Keywords

When the articulation of values in the context of business operation and managing organizations is brought up, stakeholders often start referring to the value of business assets, for example, IT. Such a perspective is driven by a focus on business enablers and resources required to generate valuable assets for the market. And most decision makers look at those elements from a ‘requirements engineering’ perspective to deliver products and services. This understanding is grounded in Michael Porter’s concept of value chain and its analysis that helps in apprehending how an enterprise creates valuable elements through a set of core (like sales) and support activities. Both are assumed to contribute to the sustainable existence of the producing organization in competitive and continuously changing environments, based on products or services for which customers are creating revenues.

Products and services are produced along business processes. These are composed of functional activities transforming incoming goods and information through a series of cross-functional steps in the course of business operation. Such an approach to business analysis considers value creation to reside in the design and execution of work processes (rather than the processed or created assets) that leads to a result for customers or consumers. Although value created in this way has a tangible component, for example, effort to be spent for production, its second component, the intangible part, such as distance to customer needs, is of equal importance. However, capturing both requires explication and representation of stakeholder knowledge of work processes and their structure. The more the stakeholders know of business processes, the higher are the chances of promising improvement ideas stemming from business operation.

The challenge is now to effectively develop techniques to bring up opportunities to organize work in a way that it creates intangible and tangible value. Based on existing work processes, potential arrangements of operational structures need to be articulated by the concerned stakeholders. Knowing how to express what an organization knows in terms of structuring work to achieve business objectives reveals development opportunities without anticipating prospective operational structures. In this chapter, we introduce three different foci of articulation:

  • Stakeholders identify and refine their role identity in the context of collaborative task accomplishment

  • Stakeholders explicate information needs and supplies when accomplishing functional tasks

  • Stakeholders elaborate on collaboration with others by specifying transactions between functional roles

Although each of the approaches finally ends up with revealing and documenting essential process elements in terms of stakeholder roles, activities, and relationships, they differ in terms of their means, externalize, and represent knowledge. In this way, particular aspects when articulating knowledge can move to the center of interest. We start out with subject-oriented articulation support allowing to shape the understanding of a role (termed subject) through natural language expressions and identifying interaction patterns when accomplishing business-relevant tasks. We proceed to demonstrate a card-based structural elaboration approach for developing interaction patterns starting from a functional role perspective and progressing to an overall interactional perspective, in order to capture relevant business operations. We finally show an approach aimed at a detailed understanding of interactions in terms of formal and informal relations between stakeholder roles, when completing the chapter, with an account on value networks.

3.1 Shaping Role Identities Through Contextual Behavior Articulation

The approach introduced in this chapter aims to utilize human language skills when stakeholders describe their operational behavior at work. They also allow taking into account to capture the interaction with other stakeholders. The underlying framework for representation, subject orientation, is explained with its ontological background based on Fleischmann et al. (2012). Sample applications demonstrate the practical benefits of the approach. They cumulate in the execution of behavior representations that facilitate process development in terms of seamless round-trip engineering. Behavior patterns can be deployed dynamically when operational knowledge needs to be adapted or when aiming to transform organizations in a non-disruptive way, for example, in the course of digitalization projects.

3.1.1 Start Simple, Using Natural Language

When following natural language sentences, stakeholders can describe their behavior in terms of contextual activities in specific situations, that is, framing activities through some active role and affected objects. Thereby, we can use several constituent elements of sentences: subject, predicate, and object, referring to WHO is DOING WHAT (some activity) handling WHICH OBJECT. In case the person articulating knowledge is the addressed, WHO, he/she can describe actions and objects in a straightforward way. Besides involving only a single actor, descriptions created in this way should be easily understood due to the tripartite structure, and thus being used without further transformation when communicating work-articulated information to other stakeholders.

When using subject-oriented representations, we can utilize this information structure as models. Following the structure of natural language sentences, processes executed by digital systems can also be expressed. However, the articulation needs to start like any development of an information system or digital artifact in a socio-technical system with identifying a specific scope or universe of discourse. It is that part of the observed reality that is supposed to be supported by an information system or technological artifact.

The identified scope determines a so-called universe of discourse (i.e., the space or field of concern) in which structural qualities and behavioral elements have a certain meaning for those using them. Typically, stakeholders refer to work situations, such as handling business cases that become part of subject-oriented representations. These models include the interactions of behavioral entities (humans or technological artifacts) occurring in a work environment. It is this kind of information that qualifies subject-oriented models to be executed without further transformation, as they contain the control flow required for processing specified activities in a certain sequence.

In the course of articulation, model elements are considered either essential or complementary. The latter are grouped around the essential elements, and trigger modeling processes (Scholz and Holl 1999) embodied in various existing modeling paradigms. Typical paradigms are functional ones leading to control or data flow diagrams, data-oriented ones leading to data models such as Entity Relationship diagrams, and object-oriented ones using modeling languages such as UML (Unified Modeling Language). Likewise, subject-oriented articulation follows notational conventions, namely those that lead to subject-oriented models. Thereby, stakeholders identify roles or small sets of tasks using notations or modeling languages like the ones mentioned above. Subject orientation allows representing parts of the observed reality in terms of natural language sentence structures. Hence, these models can be used for any other representation or modeling approach universal use, due to the familiarity of natural language in daily communication, and the availability of a structural semantics for sentences, comprising subject, predicate, and object.

Since the use of natural language does not prevent misunderstandings, this simplified sentence semantics should help to initially clarify roles, activities, and concerned objects of work before engaging in more structured forms of representation. It might require some exercise to strictly apply it; however, it aims to deliver more complete descriptions of situations compared to purely functional descriptions of workplaces. The structural sentence semantics of natural language ‘subject-predicate-object’ corresponds to subject-oriented modeling, in several ways:

  • A subject is the starting point for describing a situation or events.

  • An activity is denoted by a predicate.

  • An activity concerns an (abstract) object.

The distinction between essential and supplementary aspects can be kept for natural language articulation, since humans also tend to use passive sentences in case they do not take into consideration any particular actor explicitly. Such sentences could convey events or specific contextual information of situations. For precise representation, however, each activity has to be assigned to a specific subject (actor). In behavior models, acting roles, for example, the employees are distinguished from predicates defining the activities of acting roles, and objects denoting the purpose of these activities. In the course of accomplishing their tasks, they receive work inputs and pass on results. Hence, we consider interaction and communication, either direct or indirect, to be an essential activity of acting roles for subject-oriented articulation and representation.

We introduce the subject-oriented articulation approach using a common work situation: Employees have to apply for going on holidays or taking days off. It allows us to demonstrate the fundamental and supplementary aspects of the sentence structure ‘subject-predicate-object’. Figure 3.1 shows the natural language description of the respective work procedure.

