Alignment of Multiple Perspectives: Establishing Common Ground for Triggering Organizational Change

Abstract

This chapter introduces methodological support for transitioning from existing to envisioned work processes via direct actor involvement. It suggests direct actor involvement in the alignment and validation of novel work practices, in particular when digital workflows or instruments are involved that fundamentally impact the modes of individual operation and collaboration. Alignment is required for consolidating various inputs for further processing. In particular, actively involving process participants in process modeling creates a challenge for consolidated digital work design. Process participants are not expected to have modeling skills and usually, they prefer to externalize their knowledge through diagrams that are as simple as possible in terms of both syntax and semantics (‘natural modeling’). Alignment leads to accommodation of novel perspectives on a work process according to the participants’ individual mental models, allowing their implementation in organizational practice after validation.

This chapter introduces methodological support for transitioning from as-is to to-be work processes via direct actor involvement. It suggests direct actor involvement in the alignment and validation of novel work practices, in particular when digital workflows or instruments are involved that fundamentally impact the modes of individual operation and collaboration.

Alignment is required for consolidating various inputs for further processing. In particular, actively involving process participants in process modeling creates a challenge for consolidated digital work design. Process participants are not expected to have modeling skills, and usually, as also stated in Prilla and Nolte (2012), they are not willing to learn a modeling language with a strict syntax and semantics and many different symbols. What they would prefer would be to externalize their knowledge through diagrams that are as simple as possible in terms of both syntax and semantics. As we have already argued for in Chap. 1, this desire calls for supporting ‘natural modeling’ processes (Zarwin et al. 2014). Such natural modeling processes are usually collaborative and focus on knowledge externalization, sharing, and negotiation of a common understanding about the topic of modeling. In the course of modeling, if appropriately supported and facilitated, alignment processes are carried out. This alignment leads to accommodation of novel perspectives on a work process according to the participants’ individual mental models, eventually causing the development of common ground (Convertino et al. 2008). Such common ground is a necessary prerequisite for informed design of to-be work processes and their implementation in organizational practice.

The purpose of this chapter is to introduce alignment from a conceptual and methodological perspective, referring to the gap resulting from enabling natural modeling practices, while at the same time, maintaining a well-defined bridge towards techno-centric (formal) modeling. Through the adoption of natural modeling principles, we present an approach called CoMPArE/WP (Collaborative Model Articulation and Elicitation of Work Processes). It achieves effective involvement of process participants and supports consolidating elicited work knowledge. Effectiveness in this context refers to the extent the participants are facilitated in externalizing their tacit knowledge and reflect on the business process model based on that knowledge. Effectiveness also refers to the acceptance of the approach by the participants. CoMPArE/WP builds upon the card-based articulation method introduced in Chap. 3 and deals with the transition of the model developed by process participants to a techno-centric process model, meaning that it can be processed and enacted using a Business Process Management System (BPMS), paving the way to acting on new work designs, which we elaborate on in Chap. 5.

After introducing fundamental alignment principles, the discrete components of the CoMPArE/WP approach are analytically described. Finally, an illustrative case is presented as proof of concept.

4.1 Alignment Concept and Principles

Alignment was introduced as an issue relevant in management by Kaplan and Norton (1996) based on their book and concepts of the Balanced Scorecard. It was considered novel to strategy management, tackling the adjustment of strategy with organization and management processes which is considered hard to achieve. It provides structured support to meet the need already recognized in 1982 for the alignment of corporate strategy with structure, systems, staff, style (culture), skills, and shared values (Peters and Waterman 1982).

Although Kaplan and Norton targeted strategic management, their plan of action and process for alignment is quite comprehensive. They suggest a thorough diffusion of adjustment activities into an organization, when suggesting the development of strategy maps and balanced scorecards ranging from corporate office to customers and suppliers, and addressing the variety of intermediate organizational units. Hence, alignment can be considered to be omnipresent, going beyond linking financial, customer, internal and learning, and growth objectives.

As an organizational communication device, an alignment process is supposed to be implemented in a variety of management activities, such as handling project meetings and multi-faceted development planning—whenever value should be created beyond what individual perspective or technical units could achieve on their own. However, as this process is supposed to be driven by specific interests due to various stakeholders that need to be involved for overall benefit generation, it requires particular management and facilitation skills and techniques. They comprise tackling complexity explicitly when required, in particular when trying to eschew complexity for simplicity. They also need to emphasize organizational adaptation capabilities to change through interventions around finance, customers, and people—how they organize their work and accomplish business tasks.

Several approaches have been made to provide technological support for that alignment process. In Business Process Management, the semantic heterogeneity between business processes has been addressed. Alignment has been focused on business ontologies for integration (Jung 2009; Fan et al. 2016). Two types of alignment processes are researched, namely, manual alignment for building a comprehensive business process ontology in a business process management (BPM) system, and automated alignment between business processes stemming from different BPM systems. Automation support is based on detecting the optimal integration of a business process into another has to be discovered, in order to maximize the summation of a set of partial similarities between semantic components consisting of the business processes.

An ontology (i.e., specification of a concept) captures knowledge with terms, definitions, and axioms related to a specific domain while representing real-world phenomena. Besides choosing a proper notation for representing the domain, an ontology aims towards improving the understanding of phenomena represented through the notation and clarifying (ambiguous) semantics. Process models could make use of ontologies for checking whether a process model covers completely the constructs in business process ontology, and thus, measuring whether a process model clearly represents the real-world phenomena.

Semantic ambiguities result from domain knowledge and its development processes. They could lead to cognitive overload and finally, inaccurate models. Domain ontologies could help ease semantic ambiguity, reducing cognitive load. When modelers use ontologies to represent domain knowledge for business process management, they define the semantics of existing business process models for process model verification and automation (Jung 2009). They also could use it to ground business process models on domain knowledge (Fan et al. 2016).

Design ambiguities in process modeling are structural or semantic:

• Structural ambiguity refers to the notation or language used for modeling, when lacking a formal definition of modeling constructs.

• Semantic ambiguity occurs when a model does not represent the business logic correctly, as it is supposed to be.

The latter is caused by the lack of accurate mapping between two items or concepts, one stemming from observing reality and the other from a formal or visual representation scheme. Consider a holiday approval process of an organization. A holiday application could be handled in several steps:

• 1. the responsible verifies the validity of application

• 2. the human resource department verifies the vacancy contingent of the applicant

In case the modeler is not clear about the granularity of work process to be represented (domain knowledge), the developed model could represent a holiday approval as single activity including both verifications. In such cases, a modeler needs to align the representation with domain experts to ensure correct models.

In order to automate alignment processes, semantic components could be extracted from annotations of business process representations (Jung 2009; Lin and Krogstie 2012). Figure 4.1 shows a potential architecture of such an approach. An ontology-based BPM system is composed of a resource repository. It contains resources, such as documents, videos, and so on, and business processes or service APIs. The latter process the resources, while ontologies as additional resource serve as a point of reference or baseline for clarification. Ontology-based BPM systems semantically describe their resources and business processes to support execution of processes.

Fig. 4.1

Architecture of ontology-based BPM systems (adapted from Jung 2009)

When using ontologies through semantic annotations of business process, meaning can be shared with other participants; this alignment can be supported constructively. Thereby, concepts and items from other ontologies or additional work knowledge can be brought in when considered relevant for the participating stakeholders. Since the relations of concepts in ontologies can be quite heterogeneous, several adjustments could occur (Jung 2009):

• Lexical heterogeneity may occur due the labeling, for example, when concepts are named in different ways while being consistent with respect to semantics, for example, Human Resource Department is also termed HR.

• Structural heterogeneity occurs once relations between two concepts differ.

• Conceptual items are missing.

One way to automatically couple even heterogeneous BPM systems is to align business process representations for the sake of semantic interoperability. Figure 4.2 shows the layered approach when developing an ontology matching algorithm. It aims at discovering semantic correspondences between model elements, such as activities.

Fig. 4.2

Ontology-based alignment (adapted from Jung 2009)

Figure 4.3 shows exemplary results of ontology-based alignment. When merging parts of ontologies, manual alignments between fragments (ref dotted line) and annotations (arrows) for a work process need to be set.

Fig. 4.3

Alignment through merging ontology fragments (adapted from Jung 2009)

When the objective of ontology development is to come up with developing a process ontology allowing the resolution of semantic ambiguities along business process modeling, approaches such as the Process Ontology Based Approach (Fan et al. 2016) are helpful. It has been designed to help reducing semantic ambiguity by avoiding cognitive overload. It tackles

• construct overload, that is, one modeling construct stands for two or more ontological constructs, and

• construct redundancy—more than one modeling construct is used to represent a single ontological construct

When creating a systematic approach to ontology-based modeling in business process management that reduces semantic ambiguity, classes (i.e., various types of terms and relationships) for domain processontology need to be formally defined to guide business process modeling. Relationships can be differentiated according their validity across different domains or not, referring to domain-specific relations. For business process modeling, different types of domain relationships have been identified (Fan et al. 2016):

• Activity-performing relations which connect two roles involved in an activity performed by one of the roles, for example, a customer sending a request to customer service.

• Temporal relations denoting sequencing activities performed by a role, for example, an employee goes on vacation after the superior’s approval.

• Conditional relations as they specify conditions when performing specific activities for a role, for example, vacations require superior approval.

Figure 4.4 shows the approach when compared to traditional process modeling. The underlying steps to prepare for alignment is based on validations and has been detailed accordingly—see Fig. 4.5.

Fig. 4.4

Facilitating resolving semantic ambiguities in process modeling based on ontologies according to Fan et al. (2016)

Fig. 4.5

Developing a domain process ontology instance (according to Fan et al. 2016)

A first empirical evaluation could demonstrate that the domain process ontology, although its creation requires some effort, could reduce cognitive effort while enhancing the perceived quality of process models. Overall, ontologies could support the generation of accurate representations, and serve as concept repositories for resolving semantic ambiguities. From a human perspective, alignment is a cooperative activity, involving cultural issues, deeply rooted in individual engagements and mindfulness, as already noted by (Evans and Jukes 2000) (see also Fig. 4.6).

Fig. 4.6

Alignment of business processes as part of co-developing organizations

Although existing approaches aim to consolidate elicited work knowledge, they require explicit ontology building. In the following, we introduce a support technique allowing direct consolidation (in line with direct manipulation), thus, reducing the semantic distance between actors (modelers) and the content to be consolidated.

4.2 Towards Direct Stakeholder Support—Minimizing Semantic Distance

In this section, we first review participatory elicitation approachesand detail the instrument, CoMPArE/WP, which aims to minimize structure inputs for modeling, while guiding actors to express their mental work models and process understanding collaboratively using scaffolds. As in participatory design (Kensing and Blomberg 1998), in the proposed instrument, actors are actively involved in process design. In this procedure, actors are guided by the process analyst who acts mainly as a facilitator. Modeling is not performed sitting in front of a PC screen and using some kind of software for process modeling. Instead, participants hold cards with different colors which are assigned specific semantics during the design procedure. Like in card sorting (J. R. Wood and Wood 2008), participants create structures using the cards. Employing tangible means to conduct process modeling has already been proposed in the literature (Weske and Luebbe 2011). Using tangible means like cards instead of sophisticated software also allows technologically illiterate actors or, in general, actors who do not feel comfortable with technology to take part in modeling and, overall, makes modeling more enjoyable and appealing to modeling participants.

Participatory Design is also the foundation of the work of Türetken and Demirörs (2011), who propose a decentralized process elicitation approach (‘Plural’) in which individuals describe their own work. Plural is based on a multi-perspective modeling paradigm (Mullery 1979), which focuses on representation of individual work contributions in models and subsequently merges them into a common model by agreeing on the interfaces among the individual models. It uses Extended Event-driven Process Chain (eEPC) (Nüttgens and Rump 2002) as a modeling language and assumes that actors are familiar with this (techno-centric) language. Plural uses tool support built upon a commercial modeling environment, which identifies inconsistencies between individual models. The authors mention tool support for resolution of inconsistencies between models, but do not elaborate further on how scaffolding for inexperienced modelers could be implemented.

Multi-perspective modeling is also proposed by Front et al. (2017) in their ISEA (Identification, Simulation, Evaluation, Amelioration) approach to involve process participants in business process elicitation. Perspectives here are with respect to different constructs used to describe organizational reality (which is different to PLURAL and CoMPArE/WP, where multiple users conceptually describe their perspective on organizational reality using the same constructs). Similar to CoMPArE/WP, it emphasizes the needs of process participants for a ‘simplified domain-specific language’, which, at the same time is kept executable to allow for interactive validation through role-plays. While the intended outcome of the method is similar to that of CoMPArE/WP, the methodological focus of the two methods is different. ISEA focuses on eliciting business process models by reviewing them from different semantic perspectives, while CoMPArE/WP focuses on methodologically supporting the identification and resolution of different viewpoints in terms of construct semantics and collaboration when implementing a business process.

Herrmann et al. (2000) have also adopted the idea of participatory design for process elicitation proposing a methodology (‘Socio-technical walkthrough’—STWT) that allows the creation of semi-structured and incomplete models. Workshops following the STWT methodology (Herrmann et al. 2007) target domain experts who do not necessarily need to have modeling experience. The STWT uses SeeMe (Herrmann et al. 2000) as a modeling language, which comprises three core-modeling elements with context sensitive semantics and is designed to represent models of socio-technical systems. It represents vague information, which explicitly captures disputed or unclear parts of a business process and thus is very close to the principles of natural modeling. No explicit scaffolds for model creation or alignment, however, are embedded in the methodology or the modeling language. The resulting models are intended for use in information system design, but are not executable in BPMS.