Fig. 3.1
The text describes the holiday application procedure in a natural language.

Natural language description of an application procedure for vacation (released under a Creative Commons Attribution 4.0 International License (CC BY 4.0))

As long as modeling is focused on activities, predicates are essential, whereas subjects and objects are considered as complementary elements. However, in subject-oriented terms, the subject and activities are essential, as they constitute the core concepts to representing processes in this approach. A subject scopes a specific set of send-, receive-, and do-activities (Fleischmann et al. 2012).

3.1.2 Roles As Semantic and Pragmatic Entities

When applying subject-oriented articulation to picture reality and represent situations according to its essential elements, some properties of subject systems can be identified. They finally guide the articulation of behavior:

  • Being in the World: Identifying a subject means bringing a self-contained entity to life—it is a behavior encapsulation of an active entity, and also subject to the ‘world’ (i.e., identified universe of discourse). The latter results from the fact that a subject can be addressed (only) by other, existing subjects of the world. Consequently, being a subject in the world also means being subject to the world.

  • Subjects are social and private at the same time: Exchanging messages is interaction via send and receive pairs. Hence, subjects are open for message passing, either for being informed or for further handling and delivering a business object. However, how they process incoming messages and produce output remains encapsulated in the (internal) behavior description. In this way, subjects align individuals with communities—they allow stakeholders having a cognitive identity while behaving as a social being.

  • Subjects are dynamic entities while keeping the outer structure stable: They can change their internal behavior while remaining a stable communication partner. In this way, self-organizing communities can be represented. It increases flexibility of structures, even when changing their manifest form. New gadgets can take over new responsibilities, such as calendar, meeting, cinema proposal, or sensor systems, just to name a few, replacing or encapsulating existing behavior patterns.

  • Subjects make the world more concrete due to their nature of being a boundary object. Such a boundary object can be communicated among stakeholders and thus, understood by people with different backgrounds (Arias and Fischer 2000). Subject representations can be read in natural language using active sentences. This property ensures some understanding and allows active participation of all stakeholders, even when requiring some self-discipline to use active sentence and complete natural language expressions to describe situations. It brings the approach to integrated thinking and acting of stakeholders, as proposed by Heidegger (cf. (Han 2015), p. 53).

  • Subject orientationscales due to the decentralized management mechanism. It enables setting up and configuring a large number of actors or systems. The latter is of particular importance in networked settings. Thereby, subjects correspond to autonomous agents, not only being capable to implement certain task behaviors, but also to monitor the status of other elements or systems. For instance, in safety-critical settings, such monitoring and supervision services may be a requirement.

  • Subjects are part of choreography. In this way, lifecycle activities of certain systems or elements can become part of continuous development without endangering ongoing operations of networked actors. As long as the communication interface remains, internal subject behavior can be replaced and modified.

  • Subject-oriented representations allow for problem- and domain-specific abstraction. This feature provides uniform addressable interfaces for resource control and management.

Overall, a subject-oriented representation of any setting can come close to the ‘reality’ as perceived and pictured by humans, both in terms of its elements as behavioral entities including their set of activities and interactions, and in terms of its description, as natural language can directly be used conveying the meaning encoded in work processes.

3.1.3 Acting in a Specific Role—Pragmatic Modeling

The semantics of a situation and activities of embodied actors refer to the pragmatic aspects of a situation and thus, influence the pragmatic quality of a representation or behavior model.

Pragmatic quality is the correspondence between the model and the audience’s interpretation of the model and has one goal, comprehension, meaning that the model has been understood. Means to increase pragmatic quality include not only executability, animation, and simulation but also more advanced techniques like model transformations, model filtering to present model abstractions from several viewpoints, model translation, and explanation generation. (Krogstie et al. 2006, p. 94, according to Stamper 1996)

In the following subsections, we start out with the general perspective on the world as perceived by stakeholders from a subject-oriented view and proceed with constructing work models based on a role-specific behavior understanding (cf. Fleischmann and Stary 2012).

3.1.3.1 The World As Network of Roles

Articulating the world in a subject-oriented way means trying to represent each observation in terms of networked active elements termed subjects, assumed to act in parallel (Fleischmann et al. 2012). Since each of those actors or subjects can be described in terms of its behavior and has the capability to exchange messages, a federated choreographic ecosystem is established: Federation means a form or single unit, within which each actor or subject or organization keeps some internal autonomy. This form or single unit identifies the perceived part of the world that is considered relevant to describe a specific situation. It sets up the universe of discourse or context space for representation and action.

Keeping some internal autonomy at some point requires being more concrete: The ‘some’ is dedicated to the level of abstraction considered representative for the stakeholders or modelers, both, with respect to functional or technical activities, and interaction or communication with other subjects.

Choreographic ecosystem refers to recognizing concurrent, however, synchronized processes and activities

  • in a community of interacting elements and their environment

  • when considered as networked or interconnected system

According to this perspective, ecosystems operate as autonomous, concurrent behaviors of distributed subsystems or actors. A subject is a behavioral role assumed by some entity that is capable of performing actions. The entity can be a human, a piece of software, a machine (e.g., a robot), a device (e.g., a sensor), or a combination of these, such as intelligent sensor systems.

Since subjects represent systems with a uniform structure, they can be used to define federated systems or System-of-Systems (SoS) (Jamshidi 2008). SoS have as essential properties “autonomy, coherence, permanence, and organization” (ibid., p. 1) and are constituted “by many components interacting in a network structure,” with most often physically and functionally heterogeneous components. For instance, education support systems comprise social media and content management systems for learning support. SoS subjects can execute local actions that do not involve interacting with other subjects (e.g., a clock providing the time in an office), and communicative actions that are concerned with exchanging messages between subjects, that is, sending and receiving messages, for example, triggering ringing a tone (Stary and Wachholder 2015; Stary 2017).

3.1.3.2 Articulation by Stepwise Behavior Abstractions

Subjects exchange messages and use operations on objects. For the holiday application, the behavior articulation starts with the identification of the actors or roles involved in the process (Bach 2000), that is, the subjects, and the messages they exchange. Actors drive a process. In order to coordinate and tune their activities, actors have to communicate and use suitable tools. Figure 3.2 shows the subjects involved in the holiday application process, the exchanged messages naming the transferred information. In this way, depending on the activities of the subjects, all predicates required for task completion are identified step-by-step (including the required data).

Fig. 3.2
The chart depicts the process flow for leave application between the employee, manager, and Human Resources.

Subject identification for the holiday application process, providing subjects and their interaction

While sending messages, data is transmitted. For instance, the holiday message application sent by the employee to the manager contains the start and end of applied holidays. ‘Send messages’ or ‘message transfer’ does not imply implementation details of the underlying mechanisms for interaction. The holiday application might be transferred in carbon copy, by email, or using a web application accessible by the employee and the manager. The terms refer to a logical action rather than concrete implementations, for example, messaging systems used for data exchange.

Figure 3.2 shows only the interaction structure of a process. The first refinement concerns the sequences of interactions, that is, the behavior of each subject has to be specified. Figure 3.3 details the employee behavior, namely the sequence of sending and receiving messages and performing activities. The initial state is marked. In this state, the employee fills in a holiday application form. Upon completion, the employee’s state switches to the next state via the transition ‘holiday application completed’. This state is a sending state. In this state, the holiday application is sent to the manager. After successfully sending the message, the employee reaches the state ‘answer of manager’ waiting for approval or rejection. This state is a receiving state. In case of rejection, the process terminates. In case of approval, the holidays can be taken as applied for. Upon return of the employee, the holiday application process also terminates.

Fig. 3.3
A flow chart depicts the steps involved in the holiday application process from the employee's end. The process starts with the filling out of the vacation request and ends with being on vacation if approved or with the withdrawal request if not approved.

Employee behavior in holiday application process

The behavior of the manager is complementary to the employee’s. The messages sent by employee are received by the manager and vice versa. Figure 3.4 shows the behavior of the manager. The manager is on hold for the holiday application of the employee. Upon receipt, the holiday application is checked (state). This check can result in either an approval or a rejection, leading to either state, informing the employee. In case the holiday application is approved, the Human Resources (HR) department is informed about the successful application.

Fig. 3.4
A flow chart depicts the steps involved in the holiday application process from the manager's end. The process starts with receiving the vacation request. This request, if approved, is conveyed to the employee and Human Resources and ends with the receive state. If denied, then the message is conveyed to the employee and the process ends with the receive state.

Manager’s behavior in holiday application process

Finally, the behavior of the HR department has to be detailed. It receives the approved holiday application and puts it to the employee’s days-off record, without further activities (process completion) (Fig. 3.5).

Fig. 3.5
A flow chart depicts the steps followed by the Human Resource department toward the approved request for vacation. The process starts with the receiving of the approved vacation request and ends with updating the leave account.

HR department behavior in holiday application process

So far, we have modeled:

  • the subjects involved in a process

  • interactions they are part of

  • the data they send or receive through each interaction, and

  • behavior of each subject

The description of a subject defines the sequence of sending and receiving messages, or the processing of internal functions, respectively. In this way, a subject specification contains the pushing sequence of predicates. These predicates can be the standard predicates like ‘send’ or predicates dealing with specific objects, such as required when an employee files a holiday application form (see Fig. 3.3). Consequently, each node (state) and transition has to be assigned an operation. The implementation of that operation does not matter at that stage, since it can be handled by object specifications. As we abstract from implementation details, it seems suitable to replace the term operation by the more general term service.

A service is assigned to an internal functional node, once this state is reached, the assigned service is triggered and processed. The end conditions correspond to links leaving the internal functional node.

Each result link of a sending node (state) is assigned to a named service. Before sending, this service is triggered to identify the content or parameter of a message. The service determines the values of the message parameters transferred by the message. Analogously, each output link of a receiving node (state) is also assigned to a named service. When accepting a message in this state that service is triggered to identify the parameter of the received message. The service determines the values of the parameters transferred by the message and provides them for further processing.

These services are used to assign a certain meaning to each step in a subject. Services allow defining the predicates used in a subject. All of those are triggered in a synchronous way, that is, a subject only reaches its subsequent state once all triggered services have been completed. Figure 3.6 shows how the predicates of a subject are defined by means of objects.

Fig. 3.6
The flow chart of vacation application with predicates and objects. The flow starts with the filling out of vacation request and ends either with the vacation or with request withdrawal. This also includes filling in the start, end, status, and decision results.

A subject with predicates and objects

3.1.4 Conclusive Summary

Natural language is a valid starting point for articulation and behavior representation. Structured natural language sentences can serve as a fundamental means of articulation. When using the introduced subject-oriented scheme, stakeholders recognize actors as the starting point for modeling, allowing for rich context representation of functional behavior (Brocke et al., 2015, 2016). The representation scheme ensures coherence, both, in terms of flow of control, and the addressed data. Consequently, stakeholders can benefit from specifications that contain contextual and operational information, such as social interactions, cooperation, and collaboration aspects (Neubauer and Stary 2017).

3.2 Sorting Out: Cards As Carrier of Functions and Interaction

While subject-oriented models provide a natural language-oriented form of representation, the act of modeling itself still requires the people engaged in modeling to step out of their own work context and adopt a bird’s eye view on their work. This is cumbersome for inexperienced modelers, who usually have a spatio-temporally contextualized understanding of their work contributions and are mainly used to talk about single cases (i.e., instances) of their work processes. Abstracting from these instances and adopting a more generic view is a fundamental skill when engaging in modeling activities (Frederiks and van der Weide 2006). It, however, cannot be assumed to be fully developed for all modeling participants. Appropriate forms of representations and scaffolds can thus help to mitigate deficiencies in this area and allow including people without prior modeling experiences in work articulation and design activities (Oppl et al. 2017). In this light, we here introduce a method based on structure elaboration techniques (Groeben and Scheele 2000) that scaffolds the articulation process and still leads to models that represent both, the functional and interactional aspects of work processes.

Research on facilitating lay modeling focuses on measures to guide inexperienced modelers through the process of creating a model without overloading them with syntactic formalism and complex modeling constructs. Existing research (Santoro et al. 2010; Fahland and Weidlich 2010; Kabicher and Rinderle-Ma 2011; Lai et al. 2014) suggests that starting modeling based upon a concrete work case facilitates developing an understanding of the necessary concepts for inexperienced modelers when describing a work process in an abstract conceptual model. Using a case-based approach to modeling also reduces the number of language elements necessary to depict the work process.

For example, case-based models do not require decision constructs or elements for exception handling. While the number of modeling elements alone appears not to have a notable impact on the understanding of a modeling language for inexperienced modelers (Recker and Dreiling 2007), empirical evidence shows that the number of elements actually used during modeling is limited and highly dependent on the modeling objective (Muehlen and Recker 2008). When involving inexperienced modelers, 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 (Genon et al. 2011; Britton and Jones 1999). For modeling organizational work, the modeling perspective is oriented towards the work of actors and their interactions within an organization. The targeted outcome is reaching common ground on the work process for non-expert modelers.

Furthermore, Herrmann and Nolte (2014) and Santoro et al. (2010) provide evidence that non-formalized information and annotations to model elements can aid the externalization process. However, they do not force the modelers to express all information using the constructs of the modeling language. Some results also point at the importance of (human or automatic) facilitation and scaffolding during the model creation process (Hjalmarsson et al. 2015) and the model alignment process (Rittgen 2009), particularly for inexperienced modelers (Davies et al. 2006). Recent research indicates that procedural and structural scaffolds provided by a facilitator or an automated system may support the refinement of incomplete models (Oppl and Hoppenbrouwers 2016; Oppl 2016).