A similar approach is proposed in CPI modeling (Barjis 2011). Modeling is performed in a workshop setting similar to the STWT and focuses on validation of the process in the course of modeling by revisiting the model concepts in facilitated discourse. The approach claims to use an intuitive modeling language, which appears to be a simplified version of activity diagrams, to let process participants collaboratively create a ‘trustworthy and complete’ model of an enterprise. Again, the focus is on process elicitation and no bridge towards execution of the created models is discussed. In an attempt to make BPMN (Business Process Modeling Notation)—as a techno-centric language—more accessible for participatory design by process participants, T-BPM (Luebbe and Weske 2011) uses tangible modeling elements in a collaborative workshop setting. The modeling methodology focuses on articulation using BPMN notation elements, which, the authors claim, are intuitively understandable by participants after a brief introduction using examples. The result of modeling can be manually transcribed to a digital representation for further processing.

CoMPArE/WP in its final component provides tool support for guiding collaborative model creation among participants. This approach is also promoted by Collaborative Modeling Architecture (COMA) (Rittgen 2009) and Cooperative Editor for Processes Elicitation (CEPE) (Santoro et al. 2000). COMA focuses on providing support for articulating and consolidating models during collaborative modeling with a language-agnostic negotiation approach. The COMA tool provides support for UML (Unified Modeling Language) and enables actors to communicate via the software in a structured way specified by the COMA methodology. It provides scaffolds for model consolidation (i.e., the negotiation process), but presupposes that the involved participants are technology-proficient. As a result, participants, who have an important input to a process but do not feel comfortable with such software tools, might express unwillingness to be involved in a software-based collaborative elicitation-modeling procedure.

CEPE also supports collaboration during modeling with a particular focus on BPM. The modeling language proposed uses a limited set of elements to describe tasks, responsibilities, and decisions in a process. Further technical processing of the resulting models, however, is not addressed. The associated tool provides awareness features that support collaborative modeling. Aside of these features, no dedicated methodological or conceptual support for collaboration of process participants is provided. In a more recent research, Santoro et al. (2010) propose to use storytelling techniques in the early phases of process elicitation and further develop these stories to BPMN models of the described process. They describe a method to support the abstraction process necessary to derive models from stories, and to finally create formal representations in BPMN. As such, it takes a complementary approach to CoMPArE/WP, where the need for explicitly creating formal representations is avoided by refinement via virtualenactment.

CoMPArE/WP is not the first approach to tackle collaborative modeling by process participants for eliciting business process knowledge. Existing approaches supporting collaborative articulation and modeling, however, either target inexperienced modelers, or aim at producing a model that can be directly executed. This is a reasonable approach given the conflicting requirements in those areas (Zarwin et al. 2014). From a BPM perspective, however, it remains desirable to satisfy requirements in both areas with a single methodological approach. The present work goes beyond the state-of-the-art by proposing a methodology that involves transitioning from natural modeling towardsrefinement of technically interpretable models. To enable this transition, the representation used for articulation and alignment support is syntactically and semantically compatible with techno-centric modeling languages like BPMN.

4.3 Alignment Scheme

In the following, we introduce CoMPArE (Collaborative Model Articulation and Elicitation) (Oppl 2017b) as a generic approach for collaborativearticulation and alignment of individual understandings about collaborative work—independent of the actual focus of modeling, which in the case of CoMPArE/WP is work processes. CoMPArE facilitates collaborative articulation of different aspects of work using conceptual modeling techniques. As identified in related work, collaborative conceptual modeling is a recognized means to facilitate the development of a common understanding between people about a subject of discourse. The conceptual models serve as externalized artifacts, representing the participants’ mental models, and so act as mediators for the development of a shared understanding (Groeben and Scheele 2001).

CoMPArE offers structural and procedural guidance in a multi-step modeling approach (cf. Fig. 4.7). The first step makes sure that every involved participant is able to contribute his or her individual view on the work process. The second step aims at avoiding the unreflected acceptance of inconsistent or conflicting views by explicitly confronting the participants with these issues. Figure 4.7 shows a generic scheme for this process. The steps are described in the following in more detail.

Fig. 4.7

CoMPArEarticulation scheme

The guidance measures aiming at facilitating alignment activities need to be integrated in the modeling approach. This, however, cannot be done generically for all potential modeling languages. Work processes in organizations can be described with different foci (Curtis et al. 1992) that require conceptual modeling languages to provide different language constructs to describe appropriately the respective aspect (referred to as “semantic appropriateness to the modeling domain” by Krogstie et al. 1995). As an example, creating a model of the interaction in a collaborative work process requires different constructs than describing the flow of materials through a production chain. The used modeling language thus needs to be tailored to the targeted aspect of articulation. It needs to provide constructs that allow a description of the relevant aspects of the work process.

Independently of the aspects to be represented, the language needs to adhere to certain structural requirements in order to facilitate alignment activities. The aim of step 1 is to allow individual articulation of the view of every participant and have it represented in an individual conceptual model. These individual models are used again in step 2, in case conflicting representations need to be consolidated, in order to create ultimately an agreed-upon conceptual model representing a view on the work process shared by all participants. The modeling language can support the consolidation process by providing structural guidance. In line with the work of Türetken and Demirörs (2011), guidance measures are incorporated in the modeling notation in order to make visible the parts of the individual models that are subject to negotiation during the consolidation process, and which parts should remain the genuine responsibility of the contributing individual (cf. modeling areas and elements for modeling individual aspects and aspects to be consolidated in Fig. 4.7).

As an example, the individual ways of working in a collaborative work process might not be subject to negotiation as long as the collaboration interfaces are agreed upon. Consequently, the modeling language comprises elements to describe individual work and elements to describe the collaboration aspects. The former are specified to remain the responsibility of the contributing individual, whereas the latter are used to describe the relevant collaboration aspects from an individual perspective in step 1, and are subject to negotiation in step 2.

4.4 Alignment Approaches

The Subject-oriented Business Process Management (S-BPM) modeling language introduced in Chap. 3 provides a good starting point for designing a work modeling approach following the CoMPArE scheme. Section 3.2 describes how individualarticulation can be supported with a representation scheme that can be transformed to S-BPM models for further processing. Its use for alignment activities, however, has not been discussed so far. We present a detailed procedural model designed for this purpose in the next subsection. Here, we first discuss the conceptual considerations that need to be elaborated for communication-oriented work process models in the light of the CoMPArE scheme.

Separating a process along the involved roles has implications for modeling support. Modelers need support for interlinking and aligning different contributions to a business process and ultimately deriving a commonly agreed upon model of the business process (Oppl 2013).

Each role’s contribution to work is created as a separate part of the model. As noted above, one role can be taken by several actors in an organization. Different actors introduce different viewpoints about how one role’s contribution can be implemented (Herrmann et al. 2002). These different viewpoints require alignment in order to derive a unified, commonly agreed upon view on a business process. Consequently, collaboration support for modeling role behavior has to be provided. All participating actors in this case share the same part of the model.

The role-based process parts are interconnected by communication acts, which are represented by flows of discrete messages. Communication among roles occurs whenever results of work (information and/or physical goods) have to be passed on from one role to another. The following modeling activities can occur in this context (using the concept ‘message’ to represent transmitted results of work): (a) send a message to another role; (b) get notified that a message has been sent to one’s own role; (c) request a message from another role to be able to proceed with one’s own part of the process; and (d) get notified that another role requests a message to be able to proceed with its part of the process.

The first two communication acts (a and b) occur regularly in the course of modeling. They are sufficient to describe all communication situations if the business process is modeled in fully sequential manner across all involved roles. This, however, requires actors to wait for another role to send a message, before they can proceed with modeling their own process part. Communication acts c and d are introduced to avoid these delays in modeling and to explicitly allow to express expectations on modeling that might require further discussion. Actors can specify messages they expect to arrive from another role and continue modeling as if this message already would have arrived. Elicitation support has to address the specification of these different types of messages as well as the resolution of inconsistent communication acts across roles.

Modeling of role behavior is realized using a generic activity modeling element that is used for representing activities as well as acts for sending and receiving messages. The actual semantics of the element (i.e., do something, send, receive) is determined during modeling time by whether it has incoming or outgoing message elements attached to it.

Modeling of communication acts implement all four modes of communication modeling described in the previous section. Message elements are used to either send a message (outgoing message element) to another role or request a message from another role (incoming message element). Their respective incoming or outgoing message counterparts are added to the communication partner’s modeling surface to enable linking the models. Incoming messages or message requests, however, do not necessarily need to be processed by the communication partner immediately. For that reason, they are pooled in tray areas that visualize all unprocessed messages for each communication partner (cf. Fig. 4.8).

Fig. 4.8

Example setting of role-distributed models in an intermediate stage during modeling

The uses of the three modeling elements are visualized in Fig. 4.8, which shows an elicitation process in an intermediate stage for illustration purposes. The depicted scenario consists of two interacting roles. The behavior of role 1 is modeled by three actors; two actors provide input for role 2. The modeling surfaces include trays for coupling to the respective other role on one of their borders.

The model of a role’s behavior is created in the main area of each surface. Activities (labeled with lower-case letters in Fig. 4.8) are placed on the surface and are associated following their sequential order. Optional paths are represented by decision parameters placed next to the according association link (labeled with upper-case letters in Fig. 4.8).

The two model parts are interlinked using message elements (labeled with numbers). Following the coupling concept, messages always exist in pairs of two, with an outgoing message element on one surface and an incoming message on a second surface. The semantics of a message element changes depending on whether it is incorporated into the actual model (i.e., attached to an activity element) or kept in the tray area (i.e., so far not being used in the model). There are four different cases: (a) the combination of an incoming message attached to an activity (e.g., activities a, c, or h in Fig. 4.8) represents the act of processing a received message; (b) the combination of an outgoing attached to an activity (e.g., activities e, i, or j in Fig. 4.8) represents the act of sending a message to a communication partner; (c) an incoming message placed in an tray area represents a message that is offered by a communication partner, but has not yet been used in any way in one’s own role behavior model; and (d) an outgoing message placed in a tray area represents a message that is expected by a communication partner, but has not yet been created and sent in one’s own role behavior model.

As noted above, message elements are always created pairwise. If a role’s behavior includes sending a message, the outgoing message element is directly attached to the sending activity (e.g., activity e with message 6 in Fig. 4.8). The corresponding incoming message is placed in the tray area of the receiving role’s surface (e.g., message 6 on the surface of role 2 in Fig. 4.8). From there, it can be incorporated in the receiving role’s model by attaching it to a receiving activity (e.g., activity c with message 2 in Fig. 4.8, which was sent from activity g earlier). Requesting a message is performed in a similar way. When an incoming message is required to proceed with a role’s model and it has not yet been provided by the communication partner, the incoming message can be preliminarily used in the model by attaching it to a receiving activity (e.g., activity h with message 3 in Fig. 4.8). The corresponding outgoing message is considered a request to the communication partner to provide the necessary message. The outgoing message element is therefore placed in the tray area of the communication partner (e.g., message 3 on the surface of role 1 in Fig. 4.8). From there, it again can be incorporated in the designated sender’s model by attaching it to a sending activity (e.g., activity f with message 1 in Fig. 4.8, which was requested from activity a earlier).

The messages kept in the tray areas make mutual expectations and potential communication flaws explicitly visible. Requested messages or unused incoming messages that remain in one of the trays always point at a mismatch between the expectations and the current behavior of the communication partners. During elicitation, this visualization of communication problems triggers negotiation and alignment activities that allow for the specification of a sound overall model.

Three different procedural approaches for distributed model elicitation can be identified following the concept of behavior and communication specification described above. They differ in the point in time when message specification happens. In ex-ante communicationnegotiation, all messages are specified collaboratively by the involved actors before the roles’ behaviors are described. The messages are initially placed in the tray areas for each role and a then used during behavior modeling. In ex-postcommunication negotiation, each role’s behavior including all outgoing and required incoming messages is modeled separately. In a consolidation step, the communication among the roles is then aligned by mutually matching requested and sent messages. In ongoingcommunication negotiation, messages are put into the trays of communication partners immediately when they are specified during behavior modeling. Inconsistencies or different understandings are discussed immediately.

Each of the three approaches stresses different aspects of the modeling process and appears to be suitable for different modeling purposes.

• Ex-antecommunication alignment creates an initial common overall picture of the work process and leaves identification of non-suitable communication to the subsequent distributed modeling phase. Uncovered communication problems might then require an additional iteration of alignment of the communication acts among the involved roles.

• Ex-postcommunication alignment by contrast does not create an overview of the entire work process upfront and forces modelers to only focus on their own contribution to the work process. The identification of inconsistent communication acts is most likely here, as communication partners need to describe their communication completely independently of each other. The alignment of communications acts could lead to the need for a subsequent revision of roles’ behavior models, in case fundamental inconsistencies, for example, conflicting communication sequences, are identified.

• Ongoing communicationalignment avoids the need for fundamental revisions of either behavior models or communication acts, as both are specified simultaneously. Different viewpoints are immediately visible and can be discussed ad-hoc. This immediacy, at the same time, can be challenging for modelers, as they are continuously confronted with incoming messages or message requests while at the same time describing their own behavior.

4.4.1 Example: Ex-ante Communication Alignment

In S-BPM, modeling of interaction is based upon identification of the relevant subjects and the messages they exchange in the course of performing their collaborative work process. In scenarios where representatives for all involved subjects are available on-site, the elicitation of interactions in a certain work process can be performed using a methodology similar to storytelling (Swap et al. 2001). The involved actors assemble around the modeling surface (cf. Fig. 4.9), each one representing one role. A part of the surface is assigned to each role.