Summarizing, the following properties of a modeling approach support collaborative modeling by inexperienced modelers: (1) starting with case-based development of process models, (2) offering a constrained set of modeling constructs with semantics focused on the modeling objective, (3) enabling informal annotations of model elements (i.e., not adhering to formal modeling syntax), and (4) offering procedural and structural scaffolds for model creation and alignment.

3.2.1 Articulation Concepts

Models of work processes that should express the collaborative aspects of work need to provide semantic constructs to represent who is involved in the work process, which activities are performed by the involved entities, and what information or artifacts are exchanged by them. These elements describe the coordinative aspects as well as the operative aspects of work and thus, can be considered the minimal set of conceptual elements necessary to describe collaborative work (Fjuk and Dirckinck-Holmfeld 1997). This assumption has been backed by the development of business process modeling languages over the last few years, where the focus has shifted from functional approaches (e.g., Event-driven Process Chains (EPCs); Nüttgens and Rump 2002) to approaches that structure process descriptions along the involved entities and explicitly allow them to express their interaction (e.g., BPMN (Business Process Modeling Notation); White and Miers 2008 or S-BPM (Subject-oriented Business Process Management); Fleischmann et al. 2012).

The mentioned interaction-oriented modeling languages are designed to describe complex business processes, covering all their variants and potential exceptions. The modeling constructs introduced to handle this complexity, however, are not required for the articulation approach proposed here (Oppl 2018). Starting articulation with a case-based narrative approach avoids the need for control-flow constructs beyond describing sequences of activities and interaction with others. This reduces the number of modeling elements to make modeling easier for non-expert modelers. Based on empirical data collected on practitioners’ use of BPMN 2.0, Muehlen and Recker (2008) show that for interaction-oriented modeling of organizational work processes, at most the following constructs are used: Task and sequence flow to indicate what is to be done in which sequence, pools to indicate who is doing what, message flows to couple the process parts in the pools, and events indicating the start and end of the process. Abstracting from BPMN notation, the modeling language proposed here consequently consists of the following three modeling elements (cf. Fig. 3.7):

  • WHO–element: representing actors, roles, or organizational entities (exact semantics depending on the level of abstraction individually chosen for modeling) (➔ ‘pools’ in BPMN or ‘subjects’ in subject-oriented modeling)

  • WHAT–element: representing activities (➔ ‘tasks’ in BPMN or ‘states’ in subject-oriented modeling)

  • EXCHANGE-element: describing exchange of information or artifacts among WHO-elements (exact semantics depending on designator for element) (➔ ‘message flow’ in BPMN or ‘messages’ in subject-oriented modeling)

Fig. 3.7
The three elements of card-based modeling language are W H O elements representing actors 3, 1, and 2. what element, and exchange element.

Elements of the card-based modeling language

These elements are put into mutual relationship by spatially arranging them as follows (cf. Fig. 3.7):

  • Each WHAT-element is assigned to a WHO-element by placing it on an imaginative straight line originating from the WHO-element (➔ assignment of ‘tasks’ to ‘pools’ in BPMN or definition of a subject’s internal behavior in subject-oriented modeling)

  • Causality between WHAT-elements is expressed by their order on the line starting with the one that is placed nearest to the WHO-element (➔ ‘sequence flow’, ‘start event’, ‘end event’, in BPMN or refinement of a subject’s internal behavior in subject-oriented modeling)

  • EXCHANGE-elements are placed between the lines of the communicating WHO-elements and are causally related in the stream of WHAT-elements by spatial arrangement, explicitly adding connecting arrows from the activity in which or after which the exchange is triggered and to the activity that receives or is triggered by the exchange (➔ ‘message flow’ in BPMN or definition of the interaction among subjects in subject-oriented modeling)

As shown above, the proposed language covers the elements used for interaction-oriented modeling for organizational work processes as identified by Muehlen and Recker (2008) and can be unambiguously mapped to formal business process modeling languages such as BPMN or subject-oriented process models. The number of elements has to be reduced and assigned clearly distinguishable semantics in order to meet the articulation needs of inexperienced modelers (Genon et al. 2011).

3.2.2 Articulation Process

The following spatial layout is used for the different elements described above to create a consistent form of model representation (Oppl 2015):

  • WHO-items are placed on the upper border of the modeling surface, and indicate the role represented by the actor and those roles with which the modeler is perceived to interact directly.

  • WHAT-items are placed below the WHO-item representing the role of the actor, and describe the actor’s own activities. Their sequence indicates causal and/or temporal relationships.

  • EXCHANGE-items are placed below the WHO-items of the other roles. They indicate expected exchange of information or artifacts. Their spatial arrangement indicates the causal and/or temporal relationship to the stream of WHAT-items:

    • EXCHANGE-items placed slightly above a WHAT-item indicate expected incoming information or artifacts. In case of ambiguity, this relationship can be made explicit by drawing an arrow connecting the EXCHANGE-item with the WHAT item requiring this input.

    • EXCHANGE-items placed slightly below a WHAT-item indicate offered outgoing information or artifacts. In case of ambiguity, this relationship can be made explicit by drawing an arrow connecting the WHAT-item producing this output with the EXCHANGE-item.

Figure 3.8 shows the three individually articulated models for the sample process. WHO-items are represented in blue, WHAT-items are red, and EXCHANGE-items are yellow. As an example, the model of actor 2 is described in narrative form in the following: the secretary perceives that he has to interact with his colleague and his boss to complete his role in the process. He expects to receive a completed application from the colleague to be able to start his contribution. He checks for conflicts with other submitted or already confirmed applications. The checked application is then forwarded to the boss. The secretary proceeds, as soon as he receives the confirmed application back from the boss. He then files the application and forwards the confirmation to his colleague.

Fig. 3.8
The sample result consists of three sections. section 1, employee and secretary. section 2, colleague, secretary, and boss. and section 3, secretary and manager.

Sample result of individual articulation

Figure 3.8 also shows semantic differences between the models on the level of WHO-elements (e.g., ‘boss’ vs. ‘manager’) and on the level of EXCHANGE-elements (e.g., ‘form’ vs. ‘completed application’ or ‘decision” vs. “confirmed application”). These differences reflect different perceptions of the work process. They are addressed in the next phase, where the individual models are consolidated into a commonly agreed-upon model. This process of consolidation is described in Chap. 4. It results in an interaction-centric model of the perceived overall process of the articulated work case as shown in Fig. 3.9.

Fig. 3.9
The result of collaborative consolidation consists of the cards of employees, secretaries, and managers.