Fig. 4.9

Co-located creation of interaction models on a shared surface

The involved actors agree upon a scenario that serves as an example for the work process to be modeled. Then they start to collaboratively describe their roles and activities in the work process and their mutual interactions.

For each interaction, a message element is placed on the surface (cf. Fig. 4.9). These message elements are named and additional information can be assigned. Assignment is performed using the elements as containers and putting inside physical representations of digital information (business objects). The message elements are then passed to the representative of the receiving subject. The receiver continues to act according to the received information. In cases where different messages can be passed from one subject to another (e.g., depending on a decision of the sending subject), these cases are acted out one after another. As incoming messages stay on the surface in the area of the receiving subject as long as they have not been handled, messages cannot get lost or be overlooked. For each outgoing or incoming message, the representatives can take (digital) notes of what activities triggered the message or are triggered by the message. This information is used to provide context for modeling internal behavior later on.

After modeling their collective view on interaction, the representatives of the subjects have to model their internal behaviors to react upon the incoming messages.

The involved individuals use the interactive support system to model their behavior one after another, handling one or several incoming messages at a time. The main building blocks for modeling internal behavior are states. States are visualized using physical building blocks and can represent functions (i.e., activities which create some work result) or message handling (receiving and sending states). While state elements are generic before they are placed on the surface, they take one specific role (function, sending, receiving) as soon as they are used. The modeling surface shows messaging ports to all other subjects at its borders when modeling internal behavior (cf. Fig. 4.10). The ports display all incoming and outgoing messages for the respective subject, visually marking those that have not been handled so far. Placing the state element on an incoming message and dragging it to its position creates a receiving state. Temporarily dragging a state element to a messaging port (and putting it back into place again afterwards) creates a sending state.

Fig. 4.10

Modeling of internal behavior on an interactive surface

Placing a state element without any interaction at the borders of the surface creates a function state, which then can be described textually. The control flow of the internal behavior can be established by associating the elements with each another.

Displaying the incoming and outgoing messages provides the global context for a subject, even across several models of internal behavior. Information that was captured during modeling the interaction among subjects (e.g., notes about what happens when a certain message is received) is additionally provided during modeling. The representatives of the subjects in this way can focus on internal behavior without losing the big picture provided by the interaction model. The resulting models can be mapped directly onto an S-BPM representation without any further steps of interpretation.

4.4.2 Example: Ongoing Communication Alignment

The former modes of modeling support are tailored to settings, where all representatives of the involved subjects are gathered at the same place at the same time, where modeling of internal behavior can be performed asynchronously.

In scenarios, where modeling should be performed with ongoing communication alignment, several interactive support modeling surfaces can be connected and used to elicit subject-oriented process representations in one single step (the use of several support platforms at the same site would also allow single-step elicitation in a co-located scenarios). The ensemble of surfaces involving four subjects is visualized in Fig. 4.11. It can be supported using the interactive tabletop modeling instruments (Wachholder and Oppl 2014; Oppl and Rothschädl 2014) described in Chap. 3.

Fig. 4.11

Multi-surface setup for distributed modeling of subject-oriented models (bold arrows indicate linked messaging ports)

Each support platform acts as a modeling environment for the internal behavior and interaction of a single subject in the work process. For the individuals representing the subjects, the modeling experience is similar to modeling individual behavior in the co-located setting. The major difference is that the messaging ports of two subjects (allowing mutual communication) are connected directly and synchronized live. During operation, a sent message from one subject appears as an incoming message at the receiving subject’s side without any noticeable delay and is ready to be handled. Using this mechanism, the work process can be performed like in the real world.

Moving a state element to a messaging port generates an outgoing message. Incoming messages are visualized differently depending on whether they have already been handled or not. In this way, users can easily distinguish messages that require additional modeling activities, from those that have already been used in another model of internal behavior for the same subject.

4.5 Alignment Practice: Ex-post Communication Alignment with CoMPArE/WP

CoMPArE/WP is an instance of the CoMPArE scheme presented above, which is based on natural modeling practices and which at the same time maintains a well-defined bridge towards techno-centric (formal) modeling (Oppl and Alexopoulou 2016). It adopts an ex-post approach for communication alignment. In the following, the description of CoMPArE/WP is structured along these aspects. We start with an overview of the whole method, and subsequently detail each component.

CoMPArE/WP comprises three components as depicted in Fig. 4.12. The first component (‘Setting the Stage’) is based on a semantically flexible modeling scheme, with the semantics of the cards being left open, in order to identify and agree upon the concepts that are relevant for the situation at hand. This component is in line with the alignment principles described in Sect. 4.1, where we have argued for semantic alignment among stakeholders. When implementing this component, modeling participants try to find a common understanding about the scope of the business process and the notions to use to refer to the relevant concepts. Scope herein refers to where the business process starts, where it ends, and which aspects are to be addressed when implementing it.

Fig. 4.12

The CoMPArE approach represented as a BPMN process

Groups of modeling participants with heterogeneous backgrounds in particular might have an issue with wording when aligning their different views. The notions used to refer to different aspects of the business process are thus explicitly captured. A semantically unconstrained notation similar to concept mapping is used in this component to allow modeling participants to express their concepts without requiring them to initially adapt to a given modeling language. This addresses the first requirement of natural modeling. This stage explicitly meets the third principle of natural modeling (i.e., ‘no predefined meaning of symbols’).

Component 2 consists of the two steps, which form the core of the CoMPArE concept, namely ‘Describing Individual Work Contributions’ and ‘Collaborative Consolidation’, which together lead towards semantically more constrained models eligible for business process representation. During this phase, the participants use the results of phase 1 as a point of reference and implement a multi-perspective articulation approach to process modeling (Mullery 1979). The first step in this phase is dedicated to individual modeling according to the perspective of each modeling participant, while the second step focuses on collaborative consolidation of the individual perspectives. As it will be further elucidated, this separation of individualarticulation and collaborative consolidation facilitates knowledge sharing and promotes negotiation and commonly agreed-upon decisions, thus meeting the second requirement of natural modeling (i.e., ‘collaborative modeling’).

As already described for card-based modeling in Chap. 3, the modeling notation chosen for component 2 is reduced to the very fundamental concepts for the description of a business process, namely, the active entities, the actions performed by these entities and the exchange of tangible or intangible resources between entities by any means. As we adopt a case-based approach to modeling, the notation does not require decision constructs or elements for exception handling.

When actively involving process participants, it seems to be appropriate to limit the number of available modeling elements a priori to those appropriate for the intended modeling perspective and targeted outcome, that is, case-based models of business processes, as in scenario-based elicitation techniques. In this way, models are kept simple and comprise the most fundamental constructs used for the description of work and therefore the first requirement of natural modeling is met (‘i.e., intuitive constructs’). This reduction of complexity, however, interferes with the requirement of creating semantically complete formal models of business processes. Component 3 conceptually addresses this shortcoming by elaborating the model in an interactive way towards a comprehensive representation of the business process. This is achieved through refinement during virtualenactment, that is, engaging modeling participants in identifying problems and gaps of their initially agreed upon model by playing through it and elaborating it concurrently.

The whole modeling framework is iterative, enabling the flexible combination of design components as the shared understanding about the business process evolves over time and potentially uncovers additional aspects to be addressed. Flexibly combining the three components enables the adaptation of the design procedure to the business process at hand (higher complexity requires more overall iterations), to the amount of divergent views that is present in the group of modeling participants (more divergence requires more iterations of component 2), and to their skills in abstraction and modeling (higher skills enable more complex changes to be made during virtualenactment). Selecting the appropriate steps in an ongoing design process is the task of a modeling facilitator. The selection is made based on the observed situation in the group of the modeling participants and the desired outcome in terms of elaborateness of the resulting model.

All components are carried out in a workshop setting, where the modeling participants work on creating a shared artifact. However, component 2 comprises an initial step of individual activity without any interaction to capture the different participants’ views on the business process, before collaboratively consolidating those views to an agreed upon model. The methodology enables process participants to gradually develop a comprehensive model of their business process in a cooperative way without requiring them to be familiar with techno-centric modeling languages.

4.5.1 Component 1—Setting the Stage

Process participants do not necessarily share a common understanding of the organizational setting of the business process and which concepts to use for describing it (Sarini and Simone 2002). Component 1 aims at ‘setting the stage’ to enable co-operatively creating a business process model in the later components. It establishes a common understanding of the scope of the business process and of the concepts used for referring to its relevant aspects.

The modeling method used for setting the stage is based upon research on collaborative concept mapping as a means to create common ground (van Boxtel et al. 2002; Gao et al. 2007). Concept mapping is a method for externalizing and reflecting knowledge about real world phenomena, which reflects cognitive structures of the creator (van Boxtel et al. 2002).

Concept maps allow arbitrary model element types. This ensures avoiding misrepresentation or loss of information of individual work perceptions due to lack of support of what people want to express (Sarini and Simone 2002). Creating concept maps without any semantic restrictions supports actors not used to thinking in distinct concepts and helps to verbalize their work perception. It guides them towards conceptual thinking and sets a common frame of reference for all members of the group. This frame of reference facilitates consolidating the different individual views on collaboration later on.

The modeling participants perform the following steps as a group to build collaboratively a concept map:

• 1. They collect a set of elements (depicted on the cards) they consider relevant in the context of the business process under design. The types of the elements remain unconstrained. All modeling participants assign names to each of their elements individually. Then they group together elements that are of the same type (e.g., persons, tools, and documents), making the first step towards conceptual abstraction.

• 2. Each modeling participant presents each of his/her elements separately, one after the other. The element is added to a shared modeling surface accessible to all actors. The other modeling participants are asked to check, if they have also created an element representing the same real-world concept (independently whether they used the same name or not). In case an element is added to the shared modeling surface with the assumption that it is equivalent to the element by another participant, the equivalence of both elements need to be discussed by comparing the (verbal) descriptions provided by the actors. In case different names have been used, all of them remain in the model for future reference. In case the same name has been used for different concepts, a clarification is added. This step is repeated until all concepts have been added.

• 3. Concepts are correlated by the modeling participants by (a) spatial clustering of elements and (b) explicit associations depicted by connecting two elements and naming the connection. If the card-based models are developed on top of a shared paper surface, markers are used to draw the arrows between the cards. If the spatial arrangement of cards is done directly on top of a table (i.e., without a paper intervening), the incoming/outgoing arrows can be drawn on the cards themselves. Initial clustering and association specification can be performed while adding concepts in step 2. A final round of collaborative clustering and association specification after all elements have been added completes the setting-the-stage design step.

As the semantics of the modeling language is not predetermined but evolves during the design procedure, semantic compatibility to the subsequent semantically more constrained phases cannot be taken for granted. One might even argue that leaving semantics unconstrained in phase 1 makes it incompatible with the following steps and superficial for the overall modeling result. A more efficient approach might be to provide the participants with the structure of the notation used in phase 2 to have a well-defined gateway between unstructured and structured modeling.

This approach, however, does not consider the cognitive requirements of process participants who are not skilled in structured business process modeling (Genon et al. 2011), and moreover it a priori directs the participants’ mind which might result in constraining externalization of their tacit knowledge. Furthermore, a shared set of language constructs used by all involved participants to describe their mental models is a prerequisite for alignment on content level (Sarini and Simone 2002; Roschelle 1996). The existence of a common ground (Clark and Brennan 1991) in this respect, however, cannot be taken for granted—particularly when people with a diverse professional background are involved (Sarini and Simone 2002). Semantically open modeling has been shown to be an appropriate approach to address this issue (Faily et al. 2012; Engelmann and Hesse 2010; Trochim et al. 1994).

4.5.2 Component 2—Articulation and Alignment

The presented arguments for semantically open modeling in an initial phase of business process elicitation, however, leave open the question of how the results of component 1 can be used in component 2 and 3 beyond the indirect effects caused by the upfront alignment of the participants’ mental models. Although the modeling constructs are semantically not constrained in component 1, clusters of concepts that are instances of the same semantic construct generally emerge during modeling and can be identified and named (Trochim et al. 1994). Following the assumption that a business process can be described by naming the active entities, the actions performed by these entities and the exchange of tangible or intangible resources between these entities (ibid.), it is likely that concepts using these semantic constructs will naturally emerge already in component 1. A dedicated step of asking the participants to identify the concepts, which are instances of the constructs used in component 2 has two potential effects: (a) it triggers another iteration of reflection on the outcome of component 1 and prepares the transition to the semantically more constrained modeling approach in component 2, and (b) it allows the identification of the concepts that can be reused in component 2 and therefore provides a means for reflecting on the completeness of the model in the course of collaborative consolidation. This is done by matching the elements of component 1 with those having emerged from collaborative consolidation in component 2.

Still, there might be clusters of concepts that bear semantics, which is not used in component 2. These cases cannot be directly incorporated in the models resulting from collaborative consolidation. They are, however, still available for another iteration of reflection in component 3, where semantically more comprehensive modeling approaches, such as BPMN, are used. This might allow matching further constructs having emerged in component 1 to the resulting model (e.g., data used within an activity of a single participant, which are not part of the modeling language used in component 2, but can be represented in BPMN). If concepts remain that still cannot be matched to semantic constructs of the formal languages after component 3, they have to be considered to describe the process context, that is, provide further information about how the model has to be interpreted and/or can be put to practice. This additional information is also considered of value for model understanding of process participants (Herrmann and Nolte 2014; Santoro et al. 2010).

4.5.2.1 Step 1: Individual Articulation