Result of collaborative consolidation

3.2.3 Mapping to Subject-Oriented Models

The modeling approach described above has been designed to lead to models that are transformable to models created with role-aware, communication-oriented business process modeling languages such as S-BPM (Fleischmann et al. 2012) or BPMN (White and Miers 2008). The mapping from the card-based model to the target S-BPM business process model is homomorphic (i.e., fully represents the structure of the case-based model in the target S-BPM model). By applying specific transformation rules, the S-BPM model is syntactically correct. Syntactic correctness allows to further process the model with tools designed for S-BPM (cf. Krenn and Stary 2016; Oppl and Rothschädl 2014). The mapping rules are described in the following. Figure 3.10 shows a mapping from a card-based model to an S-BPM model and presents examples of the application of rules given below at the locations of the dashed-outline circles.

Fig. 3.10
A text box illustration depicts the transformation from card-based management to subject-oriented business process management.

Transformation from card-based to S-BPM model

Syntactically valid and semantically equivalent S-BPM models can be derived from card-based models by applying the following set of rules:

Creating the behavior diagrams for each identified WHO-element is performed by applying the following rules in the given sequence (cf. numbers in dashed circles in Fig. 3.10):

  1. 1.

    WHO-items map to S-BPM subjects. For each WHO-item, a behavior diagram is created.

  2. 2.

    WHAT-items map to S-BPM function states. For each WHAT-item, an S-BPM function state of the same name is created in the according S-BPM subject. The according S-BPM subject is identified by tracing the imaginary line running vertically through the activity card up to the upper border of the model, where the heading WHO-item corresponds to the according S-BPM subject.

  3. 3.

    Causal relationships between S-BPM function states are identified in the original model by tracing the imaginary line running from heading WHO-item vertically down through the WHAT-items. Two vertically adjacent WHAT-items map to an S-BPM state transition from an S-BPM function state mapping to the upper WHAT-item to the S-BPM function state mapping to the lower WHAT-item.

  4. 4.

    The top-most WHAT-item placed below a WHO-item, maps to the S-BPM start function state of the according S-BPM subject.

  5. 5.

    The lower-most WHAT-item placed below a WHO-item, maps to the S-BPM end function state of the according S-BPM subject, except if the WHAT-item is the origin of a connection to an EXCHANGE-item (see next rule).

  6. 6.

    EXCHANGE-items connected to a WHAT-item by a directed connection originating from the WHAT-item are mapped to an S-BPM send state in the S-BPM subject mapping to the WHO-item to which the WHAT-item belongs. The S-BPM send state is inserted after the S-BPM function state representing the originating WHAT-item. The S-BPM send state is named ‘sending <name of EXCHANGE-item>’. The S-BPM send state is connected with an outgoing state transition to the S-BPM state that maps to the WHAT-item placed below the originating WHAT-item.

  7. 7.

    If the originating WHAT-item is the last element in its sequence of WHAT-items, an additional S-BPM function state is inserted in the according S-BPM subject as a dummy end function state (as send states cannot terminate the internal behavior of an S-BPM subject).

  8. 8.

    EXCHANGE-items connected to a WHAT-item by a directed connection originating from the EXCHANGE-item are mapped to a S-BPM receive state in the S-BPM subject mapping to the WHO-item the WHAT-item belongs to. The S-BPM receive state is inserted before the S-BPM function state representing the targeted WHAT-item. The S-BPM receive state is named ‘receiving <name of EXCHANGE-item>’. The S-BPM receive state is connected with an incoming state transition to the S-BPM state that maps to the WHAT-item placed above the targeted WHAT-item.

The subject interaction diagram is created based on the following two rules:

  1. 1.

    WHO-items map to S-BPM subjects. For each WHO-item, an S-BPM subject of the same name is created.

  2. 2.

    EXCHANGE-items map to S-BPM message elements. For each EXCHANGE-item connecting two WHAT-items assigned to two different WHO-items, an S-BPM message of the same name is created between the according S-BPM subject elements.

The application of these rules introduces additional elements to the S-BPM model, which were not present in the original card-based model. Rules 6 and 8 add send- and receive-states to the S-BPM model. These model elements are only contained implicitly in the card-based model and are derived from the connection points between EXCHANGE- and WHAT-elements. Rule 7 introduces a dummy function state for internal behaviors that would end with a send state. This is necessary as in S-BPM models, the outgoing message information is not attached to the send-state itself, but to the following transition.

Conditional execution of process parts in internal behavior is not considered during transformation, as the card-based models due to their nature as a case-based approach do not support modeling of decisions at all. This semantic limitation is addressed after transformation to a subject-oriented model by refining it via simulated enactment (cf. Oppl 2017). This approach is described in Chap. 5.

3.3 On the Go: Capturing Functions and Interactions While Working

The capturing approaches described above allow for work knowledge representation even by inexperienced modelers and thus enable stakeholder involvement in work design processes. Knowledge capturing, however, does not always necessarily start in dedicated modeling sessions, but might already be triggered during the work process itself. This enables the capture of undistorted models of the actual flows of work that might not be obtainable during ex-post reflective modeling sessions. In-work modeling activities, thus, can provide the basis for follow-up dedicated articulation sessions, but are inherently disruptive to the actual work process (Hoppenbrouwers et al. 2018). We thus propose to mitigate the potential negative impacts of modeling while working by using an instrument that supports process knowledge capturing based on the thinking-aloud method (Van Someren et al. 1994).

Such an instrument needs to be minimally invasive and allow instant capturing and processing of work knowledge. As the articulation process is actor-centric, the instrument in particular needs to be self-contained, in order to encapsulate behavior specific to a subject, and be individual, since each stakeholder should be able to express his/her way of accomplishing tasks. In order to capture both, interactions and functions performed by stakeholders and the systems they work with, it needs to enable encoding technical activities the same way as sending and receiving messages, since they are considered to be of equivalent importance for representing role- or task-specific behavior.

We therefore devise a scheme that closely resembles the representation presented in the former section, but is even more focused in terms of semantics. Actors only distinguish between individually performed activities and interactions with others. These distinct modes of operation during a work process are identified, noted down, and put on a stack. The stack (in reverse order) represents the sequence flow of the activities and interactions of a single stakeholder in a particular instance of a work process. This information can be used as an input for card-based modeling as described in the last section and so provide the foundation for fully specified subject-oriented process models.

Modeling can be performed using physical cards or a tablet application. The latter can further reduce the effort for capturing by providing scaffolds and ad-hoc checks of the consistency of the captured information (Lerchner and Stary 2016). In both cases, stakeholders start articulating by moving a yellow or green card on the heap to the left (cf. Fig. 3.11, ‘A’). A card represents a step of a work procedure. Its specification requires the input of the respective data, in particular, the activity performed (yellow card), or the information to be exchanged, the communication partner, and the direction of interaction (green card).