The first step of component 2 focuses on individual articulation of the participants’ own perceived work contributions. The participants are provided with cards of different colors for modeling, with each color representing different semantics. The spatial arrangement of the cards based on their colors acts as a structural scaffold, which enables guiding the consolidation process in a structured manner via dedicated areas for describing different aspects of the process (cf. Fig. 4.13). Scaffolding is a concept widely used in education to describe structures or methodologies that support learners in self-directed efforts to understand something new (Van de Pol et al. 2010). Using the structural scaffold, modeling participants can independently of each other describe their own activities, the actors or organizational entities they are interacting with, and how this interaction manifests itself in terms of information or artifact exchange.

Fig. 4.13

Result of individual articulation

The detailed semantics of the modeling elements in the stage of individual modeling is hard to be determined upfront, as the people involved in modeling are not necessarily accommodated to explicitly follow specific semantics when describing work. As long as people use the fundamental process element classes (WHO, WHAT, EXCHANGE), a common level of conceptual abstraction can be achieved in the next, collaborative phase. The modeling elements in individual articulation should consistently be used as follows to provide for easier consolidation in the collaborative phase:

• WHO-items (represented by blue cards) indicating the role represented by the modeler herself/himself and those roles the modeler perceives to directly interact with.

• WHAT-items (represented by red cards) describing individual activities and their sequence indicating a causal and/or temporal relationship.

• EXCHANGE-items (represented by yellow cards) incoming to the participant’s stream of activities indicating tangible or intangible resources expected from others.

• EXCHANGE-items (represented by yellow cards) outgoing from the participant’s stream of activities indicating tangible or intangible resources offered to others.

Figure 4.13 shows three sample models created individually in step 1 of component 2, which together form a foundation for later consolidation. The labels in the models refer to a (exemplary) production process, in which a production manager, a production worker, and a stock manager are involved. The models indicate several fundamentally different understandings of how the production process should be implemented. While those differences might not occur in such a drastic way in reality, the scenario has been chosen to illustrate different aspects of consolidation below.

Modeling starts with a blue card bearing a name for one’s role, which is used by the individual modeling participants to refer to themselves. The card is placed at the top border of the modeling surface. Modeling participants then describe what they are doing in order to complete their contribution to the business process. They describe their work by means of a sequence of distinct activities. Each activity is represented by a red card, named by the participant to indicate what the activity is about (referred to as WHAT-item in the following). The cards are placed vertically below the blue card representing the participant’s own role. Their vertical ordering indicates their sequence, the top-most card consequently representing the first activity of the participant.

Subsequently, modeling participants determine people or roles they have to collaborate with to finish their work in the course of the business process. For each collaboration partner, a named blue card is placed next to the blue card representing him or herself (referred to as WHO-item in the following). All blue cards are arranged along a horizontal line at the top border of the modeling surface.

Finally, modeling participants determine what artifacts (information, material, etc.) they exchange with others in order to complete their work. In particular, they distinguish what they require from others in order to carry out certain activities, and what they can provide to others as a result of their activities. For each exchange, a yellow card is placed vertically below the blue card representing the respective collaboration partner (referred to as EXCHANGE-item in the following). The cards are vertically arranged to match the activities, for which the exchange is required or by which it is provided to others. Yellow cards indicating required exchanges are connected to the red cards representing the dependent activity using an arrow from the yellow to the red card. Provided exchanges consequently are indicated by an arrow from the respective red card to the yellow card.

4.5.2.2 Step 2: Collaborative Consolidation

The resulting models of step 1 are consolidated into a common model in step 2. The individual models are merged and aligned according to the following scheme (Fig. 4.14 shows the merging process for two of the sample models depicted in Fig. 4.13).

Fig. 4.14

Result of component 2.2: Collaborative Consolidation

The modeling participants agree upon people or roles, who are or should be involved in the business process. Each process participant is represented by a named blue card. The name is mutually agreed upon. All blue cards are arranged along a horizontal line at the top border of the modeling surface. Additionally, modeling participants articulate how each of them implements their contribution to the overall business process. All activities are represented by named red cards. The name is determined by the modeling participant responsible for the activity, but has to be understandable by the other modeling participants as well. The cards are placed vertically below the blue card representing the person or role responsible for enacting it. Their vertical ordering indicates the sequence in which they are enacted by the person or role. The top-most card consequently represents the first activity.

Finally, modeling participants agree upon how to collaborate in the course of the business process and which information, material and so on is exchanged in the course of this collaboration. All exchanged information, materials, and so on are represented by named yellow cards. The name is agreed upon by the modeling participants involved in the exchange but has to be understood by the other modeling participants as well. Each card is placed between the source lane (i.e., the sequence of red cards headed by the blue card representing the providing person/actor) and receiving lane. If the lanes are not adjacent, the card is placed next to the lane the exchange originates from. The cards are vertically arranged to match the activities, for which the exchange is required and by which it is provided. Arrows are used to connect the red cards representing the providing and requiring activities to the yellow card.

Consolidation is performed according to the following scheme (modeling steps described in brackets refer to the example depicted below):

• 1. One of the modeling participants starts by placing the WHO-item representing him/herself on the shared modeling surface. If known a priori, the actor responsible for starting the real-world business process starts modeling (cf. step 1 in Fig. 4.14). The process start is indicated by an individual model, which contains WHAT-items that are not dependent on any EXCHANGE-items to be received. If more than one such individual model exists, this indicates a business process with multiple parallel starting activities, which are only synchronized at a later point in time. In such cases, any of the affected modeling participants can start modeling.

• 2. The same participant describes his/her own contribution to the business process by placing WHAT-items below his/her own WHO-item. Others do not intervene during this stage (cf. steps 2–3 in Fig. 4.14).

• 3. As soon as the participant places the first EXCHANGE-item (step 5 in Fig. 4.14), the targeted communication partner steps in and matches his/her own perception of the business process (steps 6–8). Matching can take the following forms:

  • The communication partner has a matching EXCHANGE-item (i.e., an EXCHANGE-item that matches the already placed item). In this case, the matching elements are merged (cf. steps 19–20 in Fig. 4.14).

  • The communication partner has no matching WHO-item (i.e., he/she has not perceived any collaboration with the original modeling participant at all). This is a fundamental difference in the perception of the business process. Participants need to agree how to resolve this issue (cf. steps 15–16 in Fig. 4.14, where the stock manager expected to receive a part list of parts from the production manager directly, whereas the production manager passed it on via the production worker).

  • The communication partner has no matching EXCHANGE-item (i.e., he/she did not share the perception of collaboration or did not consider it relevant). Such a difference again needs to be resolved by the affected participants (cf. step 22 in Fig. 4.14, where the production worker considered it to be finished after the order was produced, whereas the production manager expected an explicit notification that the production process had finished).

  • The communication partner considers one of his/her own EXCHANGE-items to match. The involved participants, however, have a different understanding of the content or form of the exchanged information or artifact. Such differences need to be addressed by the participants (cf. steps 5 and 8 as well as steps 11 and 14 in Fig. 4.14, where in the first case the production manager provided a more detailed description of the EXCHANGE than the production worker, and in the second case the EXCHANGE between stock manager and production worker was modified due to upfront communication of the parts list).