Fig. 3.11
A photograph displays a person moving cards on a tab. The current user role, description of activity, and information about things that will be exchanged are marked on the screen.

Process capturing

For each step, an actor needs to decide whether the activity to be modeled is a direct manipulation task, such as calculating data in a customer order form, or is part of an interaction with other actors, for example, contacting a Customer Service Agent to provide further order details before being able to calculate the data.

After providing the data for either card, it needs be moved to ‘A’, in order to generate a stack of activities. A card can be moved interactively by touching it on the display in the area indicated with the red dot. In case a different card should have been moved to ‘A’, all the other cards can be put aside, namely moved to ‘B’, until the intended position is reached in stack ‘A’. In this way, re-arranging a set of already captured process steps in the heap is enabled preserving the relevant order.

In this way, a first round of reflection can be supported. This feature becomes relevant, once the introspection of an actor reveals either he/she feels more confident when changing the originally modeled sequence, or once he or she has been forced to perform a certain sequence of steps due to external interference rather than his/her original intention.

In the tablet app, several process models (i.e., stacks) can be edited in parallel, as each user can switch between active modeling sessions by activating another process model. The double arrow symbol on top of the screen indicates that capability.

As context plays a crucial role for representing the behavior of stakeholders, the app enables the storage of context, both, for each activity represented by a card, and for each process model. Both can be enriched with text, audio, images, or video information. Context information may capture background information or additional data for decision making. The input of context information is enabled by the box symbol. It is displayed empty in case no context information has been provided so far, otherwise, it reflects the status as being non-empty.

In order to reduce the effort filling the cards with the required information, the tablet app provides a ‘favorite’-function. It enables users to select cards with prepared content from previous modeling sessions for the stack of yellow or green cards on the right side on the main screen. Once moved to the corresponding stack on the right hand side of the screen, the selected card can be further edited. This functionality is intended for capturing routine tasks and routine communications and works across processes.

3.4 Capturing Tangibles and Intangible Exchange Relationships

We have now presented different approaches to articulation of work knowledge using an actor-oriented and interaction-centric form of representation. Once articulation of work knowledge refers to stakeholders and their patterns of individual and collaborative behavior, we could take a closer look on the type of collaboration in which stakeholders are involved. A fine-grained understanding of interaction patterns could lead to better alignment of functional roles and their encoded work procedures. In the following, we review an articulation approach aiming to reveal both, formal and informal relations between stakeholder roles. They are captured as part of a value network.

3.4.1 Organizations As Transactional Networks of Roles

When introducing Value Network Analysis (VNA), Allee (2008) aimed at developing organizations or networks of organizations beyond the traditional value chain as mentioned in the introduction of this section. Traditional value-chain models represent a linear, if not mechanistic view of business and its operation. Complex constellations of values, however, require analyzing business relationships taking into account the role of knowledge and intangible value exchange as a foundation for value creation. Value exchange needs to be analyzed before changing business transactions in practice. In particular, complex relationships require pre-processing from a value-based perspective, as they influence effectiveness and efficiency, and possible friction in operational processes (ibid.).

VNA is meant to be a development instrument beyond engineering, as it aims to understand organizational dynamics, and thus to govern structural knowledge from a value-seeking perspective, for individuals and the organization as a whole. However, it is based on several fundamental principles and assumptions (Allee 1997, 2002, 2008; Allee et al. 2015):

  • Participants of an organization and organizationally relevant network actors participate in a value network by converting what they know, both individually and collectively, into tangible and intangible value that they contribute to the network, and thus to the organization.

  • Participants accrue value from their participation by converting value inputs into positive increases of their tangible and intangibleassets, in ways that will allow them to continue producing value outputs in the future.

  • In such a network, each participant contributes and receives value in ways that sustain both their own success and the success of the value network as a whole. This mutual dependency is a condition sine qua non. Once active participants either withdraw or are expelled, the overall system becomes unstable and may collapse, and need to reconfigure.

  • Value networks require trusting relationships and a high level of integrity and transparency on the part of all participants. Then, insights can be gained into interactions by identifying and analyzing not only the patterns of exchange, but rather the impact of value transactions, exchanges, and flows, and thus, the dynamics of creating and leveraging value.

  • A single transaction is only meaningful in relation to the system as a whole. It is set by role carriers who utilize incoming deliverables from other role carriers (inputs) and can assess their value, and they realize value which is manifest by generating output.

As network actors—in roles relevant for business—are responsible for handling their relations to others, the organization itself needs to be conceptualized as highly dynamic complex setting. In the following, we detail the underlying concept and methodological approach.

VNA builds upon organizations as self-adapting complex systems. These systems are modeled from that perspective by

  1. 1.

    Identifying patterns of interactions representing tangible and intangible relations between network actor roles

  2. 2.

    Describing these patterns in a structured way, recognizing

    1. (a)

      Sources and sinks of information exchanged between network actor roles

    2. (b)

      The impact of received information and objects

    3. (c)

      The capabilities of produced and delivered assets

  3. 3.

    Elaborating critical processes or exchanges and thus, proposing changes, from both a cognitive perspective and the flow of energy and matter

In line with the living systems perspective, VNA assumes that the basic pattern of organizing business is that of a network of tangible and intangibles exchanges. Tangible exchanges correspond to flows of energy and matter. Intangible exchanges, such as knowledge, point to cognitive processes. Describing a specific set of participating network actors and exchanges allows a detailed description of the structure of any specific organization or a network of organizations.

Although VNA considers as fundamental activity the act of exchange, it goes beyond traditional economic understanding of network actor interactions. Exchange includes goods, services, and revenue, but considers the transaction between network actors also as a representation of organizational intelligence, thus as a cognitive interaction process. Transactions ensure successful task accomplishment and business through cognitively reflected exchanges of information and knowledge sharing, opening pathways for informed decision making. Hence, exchanges do not only have value per se, but also encode the currently available collective intelligence, finally determining the current economic success.

3.4.2 Tangible and Intangible Transactions

Since in VNAknowledge and intangibles exchanges are different to tangible ones, they need to be treated specific to their characteristics. Tangible exchanges include goods, services, and revenue, in particular physical objects, contracts, invoices, return receipts of orders, requests for proposals, confirmations, and payments. They also include knowledge, products, or services that directly generate revenue, or that are expected (contractual) and paid for as a part of a service or good.

Intangible exchanges comprise knowledge and benefits. Intangible knowledge and information exchanges occur supporting the core product and service value chain, but are not contractual. Intangibles are extras networkactors in a certain role provide to others to help keep business operations running. For instance, a service organization asks sales experts to volunteer time and knowledge on organizational development, in exchange for an intangible benefit of prestige by affiliation.

Networkactors involved in intangible transactions help in building relationships by exchanging strategic information, planning knowledge, process knowledge, technical know-how, and in this way, sharing collaborative design work, performing joint planning activities, and contributing to policy development. Intangibles, like other assets, are increased and leveraged through deliberate actions. They affect business relationships, human competence, internal structure, and social culture. VNA considers intangibles as assets and negotiables that can actually be delivered by networkactors engaged in knowledge exchange. They can be held accountable for the effective execution of that exchange, as they are able to articulate them accordingly when following the VNA’s structured procedure.

Albeit various attempts to develop new measures and analytical approaches for calculating knowledge assets and for understanding intangible value creation, traditional scorecards need to move beyond considering people as liabilities, resources, or investments. Responsible networkactors need to understand how intangibles create value, and most importantly, how intangibles go to market as negotiables in economic exchanges. As a prerequisite, they need to understand how intangibles act as deliverables in key transactions with respect to a given business model.

Value networks represent organizations or network of organizations as a web of relationships that generates tangible and intangible value through transactions between two or more roles. These roles stem from any public or private organization or sector and stand for individuals, groups, entire organizations, or networks. The network, instead of representing hierarchical positions, structures the dynamics of processing and delivering tangibles and intangibles. Although the roles need to the related to the organization at hand, suppliers, partners, and consumers regardless of their physical location, need to become part of the network once they generate value or receive transactional deliverables.

When modeling an organization as value network several assumptions apply (Allee 2008):

  • An exchange of value is supported by some mechanism or medium that enables the transaction to happen. As organizations can also be considered socio-technical systems, typical enablers are information and communication technologies. For instance, a sales briefing is scheduled by utilizing some specific web application, such as doodle.com.

  • There is provided value: For instance, the provided value of the briefing is based on a tangible exchange of inputs of customer service, and response to inquiries between organizers and participants. The intangibles are targeted news and offerings as well updates on services and customer status (knowledge), and a sense of community (benefit).

  • There is return value: For instance, the value in return is efficiency in terms of short handling time of customer requests as tangible, and informed customer request and feedback on latest developments (knowledge), and customer loyalty (benefits) as intangibles.

Value exchanges are modeled in a special type of concept map (Novak and Canas 2006), termed holomap. The VNA mapping from the observed reality to a holomap is based on the following elements:

  • Ovals represent functional roles of networkactors, termed Participants of the value network, that is, the nodes of the network.

  • Participants send or extend deliverables to other Participants. One-directional arrows represent the direction in which the Deliverables are moving during a specific Transaction. The label on the arrow denotes the Deliverable.

When networkactors create holomaps, they think of Participants as persons they know carrying out one or more roles in the organizational system at hand. Holomapping is based on the assumption that only individuals or groups of people have the power to initiate action, engage in interactions, add value, and make decisions. Hence, VNA Participants can be individuals, small groups or teams, business units, whole organizations, collectives such as business networks or industry sectors (networked networks), communities, or even nation-states. VNA does not consider databases, software, or other technology as Participant. It is the decision-making capability about which activities to engage in that qualifies only humans as VNA Participants.

Transactions or activities are represented by an arrow that originates with one Participant and ends with another. The arrow represents movement and denotes the direction of addressing a Participant. In contrast to Participants, which tend to be stable over time, Transactions are temporary and transitory in nature. They have a beginning point, a middle, and an end point.

Deliverables are those entities that move from one Participant to another. A Deliverable can be physical or tangible, like a document or a physical object. A Deliverable can also be non-physical, such as a message or request that may only be delivered verbally. It can also be an intangible Deliverable of knowledge about something, or a favor.

In VNA, an exchange only occurs when a Transaction results in a particular Deliverable coming back. A gap is considered in a case when something is provided without anything being received in return. However, focusing on the exchange as the molecular element of value creation is a generic concept that enables capturing a variety of organizations as value networks. Tangible and intangible exchanges establish patterns typical of business relationships. In many cases, tangible exchanges comprise exchanges of matter and energy (goods and money), while the intangible exchanges capture cognitive and emotive exchanges such as favors and benefits.

In the following, we exemplify a VNA case in Sales and Presales from different organizational units of a networked service company providing innovative instruments (methods and technologies) for knowledge acquisition and sharing. Due to a merger with another company, Presales should complement the service chain of the company providing all other services, including Sales. In order to understand the overall patterns of exchange and determining the impact of tangible and intangible inputs for each Participant, the merging companies decided to perform a VNA. It should not only help in analyzing the state of affairs, but also leverage potential changes for each Participant. Sales and Presales aim to improve their ability to utilize operation and customer feedback in further developing their services, although stemming from different organizations.

The first step Participants need to consider in the modeling process are all the roles, organizational units or work groups, both internally and externally, that are considered of relevance in the activities of the Sales and Presales group. In this case, three networkactors (Participants) inside the organization, namely Sales, Product Development, and Customer Service, and two networkactors, Presales and free-lanced Interviewers of different organizations are identified. They represent the nodes in the holomap in Fig. 3.12.

Fig. 3.12
A sample holo map for improving sales and presales relations depicts the interconnections between sales, presales, customer service, interviewer, and product development.

Sample holomap for developing Sales and Presales relations

For modeling, first, networkactors need to think about tangible exchanges that take place between the Participants. What are the Transactions adding value? What are the tangible Deliverables in the work system? Figure 3.12 shows tangible Deliverables such as product information, feedback from market, requests, and updates. For these cases, the transaction and communication channel is considered a tangible Deliverable because it either comprises core data relevant for operating the business, or affects essential relations to organizational units for product and (customer) knowledge management.

Intangible transactions or exchanges are modeled the same way. In order to distinguish the intangible Deliverables from the tangible Deliverables, modelers use a different line style (dotted line in Fig. 3.12). For the original service provider, intangibles are incomplete information, order handling report, customer report, customer preparation data and so on, which various networkactors make available through reporting and active sharing of knowledge (see Fig. 3.12). They are considered intangible because there is no direct monetary income related to them. They are neither contracted by the provider nor expected by the recipients. They are extra offerings to Participants to keep the operation running, and product development informed, mainly based on informal learning, and experiential knowledge.

As shown in Fig. 3.12, several tangible exchanges occur, for example, Product Development provides product announcements to Presales in exchange for feedback from the market, Sales provides requests to Interviewers who acknowledge them. In addition, several intangible exchanges occur, such as Interviewers provide customer information to Customer Service in exchange to customer reports. The latter complements the formal, role-specific exchange specified through the pair ‘request for clarification—interview data’. It documents the intention to provide a comprehensive picture of customers in order to build trustful relationships to customers (representing the benefits of the exchange).