• 4. Consolidation continues in this way until all points of collaboration are agreed upon. Once one actor has completed his or her contribution, others with remaining elements not yet incorporated in the common model take over and provide further input to the consolidation process (cf. step 22–23 in Fig. 4.14).

The limited set of modeling elements used in component 3 prevents the occurrence of co-operation and externalization problems due to lack of participants’ experience in modeling (Genon et al. 2011; Britton and Jones 1999). When actively involving process participants, it seems to be appropriate to limit the number of available modeling elements a priori to those appropriate for the intended modeling perspective and targeted outcome (Muehlen and Recker 2008), that is, case-based models of business processes, as in scenario-based elicitation techniques. In this way, models are kept simple and comprise the most fundamental constructs used for the description of work and therefore the first requirement of natural modeling is met (‘i.e., intuitive constructs’).

Figure 4.14 shows the merging process for the sample models depicted in Fig. 4.13. The numbering indicates the sequence of consolidation steps, the outlines of the numbers indicate the different modelers, and the stroke of the outline indicates whether conflicting viewpoints needed to be resolved.

4.5.3 Component 3—Refinement via Virtual Enactment

Completing the modeling components described above leads to models that are semantically incomplete representations of business processes. Most notably, these models do not account for different variants of a business process. Refinement through virtual enactment is a means to complete a process description without the need to create comprehensive process models as in the case of traditional conceptual modeling. This is enabled by transforming the results of component 2 to an executable process model (as described in Chap. 3) to play through complex decision processes via workflow enactment (Oppl 2017a). By incrementally adding process variants, the model evolves as virtual enactment continues. Complex models of business processes are documented in this way without the need to ever translate one’s perceptions of a business process to abstract process descriptions in a single step. The model permanently maintains a syntactically valid state during refinement, which allows for further processing, such as live validation of dead- or live-locks or mathematical simulation of capacities. The conceptual details on and instruments used for virtual enactment are presented in Chap. 5.

For refinement during virtual enactment, an instance of the process is started. As stated earlier, this model initially only reflects one single variant of the process, omitting more sophisticated control flow constructs such as decisions or loops. It also does not contain the content and format of the exchanged information or resources. The aim of refinement through virtual enactment is to create a semantically correct and complete representation of the business process in all its variations as perceived by the involved actors. During the process of virtual enactment, the modeling participants enact the process step by step. For each step, the responsible modeling participant assesses the semantic correctness and completeness of the represented information above.

If any of these assessments leads to the need for changes in the process, these changes are made directly during execution. It should be stressed at this point that participants during the virtual enactment do not perform modeling. The system rather presents web-based dialogue forms to the participants, allowing them to describe the deviations from the currently enacted process. Potential changes include adding, altering, or removing activities of a process participant, shifting activities between participants, adding or removing messages required from or provided to another participant, and so on. The forms support the description of the new or altered process steps by providing the current process context (i.e., what was done, before the deviation was started), as well as information about potential interaction partners.

Modeling participants identify any steps in the business process that are described in a way they consider erroneous or cannot agree upon content-wise. Such steps are modified in a way that all affected participants can agree to. For each task, the participants assess whether there are any alternative ways of acting, and, if so, under which conditions these alternatives are to be executed. Both, the additional activities and the conditions need to be specified by the affected participant and have to be understandable to all other participants, as such changes might trigger cascaded changes that need to be addressed by them. As a result of these modifications, but also due to incomplete representation in component 2, gaps might by identified in the business process. These gaps need to be addressed by agreeing on and adding further activities, exchanges, or even new roles. Fundamental changes might trigger the need to go back to component 2 and explicitly address the newly identified part of the business process.

4.5.4 Transition from Modeling to Enactment

Components 1 and 2 from a representational aspect are implemented using physical cards. In order to enable execution of the models in component 3, the card-based models need to be converted into digital model representations. To this end, the card-based model initially is captured as a pixel-based image via taking a picture, for example using a mobile phone. The modeling cards bear visual markers that can be recognized and uniquely identified in the picture. The optical marker recognition engine (Oppl et al. 2017) used for this purpose is based upon the ReacTIVision system (Kaltenbrunner and Bencina 2007). Based upon the coordinates of each marker, the cards contained in the image can be identified and extracted. The extracted information is also used for identification of potential connections that are drawn between cards. The model layout is subsequently analyzed in the next step regarding its adherence to the CoMPArE/WP notation. If modeling rules are violated, missing, or ambiguous, then the information needed for the transformation can be added interactively. IT-based guidance through the interactive parts of the transformation process is described in (Oppl 2015). Once the transformation process is finished, the resulting model can be used for refinement through virtual enactment.

4.6 Conclusion

Considering the requirements and subsumed procedural cornerstones developed in Chap. 2, we can reflect on the results of this section. The reflection takes into account individual engagement of actors, as well as the activities of organizations. In Table 4.1, we follow the provided list of requirements and elaborate on each according to relevant achievements for each presented articulation technique.

Table 4.1 Elicitation requirements and CoMPArE/WP

From a procedural perspective, the presented alignment procedure and its variants are addressing the various steps as follows:

• 1. Along with preparation, the setting including participating actors, existing models, and alignment instruments is configured and provided for use. The scope is given by the previously elicited knowledge, mainly focusing on individual mental models of a certain business case. The environment is motivating in case graspable material is used for reflecting individual perspectives. It also facilitates negotiating when sharing the represented knowledge while coming up with a common model that participants could agree upon. Co-creation instruments for executing process models when probing them in the course of generating work knowledge also need to be prepared.

• 2. Situation-sensitive articulation features are provided, in particular when additional knowledge on role behavior or work tasks is externalized. For ex-post alignment, in-depth articulation turns out to be of value. Its results can be aligned with existing representations in a structured way. Hence, the procedure remains traceable and transparent for stakeholders.

• 3. Facilitation needs to be provided to structure the alignment and consolidation procedure, in particular when several models need to be aligned or different strategies of negotiation support are applied to specific cases. Intervention may be helpful when interpreting cross-boundary topics or work patterns, together with suggesting executing models for collecting implementation or practical experience in case of complex worksituations.

• 4. Representational alignment as a consolidated representation serves as the baseline for documentation and further exploration. CoMPArE offers incremental, structured alignment support due to its focus on role-specific work process designs.

• 5. Organizational alignment has to follow representational alignment, for example, through playing roles or executing the consolidated work knowledge and process models in the operational context of the business. This is the point in time, when elicited knowledge becomes part of workspaces of an organization.

Overall, the presented approach can be advised for all development settings where elicited work knowledge needs to be aligned taking into account different mental models and requiring strategic intervention for consolidating stakeholder knowledge in an accountable way.