However, several one-sided transactions with respect to tangibles and intangibles become evident, as also shown in the holomap in Fig. 3.12: For instance, concerning intangibles, the Interviewers provide customer preparation data and quality reports to Presales and Product Development, respectively, without any intangible return. Concerning tangibles, for example, Product Development provides both, product information and updates to Sales without any return.

Once all exchanges and Deliverables are captured in the holomap, a diagram of how the business is perceived from a networkactorperspective is established. The value networkview of an inter-organizational network helps understand the role of knowledge and intangibles in value creation. The modeling process allows capturing strategically critical intangible exchanges from a networkactorperspective, thus, enabling further targeting opportunities for value creation. This issue is addressed through analyzing the value network as represented by the holomap using three different types of analyses and will be discussed in Chap. 5.

3.5 Cross-Cutting Issues

Table 3.1 gives a structured overview on the reviewed techniques of this chapter. It structures each approach according to its

  • focus revealing its objective

  • understanding of organization as a cognitive construct

  • means of representation, in order to document work knowledge

  • procedure to follow for articulating work knowledge

Table 3.1 Value-oriented articulation approaches

Value-based articulation can thereby range from natural language-based documentation to highly structure-determined approaches. They require role-specific behavior recognition and various levels of detail in specifying individual and collective behavior.

Considering the requirements and subsumed procedural cornerstones from Chap. 2, we can reflect on the results of this section in a structured way. The reflection takes into account individual engagement of actors, as well as the activities on the collective level with respect to organizing work. In Table 3.2, we revisit the list of requirements as given in Chap. 2 and elaborate on them according to relevant properties for each presented articulation technique.

Table 3.2 Elicitation requirements and subject-oriented articulation

From a procedural perspective, subject-oriented articulation can be assigned to the following phases:

  1. 1.

    The preparations require (i) determining the scope of articulation, for example, a specific business case, an organizational structure of work, (iii) identifying the actors as role carriers, since their behavior needs to be specified in terms of subjects, (iii) explaining the subject-oriented notation and tools for articulation, for example, how to structure natural language sentences, paper, pencil, and a diagrammatic editor for documentation, and (iv) providing a facilitator to effectuate the articulation procedure.

  2. 2.

    Situation-sensitive articulation features are subject constellations (represented in Subject-Interaction Diagrams), enabling stakeholders to externalize their knowledge on roles and work tasks as they experience it, from a functional and interactional perspective.

  3. 3.

    Looking beyond what-is/addressing situations-to-be: The various points in time to articulate work knowledge allow flexible application of the approach. Facilitation should encourage stakeholders to revisit existing patterns, to rethink the role assignments to subjects, and to generate novel patterns of work interaction capturing situations of relevance. The facilitator can develop proposals to trigger modification of existing models.

  4. 4.

    Representationalalignment: The subject-oriented notation and specification scheme enables consolidating individual perceptions and specifying interaction patterns. Both enable stakeholders to change patterns of behavior, either internally for each subject, or externally by redefining interaction patterns.

  5. 5.

    Organizational alignment can be achieved through consensus-finding among the concerned subject carriers or stakeholders, once elicited knowledge is represented and discussed how to embody the generated knowledge in the workspace of the organization at hand.

Table 3.3 discusses the requirements with respect to card-based elaboration.

Table 3.3 Elicitation requirements and card-based elaboration

From a procedural perspective, card-based elaboration comprises several phases:

  1. 1.

    A preparation of the setting, actors, and instruments. In case of card-based articulation this step includes (i) determining the scope of elicitation, which is mainly a business case involving several stakeholders, (ii) a physical surface and/or digital media support as articulation environment, (iii) the cards, paper, markers, and/or building blocks as tangible material, and (iii) actors willing to articulate role-specific behavior for the selected business case, and engage in sharing and reflecting on the underlying mental models, (iv) a facilitator to guide the articulation procedure and introduce the corresponding material and environment(s).

  2. 2.

    Situation-sensitive articulation features comprise the (physical) surface as articulation environment, the notational elements (cards, paper, markers, building blocks, relations) in order to describe and document work knowledge in the course of articulation.

  3. 3.

    Facilitation is required (i) to set the stage involving stakeholders as role carriers, (ii) to ensure the correct use of notational elements, and (iii) to identify situation correspondence (as-it-is, to-be), and (iv) tutor the use of (digital) media.

  4. 4.

    Representational alignment might need to be facilitated when the participants aim to consolidate their findings into a shared representation.

  5. 5.

    Organizational alignment needs to be documented when the participants envision how elicited work knowledge should become part of future organizational designs.

Finally, we discuss how the requirements are addressed in value network specification in Table 3.4.

Table 3.4 Elicitation requirements and value network-based articulation

From a procedural perspective, the elicitation phases are instantiated as follows:

  1. 1.

    The preparation comprises the setting, actors, and instruments. The scope is a subset of a specific business operation, usually a core business case, and some physical space or digital tool as articulation environment. The participants need to be willing to articulate formal and informal work knowledge, and engage in common reflection, eventually guided by a facilitator explaining the topology, node, and relation types.

  2. 2.

    Situation-sensitive articulation features are roles and their formal and informal relations, termed tangible and intangible transactions. Value network can be designed individually or in a shared environment involving different people externalizing their knowledge on roles and their interactions.

  3. 3.

    Facilitation includes encouraging stakeholders to look beyond well-known connections between role carriers, besides explaining the network topology, nodes (i.e., actors), and relation types representing deliverables.

  4. 4.

    Representational alignment is only required in case a consolidated network representation needs to be achieved for further development.

  5. 5.

    Organizational alignment is not concerned as the network representation is constructed for a situation as-it-is.

Cross-checking the presented articulation technique, each of the presented techniques has its focus on role-specific behavior and allows representing interaction patterns between roles. For complex networked systems, subject-oriented elicitation provides a comprehensive while structured way to approach elicitation by human-centered means, as it starts with natural language before focusing on a dual representation of work knowledge. Card-based elaboration follows the same line, but might be limited to physical constraints when being performed without digital support—a dilemma it shares with subject orientation in case the granularity and choice of media is not appropriated to both. Value networking follows a declarative perspective throughout articulation, in contrast to subject-oriented and card-based elicitation. As a result, the exchange patterns refer to work deliverables likely subsuming the data-driven exchange of subject-oriented or card-based elicitation. In addition, intangibleassets can be represented in addition to tangible ones, whereas subject-oriented or card-based elicitation mainly target explicitly encoded ones. In terms of articulation procedure, subject-orientation and value networking start from an interactional perspective and (in the case of subject-orientation) detail on behavioral implications of interactions in a subsequent step. Card-based modeling initially focuses on individual behaviors contributing to an overall work process and derives interactions in a follow-up step when matching the mutual dependencies encoded in individual behavior models.