Preparation of Process Implementation

The aim of the process preparation in the sense of a subsequent implementation is a precise description of the process with a description of the process strategy and process logic. The preparation includes the activity bundles on the left side of the open cycle, i.e., analysis, modeling, validation and optimization (see figure below). The result of these activity bundles is a process description that is sufficiently precise for implementation. The preparation is split into the activities analysis combined with modeling, validation, and optimization. These activities are not carried out in a strict order, but rather the respective priorities can change frequently between activities. Figure 6.1 shows these various activities and their relationships


Analysis and Modeling
Analysis and modeling cannot be sharply separated. The analysis focuses on the strategic aspects of processes, while modeling focuses on the process logic. In the analysis the starting point with its associated input, the end state with its generated output, and the therewith satisfied customer needs are clarified. In the analysis, the framework and the essential aspects of the process logic are also defined. In practice, however, the process logic of the actual state is hardly explicitly described when revising processes in this phase. The analysis of the current process logic is accomplished within the framework of the definition of the desired target process. An exclusive reference to the current situation usually makes little sense and is also as a rule unpleasant for all participants to document -What has been "done wrong" lately?
As long as one is using the tool 'natural language', the focus is more on the activity of analysis than on that of modeling. The transition from natural language to a more formal process modeling language corresponds to the transition to modeling activities. The modeling can be preceded by a more or less intense analysis method. In extreme cases, a process model is immediately created without prior natural linguistic analysis. However, it is recommended that at least the strategic aspects of the process under consideration are known and defined.
In the following, guidelines for the articulation and coordination of processrelevant knowledge, which can be supported methodically and tool-wise, are presented. An essential element is the understanding of roles which the participants consider relevant for the handling of processes. In addition, it is advisable to consider the exchange relationships between actors, to evaluate their quality for the further design of processes and, if necessary, to derive potential for change from this information.

General Information on Articulation and Coordination
In most cases, knowledge about workflows and organizational processes rests in the minds of the actors. A context-sensitive, structured survey and analysis is therefore of crucial importance. The survey serves to articulate experiential knowledge and in most cases is carried out within the framework of modeling. However, if it is already handled in advance, the variety of approaches to solving tasks or problems in BPM projects can be dealt with in a more structured way. Nevertheless, in the context, the coordination and alignment of different approaches plays an essential role. Supporting these contributes significantly to the development of solutions that are capable of integration, despite a high degree of diversity and individual approaches to the fulfillment of tasks. This section therefore deals with the survey and negotiation methods and instruments that enable individuals to articulate within the framework of collective reflection and negotiation processes. How people carry out their work, how they react to perceived specifications or deviations and how they cooperate with others is essentially determined by their perception of organizational reality. The interpretation of the perceived determining factors as well as the derivation of the reaction considered adequate of the acting workers can be explained by the cognitive theory of mental models. This theory can also be used as a basis for explaining learning and change processes in organizations that are initiated by operatively active persons. In this section, it therefore forms the basis for the derivation of measures which should enable workers to become aware of their work processes and the organizational interrelationships and determining factors characterizing them.
The concept of "mental models" is used to explain how people understand the world -more precisely: how they use their knowledge to make certain phenomena of the world subjectively plausible [1]. Mental models are explanatory models of the world that are formed by people on the basis of everyday experience, previous knowledge, and conclusions based on these. A mental model is used by each individual as a basis to understand the world and, if necessary, to make predictions about its behavior [1].
The knowledge that shapes mental models can be based on everyday experience or can be founded on conveyance or instruction. Seel [1] describes the modification and expansion of one's own knowledge bases and the (further) development of the cognitive abilities necessary for drawing conclusions as "learning". Learning is linked to the processing of individual experiences with, and information about, the world, its structure and evidence, and can be understood as a process of permanent conceptual change [1]. Learning thus presupposes the ability and willingness to understand and accept conveyed world views and then to base one's own mental constructions on them [1].
There are two basic difficulties in changing mental models about work processes. In the case of mental models that have already been recognized as inadequate, there is a fundamental willingness to change (in the sense of adapting the mental model to the environmental conditions perceived as changed), but the challenge is to obtain the necessary information and have it adequately presented. A further difficulty arises in situations in which not all individuals involved perceive the situation as 'problematic' and therefore show no fundamental willingness to change their underlying assumptions with regard to their way of working (i.e., their mental models). This occurs especially in situations where collaborative reflection is not carried out from a generally perceived problem situation, but is either initiated with a purely planning character, or in situations which are perceived as 'problematic' only by certain individuals involved.
These problems can be countered with explicit support for the reflection process. Such support must ensure that artifacts are created to represent the individual mental models, which can then serve as the basis for mutual understanding of the respective views on the work process. Such artifacts can serve to coordinate aspects of a work process and to ensure that the ostensive view of a work process encoded in artifacts can be implemented in work practice through performative subjective action knowhow based on it. From a methodological point of view, it must be ensured that all persons involved in the real work process are organizationally and methodologically capable of participating in the collaborative learning process. This requires above all that they can understand and actively use the forms of expression utilized. This, in turn, is a learning challenge that must be explicitly addressed.
A widely accepted option for externalizing and harmonizing mental models in the educational sciences is the formation of conceptual models. At the same time, such models can form the basis for the specification of work processes and the configuration of work support systems, as long as they make use of a formally specified semantics (such as BPMN or S-BPM). In accordance with the objective of this section, conceptual models thus represent a means of enabling workers to reflect on their work, to coordinate it, to make the results of these coordination processes accessible to third parties, and to make them usable within the framework of existing system boundaries to support their own work processes.
Models are representations of reality that are provided for a particular purpose. Models never represent the real phenomenon as a whole, but contain only those aspects of reality that the modeler considers relevant for the achievement of the respective goal. For modeling, this raises the question of the defining power of these models and the social reality they represent. If a model does not only fulfill an objective of the modeling individual, but is used by other persons, the model influences the mental models of these persons, and thus also their behavior.
The active involvement of operative workers in the specification of work processes is therefore an opportunity for their self-empowered development of organizing their work. To this end, however, it is necessary to enable workers to understand such models, to design them by themselves, and to assess their impact on their work processes. Current approaches, on the other hand, continue to assume the need for a process analyst who translates the views of workers into a process model. This can lead to deviations between the real work process and its model representation. In addition, this approach deprives the operatively active persons of the opportunity to sharpen their mental models in the sense of model-based learning and to coordinate them with those of the other participants.
In order to enable workers to understand such models, the learning of basic approaches to the creation and interpretation of conceptual models must be the subject of education or training. Workers must be able to identify the models underlying the systems in which they are embedded. In addition, they should be able to assess the implications of external or self-implemented changes to these models and to plan interventions accordingly.
For this purpose, the following points need to be methodically supported: to enable the individual articulation of one's own mental models with respect to work in order to enable individual reflection and thus to make gaps and inconsistencies individually perceptible, as well as to prevent that perspectives of individual persons are not taken into account and that these cannot subsequently establish a reference to their working reality to support the agreement on a common vocabulary in order to identify different understandings of terms and subsequently to be able to communicate clearly about the work in question and to prevent the same real phenomenon from being described by different terms -or vice versa the same term from being used for different real phenomena to support the development of a common understanding of collaborative work to provide a basis for reflection of individual mental models in the context of the above, to enable the identification and resolution of conflicting points of view, in order to make differences in those mental models that directly affect collaboration between workers visible, and to facilitate their coordination.
The following sections show some of the methods used to implement these requirements.

CoMPArE/WP
The requirements described above are implemented exemplarily in the "CoMPArE/ WP" method. CoMPArE/WP stands for "Collaborative Multi-perspective Articulation and Elicitation of Work Processes". In the application of CoMPArE/WP, the reflection on a real collaborative work process creates awareness of the cooperation in a concrete individual case. Due to its anchoring in concrete work processes, the method is also suitable as a means of organizational development. The form of cooperation of the method is basically determined by its implementation with a card laying technique. The participating operative workers are the essential actors and carry out the components autonomously, whereby articulation and inquiry roles can change. The concrete form of the cooperation differs in the components and is therefore described in the procedure mentioned there. A facilitator is available to support the implementation, but he does not intervene in regard to content.
The method should support the articulation and coordination of mental models with respect to work, and at the same time impart basic skills for their expression in conceptual models. The combination of these two sub-objectives has an impact on the framework of the method. From the point of view of teaching modeling competence, it makes sense to introduce the necessary skills step by step with increasing complexity. From the point of view of articulation support, an approach can be contended in three components. Figure 6.2 gives an overview of these three components.
Component 1 is used to find a common understanding of where and how the work process to be coordinated begins and ends and to find a common vocabulary. Component 2 is used for articulation and reflection of the respective individual work contribution. Each participant creates here a structured model of their point of view on their respective work contribution, individually and without interaction with others. Due to the uniformly structured presentation of the individual contributions, a collaborative alignment of these is possible in component 3. This alignment is intended to uncover conflicting points of view and to create a common view of the overall work process. The objectives of skill development in modeling are anchored in these components. Component 1 aims to convey the verbalization of mental models and the concept formation based on them. In component 2, the description of the verbalized contents must be represented by means of a predefined category scheme and a notation. In doing so, it needs to be determined which elements of the category scheme remain in the responsibility of the articulating individual and which need to be validated and possibly abstracted or become the subject of negotiation during alignment in component 3.
Concrete Implementation of Component 1. It cannot be assumed that all participants have a common understanding of the concepts they use when describing their work. Collaborative concept mapping can be used to align the existing mental models to such an extent that a common vocabulary enables collaboration. In addition, it cannot be assumed that there is a common understanding concerning the borders of the work process to be coordinated. Concept mapping can also help to clarify this issue. In addition to the content dimension, concept maps provide a low-threshold entry into the world of conceptual modeling, since they do not predetermine the meaning of model elements, but rather allow the persons involved to define them during modeling. This facilitates the mapping of the individual mental models into the explicit representation and avoids the necessity of having to carry out a translation to a model with formally defined semantics in addition to the coordination with the other persons involved.
Within the scope of this component, the participants are asked to describe all relevant aspects of the environment in which the work process to be reflected is embedded. This is done by individually writing each aspect on a separate card. When the collected individual aspects are brought together, the cards are arranged in turn on a common work surface. The aspects can be put into relation to each other. Cards with different terms for the same aspect are arranged overlapping. Hierarchical or causal relationships between aspects can be represented by drawing explicit connections, but also by the spatial arrangement of the cards. The example in Figure 6.3, which is used throughout this section to explain the method, shows a concept map with relevant aspects for applying for a vacation in a company. The aspects were related to each other by spatial arrangement. The overlapping elements show aspects that are mentioned by several participants and are described using different terms.
Concrete Implementation of Components 2 and 3. Components 2 and 3 focus on the articulation and alignment of the perceived course of a work process and the associated interaction within this process. The modeling in component 2 is carried out individually by all persons involved, without interacting with others. This avoids overlapping effects and explicitly reveals different perspectives for the next component. The persons involved describe which of their work steps they see as contributing to the achievement of the work goal, with whom they interact and in what form this interaction takes place. The negotiation of a common point of view in component 3 and the associated creation of a common model is again carried out by means of a structured procedure, which is to introduce more complex modeling tasks and guarantees a uniformly prepared model representation. In doing so, the previously created models are used further. The structuring scheme separates those model aspects that remain in the responsibility of the individual worker from those that are the subject of negotiation.
In this step, a structured form of representation with pre-specified semantics is used to represent the work processes. It is based on the current category schemes for the description of collaborative work processes. The categories WHO, WHAT and EXCHANGE (M3) are used. WHO (blue in Figure 6.4) refers to the actors in the work process. WHAT (red in Figure 6.4) is used to describe active contributions in the scope of the work process. EXCHANGE (yellow in Figure 6.4) is used in the context of collaborative work processes to characterize the sharing or exchange of information or material between actors in the context of their own activities. For the sake of usability, these categories are not specified exactly and deliberately leave room for interpretation in concrete use, for example, a WHO element can represent a concrete person, a role, a department or an entire organization. WHAT elements remain the responsibility of the individual participants. WHO and EXCHANGE elements are the subject of coordination in component 3 and must be developed toward a common understanding.
Individual Articulation. In component 2, the persons involved individually describe with the help of the elements, what they contribute in the work process, who interacts with them, and in what form this exchange takes place. In order to support the articulation process, a structuring scheme was developed that prepares the models in a coherent form and allows them to be combined in the next step. As shown in Figure 6.4, the structuring scheme defines the spatial arrangement of the model elements. Operative workers represent themselves through a WHO element, under which the perceived contributions to the work process are placed as sequentially arranged WHAT elements. For all other workers with whom an interaction is Individual models in the presented notation perceived, another WHO element is placed, under which the interaction is specified in more detail by EXCHANGE elements. Their vertical positioning determines whether an incoming resource is expected (placement above the dependent WHAT element) or provided (placement below the generating WHAT element). Figure 6.4 shows three individual models for the example process described above, which were created according to this structuring scheme. In the example, it can be seen that at this point there may be divergent representations with regard to content, especially in the area of exchange elements (cf., "Application" vs. "Completed application" in the figure above). These divergences become explicitly visible in component 3 and are then subject of the negotiation of a common perspective.
Collaborative Alignment. Collaborative alignment is based on the individual conceptional models created in component 2. Figure 6.5 shows an exemplary alignment process for two of the actors represented in the example. The common modeling again takes place on a common work surface (see Figure 6.5 in the middle). The participant, who triggers the real work process, begins by describing his own contributions to the process and adding the corresponding model elements to the surface (steps 1-2 in the following figure).
The other participants intervene here only inquiringly to avoid misunderstandings or to disclose ambiguities. An active participation of the others takes place as soon as the first EXCHANGE element is used (steps 3-4). If a fundamentally common view of the work process exists, one of the participants should be able to introduce a correspondingly assigned EXCHANGE element at this point (steps 5-7).
If this is the case, the description process is continued by this person (from step 8). In the case of a basic fit, which differs, however, in the designation of the element, e.g., by different abstraction levels, this conflicting designation must be resolved, or the semantic equivalence of the two elements must be represented by overlapping arrangement (e.g., step 7). If there is no element to be assigned, fundamental differences in the representation become visible. This may be due to a lack of awareness of the relevance of an exchange, which means that the addressed participant was aware of the interaction, but did not consider it relevant in the context of the work process. However, if a participant's perceived need for interaction is not reciprocated, this must lead to more in-depth alignment processes.
The initial alignment process ends as soon as all of the participants have explained their individual models and added them to the common model. This externalization phase is followed by a collaborative reflection phase, during which the work process is examined on the basis of the common model and discussed with regard to its adaptation to the individual views of the participants. Any necessary modifications are carried out at this point, after consensus has been reached among those affected.
The result of the application of the method now represents a consensual representation of the collaborative work process. Due to the limited expressiveness of the modeling language used, it is not possible at this point to map work variants or decisions that are otherwise common in process descriptions. The decision for a semantically limited modeling language was again made from a didactic point of view, since empirical evidence shows that inexperienced modelers can initially describe their views on a work process more simply narratively on the basis of a concrete case. Decisions regarding the concrete implementation of the work process have already been made in the case-based description. Thus, an explicit representation of the same is not necessary in the scope of the modeling. A complete description of the work process therefore requires a multiple execution of the method or its extension by further refinement steps, which however, will not be considered here in detail.
In the sense of the formation of modeling competence, the focus in component 1 is on the introduction to the abstraction and conceptualization of perceptions of the real world necessary for modeling. In component 2, the representation and reflection of one's own perception of work, guided by structural aids, is captured in conceptual models and their description by means of given structural elements. Component 3 subsequently focuses on model understanding (of the other individual models), interpretation (with regard to their effects on one's own model), and negotiation (of the jointly justifiable view) of model content, which ultimately conveys the competence to influence work processes in a self-empowering way.

Raising Awareness of Process-Relevant Change Potential
In the following, the Value Network Analysis [2] is first discussed, as it was introduced in Knowledge Management for the processing of performance relationships between networked actors, before its potential for process design (analysis and modeling) is detailed.

Value Network Analysis
If we consider, as previously mentioned, the added value of organizations and thus the level of performance-related exchange relationships between actors, tangible exchange relationships can be distinguished from intangible ones in the network of actors within the framework of work processes. Tangible exchange is determined by energy and material flows. Intangible exchange, such as knowledge, refers to cognitive processes and action-guiding information. If now participants and exchange relations are described, the structure of an organization or a network can be captured. Exchange relationships represent the molecular level of economic activities. Thus, value creation does not only consist of tangible transactions, but also of intangible transactions. These relate above all to cognitive exchange, since the sustainable success of an organization is based on the exchange of information, knowledge sharing and open cognitive paths that enable appropriate decisions to be made (and thus the successful existence of an organization). However, knowledge and intangible elements behave differently than physical resources in business life, so they cannot be considered tangibles. Due to their proximity to living systems, they constitute a separate category of exchanges and differ from tangibles related to goods, services and revenues.
Tangible exchange of knowledge is defined as transactions involving goods, services or revenues, e.g., physical goods, contracts, invoices, delivery and receipt confirmations, inquiries, requests, invitations to bid, and payments. It is essential here that knowledge-intensive products and services that generate income and for which payments are made as part of a service or product or on the basis of a contractual obligation are also regarded as tangible transactions.
Intangible exchange of knowledge and performance: Intangible exchange of knowledge and information supports core processes and thus the classic value chain but is not subject to any contractual obligation. Intangibles are 'extras' or (small) courtesies that people exchange in order to build relationships and allow processes to proceed pleasantly or without disturbances. Intangible transactions include the exchange of strategic information, planning knowledge, business-operational knowledge, joint planning activities, collaborative design, and policy development. Intangible transactions are therefore not contractually agreed services for the benefit or support of organizations or their members. They can be extended from one person or group to another, for example, when an organizational unit requests an expert to work temporarily for them in a prestigious position. Recognition often helps in relationship work, so that intangible benefits constitute genuine motivation factors for active participation and engagement in group activities.
Intangibles represent the core of all human action, and thus also determine socioeconomic action. Intangible transactions are deliberately seeded. They can be brought about and recognized. If one wants to understand how intangibles generate value, one must first understand how they become visible and work as negotiables in economic exchange relationships. They are often not immediately visible, but rather 'packaged' in services or products. A typical example is to build an understanding for a customer situation (intangible) before offering a service (tangible). For a joint practice, the smooth running of processes is of immediate importance. Thus, those transactions are essential which (also) guarantee by means of intangibles that a common purpose of action is ensured. This must now be methodically taken into account.
In a Value Network, tangible and intangible values are generated by means of complex dynamic exchange processes between two or more individuals, groups or organizations, which represent the object of reflective design.

Holomapping
The view of organizational value generation based on networking brings with it a new form of organizational modeling; every exchange requires a mechanism or medium as enabler for transactions. These can be tools such as e-mail or face-to-face interactions in communities of practice. As already mentioned above, typical intangibles pertain to knowledge to gain information from customers and feedback on (product) developments.
The representation of tangible and intangible exchange processes in a diagram with flow elements allows the mapping of the dynamics of living systems. First the participants or roles (also groups, teams or organizational units, but not technical aids) are documented -they form the nodes of the network and are visualized through ovals. The participants send or supplement so-called deliverables to other participants. Arrows, which are labeled as the respective deliverable, indicate the direction deliverables take in the course of a particular transaction.
Transactions or activities are displayed as directed edges (arrows), which must originate with one participant and end with another. The arrow indicates movement and the direction in which something is happening between two participants. In contrast to participants, who are time-stable, transactions are time-limited and volatile. They have a starting point, a duration, and a conclusion.
Deliverables, on the other hand, are real 'things' that move from one participant to another. A deliverable can be material (tangible), like a document or a table, or immaterial (not tied to matter), like a message or a request that is only verbally delivered. Deliverables can also be intangible, for example, when referring to knowledge about a certain fact (cognitive) or in the case of a favor (social/emotional). Arrows are only allowed in one direction -they cover a single transaction between participants. Bilaterally directed arrows are meaningless, in fact, they make it impossible to analyze the processes and exchange relationships.
An exchange occurs as soon as a transaction results in a deliverable that is returned. It does not necessarily have to be present in the practical world of action in organizations. However, if it occurs, a Value Network can establish itself, with transactions as molecular elements of value generation.
In the context of change processes, it is essential to empower those involved and thus to have the affected role holders create the communication map with tangibles and intangibles (holomap), as well as to process the data collected by them within the framework of the Value Network Analyses.
Within the scope of knowledge generation or knowledge collection at the beginning of the work on the network structure, each individual participant considers his/her role, which he/she then communicates to the other participants. In this way, relationships and interdependencies between the individual roles, which are often unknown, become more explicit and clearer. The roles are symbolized as nodes, the exchange of material or immaterial values is represented in the form of lines connecting the roles. The modeling forms the basis for the subsequent analyses for knowledge evaluation and processing.

Exchange Analysis
The holomap shows how people use their work as a starting point for exchange analysis. Tangibles (material value flows) in the network refer to the material exchange between persons (typically goods, services and sales revenue). They represent transactions based on contracts. Intangibles (immaterial, ideational value flows), in contrast to tangibles, are based on knowledge or a certain additional benefit. They are not contractually fixed or subject to a charge. Intangibles often collected are strategic information, process or planning knowledge, as well as existing emotional components such as mutual trust, common interest, need for knowledge, security, etc. -see also Figure 6.6.
The exchange analysis examines a Value Network for its conclusiveness, robustness and sustainability. It provides insight into the current structure and dynamics of the network. The following questions should support the exchange analysis: How do the values flow through the organization? Does a certain logic emerge? Is the relationship between the exchange of material and immaterial values balanced or does a certain type of exchange predominate? Does the pattern in the Value Network show reciprocal value flows or are there participants who receive more value flows than they provide? Are there ineffective connections in the network that do not pass on value flows?
These questions are intended to check whether the network fulfills its purpose, whether missing end nodes or links can be detected, and how the structure of the network can be optimized. They ensure a general overview of added value and loss of value. The exchange analysis should serve as a stimulus for dialogue, understanding complex systems, and promoting systemic thinking (cf., [3]). The exchange analysis on customer service, under the assumption that the organization is facebook, shows several findings: Customer service is tangible from the point of view of product development as a sink -it only receives feature list. Sales receives lifestyle information, but no trust-related information. The transmission of uncertainty encumbers the relationship between customer service and sales as well as between customer service and product development. This first evaluation may be an indication of the information management shown in Figure 6.6, where features indeed allow for a certain form of feedback, but where these may be acknowledged by users with requests reflecting uncertainty. Impact Analysis Impact analysis examines the impact of each individual value input on the participants and thus focuses on the recipients of value inputs. This analysis thus shows which input triggers which reactions and activities and how this affects the material and immaterial assets of the recipients concerned. The costs and benefits of value inputs are then assessed as low, medium or high.
In order to gain a better overview of these questions, the answers for each individual recipient of value inputs are entered into a table and the current situation analyzed. The table in Figure 6.7 shows the impact analysis based on the insights gained from the exchange analysis of a customer service employee. The table shows who provides input for which activities and what effects are perceived in the form of material or immaterial value flows. The column entries for the general costs and risks as well as for the benefit of the input addressed are essential for the estimation of change potential.
The data from the initial evaluation (exchange analysis) thus form the basis for the two further analyses, whereby value-based detailed evaluations of transactions are carried out from the point of view of input received (impact analysis) and output transmitted (value creation analysis), and in this way provide insights for change processes.
For example, as can be seen in the table, it is explained when features enable a successful form of feedback, for example, to avoid requests that reflect uncertainty on the part of users. This is the case even if the current benefit of the presentation of features by customer service is estimated to be low due to a lack of comprehensibility.
The entries in the feature list table also show the reference point relevant to value creation, i.e., the quality of information provided to customers by customer service employees.
Based on the as-is analysis, strategic perspectives can then be derived and the table can be filled in again and serve as a comparison with respect to its planned, strategic activities (target analysis). In the present case, for example, a customeroriented information service is of increased importance.

Value Creation Analysis
Value creation analysis analyses how values can best be created, increased and used. Like the impact analysis, the value creation analysis also considers the individual role in relation to the entire system. The difference to impact analysis is that, unlike with input, this time the sender or producer of output is considered in his role and with his related activities.
Each individual sender of value outputs is analyzed to determine how added value and value accumulation are realized in relation to the existing value output. A costbenefit analysis will also be carried out for this purpose.
In the value creation analysis shown in Table 6.1, the results of the work were used to analyze how values can best be created, increased and used. The table shows the analysis based on data from a customer consultant's exchange analysis. Performance indicators can be used to filter out the requirements placed on sales and product development from the analyses. The strategy developed from this can be outlined with the statement 'availability or transparency of information'. As a change measure, it could be decided to increase the identified value creation potential in the Value Network by expanding the tangibles of information flows between all functional units.
After the presentation of the actual situation, the value creation analysis also makes it possible to derive strategic perspectives. Here the question should be asked 'Which possibilities should still be used in the future to generate value optimization in value output?' With regard to the concrete question 'What should be done to increase, expand or optimize the value of output?', the table is filled out in a comparative manner to analyze the target situation.
The entries in the 'costs/risks' and 'benefits' columns are essential for decision support. Here, the assessment can be put into perspective, especially with regard to costs and risks in the target situation, if, for example, content should be included in training courses, since there is know-how for the creation of corresponding training materials and for the provision of effective mediation formats in the network (e.g., in the context 'Report' -third table entry in the table). A target list usually takes into account knowledge about the feasibility or availability of resources and the associated costs for implementing measures, without anticipating a decision in this regard (see evaluation).

Evaluation
For the evaluation, tangibles and intangibles are evaluated in tabular form (impact analysis, exchange analysis, value creation analysis) according to their significance for the respective role(s). These evaluations reveal the effects on relationships and allow targeted measures to be taken.
So far, the exchange analysis has provided insight into the current structure and dynamics of the network. The implementation of the impact analysis allows all participants to deduce their own roles in the network in a context-sensitive way. The impact analysis also provides an overview of the effects each individual value transaction has on the participants. The value creation analysis allows decisions to Typical results of an evaluation to increase added value include the consideration of missing exchange relationships, such as the ones related to the case in question: -Concrete inquiries to customers in order to better understand their concerns (especially those that lead to customer uncertainty) from the point of view of product development and sales -customer service plays a mediating role here, whereby the tangible report can also be upgraded and the feedback can contain concrete suggestions for the improvement or creation of features. -Feedback from customers concerning both the future handling and the previous handling of features, i.e., those issues which affect product development in particular. As soon as the comprehensibility of the presentation is explicitly addressed, an associated flow of information (back) to product development (and also to sales) can be ensured -another measure that facilitates customeroriented access to the product.
Both measures show the necessity of networked representation of exchange relations. It is not necessarily the immediacy of exchange relationships, but rather the concatenation of exchange relationships that can bring about added value. If, for example, product development (e.g., software designers) were to start communicating directly with customers, a certain basis for discussion would first have to be established. Such measures could even be counterproductive to the strategic goal to be achieved and increase the existing uncertainty on the part of customers, thus adversely affecting the desired objective.
The additions to the network thus allow a context-sensitive system view of value creation through material and immaterial services that should flow between the actors involved. The completed Value Network map, as shown in Figure 6.8, forms the basis for further development planning. For the first time, it shows the inquiry to customers as well as the feedback for the purpose of comprehensibility as tangible deliverables, which are intended to increase the knowledge of those involved through the transparency and availability of information. In the long term, as an intangible exchange between customers and customer service, it is important to strive for a mutually secure relationship that can be expressed through customer loyalty to the organization. Only the open exchange of information enables sustainable customer knowledge management.
Value Networks view systems in their entirety and consider their complexity. They enable the holistic identification of both material and immaterial values. In any case, the latter indirectly determine the quality of material exchange relationships and must therefore be taken into account in the development of socio-technical systems. By means of Value Networks the focus on the individuals involved can be captured, which in turn gives them a sense of purpose and fosters their motivation to participate in reflection and actively take part in codesign. The surveys and analyses presented here allow the explication of individual roles and their directly or indirectly perceived contribution to the value creation of an organizational system by actors. This facilitates the clarification of roles and the understanding of correlations, since these are visualized graphically in holomaps by means of value exchange relationships, and are thus fed back role-specifically. As such, they represent a viable starting point for the participatory design of socio-technical systems.  which are considered relevant within the framework of the fulfillment of tasks and the perceived organizational events. Thus, the focus is placed on the way of working and the interaction level. -Within the framework of the development of proposals for change, instead of demands from individual role holders, proposals are made to others in the sense of individual offers to the collective. Such an approach gives the addressee the choice of whether or not to exploit this potential. All offers are presented in the context of their origin and evaluated with regard to their organizational effectiveness by the respective proposing actors. They can then be coordinated collectively on this basis. -Interaction relationships are differentiated according to contractually binding services (tangibles) and not only from the respective role according to contractually regulated services (intangibles). This already makes it evident how tasks are handled, whether more so according to formal principles or interactions that promote successful process fulfillment, or according to informal principles. The same applies to proposed changes, which may also be in formal structures (as part of functional role descriptions), or at informal level (as voluntary contributions). -There are several ways to change an actual situation into a target state: (i) an informal (intangible) interaction becomes a formal part of a role (tangible); (ii) a formal (tangible) interaction is omitted or becomes an informal part of a role (intangible); (iii) a tangible or intangible relationship is newly introduced and complements existing interaction patterns. -Interaction relationships can be directly transferred into concrete process steps, as they represent the fulfillment of tasks by the role holders in chronological order. Thus, a process model, which focuses on the exchange of services between actors (in contrast to linearized functional steps), can be derived from a holomap.

Potentials for Process Analysis and Modeling
Overall, Value Network Analysis is a diagrammatic / tabular technique for organizational development with the goal of process definitions or executable processes, which directly supports the mapping of interaction structures to communication-oriented approaches such as S-BPM ( [4]). All information is generated from the point of view of the involved or responsible role holders (see also [5][6][7]).

Structured Asset Records
In the following a procedure is described, which leads from a natural linguistic description to a formal behavior model. This approach is based on active sentences of natural languages. The process will be introduced on the basis of the Poly Energy Net (NET) project, an approach funded by the German Federal Ministry for Economic Affairs and Energy. The aim of this project was to develop a solution for a self-organizing distributed energy supply system. The following sections show how the associated software was developed, from a general description to a precise model, which was then converted in a first stage into a program based on process specifications.

General Information
The following steps, which lead from an informal description of a process to a formal model of the process flow, do not have to be performed in the order given. The steps rather serve the goal of a precise process description. If it turns out in one step that something had been forgotten in a previous step, or if it turns out that it is more advantageous to design subprocesses differently, this change is included in the step currently being worked on. The change is not reflected in the previous descriptions. To create a first draft of a process description, the procedures from Design Thinking described in the previous chapter can be used.
All documents of the previous descriptions are obsolete by default and no longer valid after completion of a more detailed description, except when a description explicitly states that a previous description is still valid (e.g., as an overview document). Experience has shown that it is not possible to keep several documents consistent. There should therefore only be one valid document, so that a formal behavioral model is available after the preparation has been completed. As a rule, changes should only be made to this model.
When creating a process model, one can also start with any step. For example, only active sentences can be used for a natural language description. Thus, the steps which transform a description in arbitrary form into an active description form are omitted. It can also begin with the identification of the actors and continue with the detailing of each actor, including communication with other actors. The concrete procedure depends on the circumstances and preferences of the parties involved.

Natural Linguistic Description of Processes
A process is described in a more or less structured way in natural language. There is no specification as to the structure of the document to be created or the vocabulary to be used. The creators of a process description can follow their preferences. Figure 6.9 shows an excerpt from the rough description of requirements for the energy management system.
The initial free use of natural language does not require any special methodological knowledge on the part of the participants. The need for such knowledge could be a major obstacle to the involvement of stakeholders from different departments.
Textual descriptions can be supplemented by suitable images. Figure 6.10 shows a functional structure of the system to be created. Such a functional structure is a first approximation to the specification of a process system.
Based on these more structural descriptions, a first process-oriented specification can be created. Figure 6.11 shows an excerpt of a process description.
This process description is supplemented by an illustration of the effects on a holonic energy network. Figure 6.11 refers to some elements (switches) in Figure 6.12.
The tools used at the beginning for an initial requirement definition and process specification are not structured. Basically, texts and supplementary drawings of any

Process Descriptions in Active Form
Informal process descriptions in natural language very often contain passive clauses (see also the above description). However, passive sentences do not contain a direct assertion about the performer of an action. Passive sentences are used when it is not important who the performer of an action is. However, this is not the case with processes. Process descriptions must include the performer of an action. All passive sentences must now be converted into active sentences. To do this, the active elements must first be identified. Active elements can be humans, software systems that run automatically and perform certain activities, physical systems, or any combination of these basic elements. Therefore, in our example, the control center can be a combination of software, people and electrical systems. The software prompts an operator to read a specific measured value and enter it. Depending on the entered measured value, the software initiates the closing of a switch.
In order to avoid a process description being too dependent on the organizational and technical environment, abstract actors are introduced. Such abstract actors are entities that send messages, receive messages, or perform internal tasks. Figure 6.13  shows the function diagram with assigned active elements. These abstract active elements are called subjects, following the subjects in active sentences. Subjects are the roles in processes. The tasks of the identified subjects can be briefly described for a better understanding as shown in Table 6.2.
With the introduction of actors in the form of subjects, all passive sentences can now be replaced by corresponding active sentences. This makes the process description more complete. Table 6.3 shows a process description with active sentences in tabular form. The numbering of the entries already reflects the control flow. The number of the follow-up action is specified in the associated column. If the follow-up action depends on certain results of the action, this condition is described in the column follow-up action. Depending on the valid condition, there may be another follow-up action.
A table with the control flow of a process can be the starting point for a control flow-oriented process model. The individual actors are the swim lanes in BPMN or in a swim-lane-oriented EPK or in UML state diagrams. However, these modeling methods should only be used if no asynchronous events, such as the possibility of changing purchase orders, occur in a process and the parallelism of the agents is not to be modeled. In addition, the number of actors should not be too high. Swim lane representations are usually flat, i.e., there are no hierarchies of swim lanes. More than five swim lanes lead to confusing representations. Thus, a service process contains as a minimum the swim lanes customer, call center, first level support, billing and, where applicable, customer feedback. Experience shows that in real processes there are usually about 10 actors or more involved. Swim lane diagrams even become confusing if the control flow just has to cross several swim lanes in order to switch to another swim lane.
Control flows are not a manageable representation for cross-organizational or cross-company processes in a distributed environment. In a distributed environment, messages are the more vivid way to model the collaboration of individual actors.

Tabular Role-Oriented Description
In the last step before the actual process modeling, the process description is structured according to the actors. All sentences with the same actor as subject are summarized in a table. For this purpose, it may be necessary to supplement the process description with interactions between subjects. Phrases such as "informs subject xy" or "engages with" etc. are replaced by send and receive actions (see Table 6.4). Sentence no. 2 "Network monitor reports the situation to the control center" in Table 6.3 is converted into a send and a receive action. In Table 6.4 this corresponds to sentence no. 2 "Network monitor sends status black to control center" in the table section for the network monitor. The counterpart to this is sentence no. 1 in the table section for the control center.
After creating the behavior tables, a formal model can be derived in a suitable modeling language. A language should be used in which the aspects deemed important for the process under consideration can be clearly and precisely expressed. In our example we have selected S-BPM. Figure 6.14 shows in the left half the (continued)

Analysis and Modeling
network structure of the considered process. The rectangles with rounded corners represent the actors involved. The arrows between the actors are labeled with the exchanged messages. The numbers on the message names correspond to the sentence numbers in the table above. The diagram to the right of the process structure shows the behavior of the holon coordinator subject. The circles with the letters E and S are states of communication. Transitions from circles with an E are labeled with the messages expected in this state. The transitions to S states are labeled with the messages sent in this state. All other transitions define local operations on local data.

Process Modeling
Selection of the Modeling Language In the following, some factors which should facilitate the selection of a suitable modeling notation or language are listed as examples. These include the determining factors of a BPM project, the manageability of the language and the support of downstream activities such as validation (see also [8][9][10][11][12][13]). With regard to determining factors, the question 'What are the properties of the subject matter to be modeled?' is of particular interest. The following properties should be decisive for the selection of a modeling language: -Asynchronous events: If such events exist, then a corresponding modeling language should offer the possibility to map the associated parallelization of processes or process steps in such a way that, if necessary, an execution reflects the parallelism. This means that the modeling language contains constructs for representing asynchronous events that explicitly contain this temporal quality. This allows a runtime environment to be configured accordingly at execution time. -Cross-organizational and cross-company: If an issue is relevant not only for a particular organization or one of its subsidiaries, but also for networked partners outside the immediate areas of activity, such as other subsidiaries or the supplier industry, then proven modeling mechanisms or language constructs should be available that enable the encapsulation of external issues. This makes it possible to embed external actors in an organization without having to know and represent their processes in detail.  Holon coordinator goes into "alert" state and waits for feedback from control center -Number of actors: At first glance, this parameter does not seem to be necessarily relevant for the selection of a modeling language. However, it becomes more important when it comes to the complexity of processes on the one hand, and the comprehensibility of the models on the other. After all, the instance-model relationship also plays into this factor. If there is a large number of actors involved, a notation should also have modeling mechanisms or language constructs that make them visible, as well as accessible aggregately or through other perspectives (e.g., functional view).
With regard to manageability, the question 'How should the subject matter be described?' is of particular importance. The following properties or quality of a modeling language should be decisive for its selection: -Number of symbols: On the one hand, a limited number of symbols can make powerful models easily manageable, but on the other hand it can lead to an undesirable abridgement of facts.  Fig. 6.14 Behavioral description of the holon coordinator subject

Analysis and Modeling
-Definition of symbols: The use of the symbols should be clear, i.e., objectively comprehensible for modelers. This facilitates effectiveness and efficiency in the creation of models. -Availability of tools for model description: The availability of digital tools for the simple and correct representation of subject matter determines the usability of a modeling language. A syntax editor for diagrammatic languages helps, for example, to create syntactically correct models and to structure complex situations in a usable way. -Possibilities of structuring models along a hierarchy: This feature allows networked issues to be viewed from a top-down perspective. This usually facilitates the legibility of models and thus increases the comprehensibility of illustrated facts for those not directly involved.
Regarding the support of further activities, the question 'How is the support of the model for next steps?' is of particular interest. When selecting a modeling language, the following features of a modeling language should be considered in this context: -Validation tools: Can a model be validated? This means that a tool can be used to determine whether the notation and thus all of the language used has been utilized correctly in the sense of the syntax of the language and in the sense of the intention of the subject matter depicted. -Optimization tools: Can a process be optimized with the help of its model?
Optimization follows initial modeling and validation and aims at the optimal distribution of tasks and the optimal use of resources. For this purpose, a tool should be used to determine whether the notation and thus all of the language used allows, or actively supports, the optimization of modeled processes through corresponding constructs of the language, or through special mechanisms (e.g., through suggestions or reference models). -Tools for organizational embedding: Can the integration of a modeled process into an organization be realized with the help of a tool? This step is the first one to implement processes and requires that a tool can be used to determine which task or role holders or which organizational units should be able to carry out the illustrated activities in practice. On this basis, the corresponding assignments for the organizational implementation of process models can then be made (and changed again as required). -Tools for technical embedding: Can the integration of a modeled process into an IT infrastructure or information system architecture be realized with the help of a tool? This step is the second necessary step for the implementation of processes and requires the determination by means of a tool which technical system can carry out the depicted activities in practice. On this basis, the corresponding assignments for the technical implementation of process models can then be made (and adapted again as required). -Tools for commissioning and operation: Can the commissioning and operation of a modeled process in an organization be supported or ensured with the help of a tool? This step is necessary as soon as a process is switched to 'productive', i.e., after it has been embedded in the organizational and technical infrastructure and has been transferred into the operational environment or has become operationally effective. In this context, a tool should help to support the introduction phase of a modeled process, i.e., to determine which process steps are transferred to operations and in which order. An appropriate tool should also support monitoring of implemented processes and thus help to ensure the operations of an organization and effectively support its further development. The latter can be done by means of annotations in process models, which mark obstacles to execution.

Modeling by Construction
When constructing a process model, modeling begins with a "blank sheet of paper". The information from the process analysis is used to describe the process step by step. The required activities include several different tasks, depending on the approach chosen: -Description of the processes and their relationships (process network) -Identification of the process to be described -Identification of the actors or systems involved in the process -Specification of the information exchanged between the actors or systems within the control, data and message flow for processing business cases. This also includes the implementation of business rules, as they directly influence the behavior of actors and systems. These activities are set in a certain order according to the selected language and lead to differently detailed representations of subject matter.

Modeling by Restriction
In addition to modeling by construction, there is also the possibility of modeling by restriction. This is based on general process models. A typical example is the communication-oriented approach as pursued with S-BPM. In the universal process model, each actor or system involved in a process can send a message to, or receive a message from, any other actor or system involved at any time. This message has the general name 'message' and can transmit any media as a business object. The result is a universal process that is characterized by the number of its subjects. These are marked as boxes with subject 1... n. Their mutual interaction possibilities are marked by arrows between the subject boxes. This results in a similar initial behavior for each subject.
Within the framework of modeling by restriction, the following steps are taken to a detailed factual situation: (i) determine number of subjects and subject identifiers, (ii) reduce communication paths, (iii) specify message types, (iv) customize subjects' behavior, (iv) specify and refine business objects.
If other, for instance, function-oriented approaches are chosen, then basic structures can be generalized, for example in the form of reference models. In doing so, behavioral patterns will also be used, such as previous events for functions or conditions that determine the further course of business processes after executing a function.

Combining Approaches
While in the construction of process models the modeling begins with a "blank sheet of paper" and is extended step by step with information from the process analysis, in the modeling by restriction a generalized structure of process models and their components is assumed. A typical example of a combination of both approaches is the case corresponding to the middle-out approach. One instance of this case is to start with a construction and, as soon as a (recurring) pattern occurs, to use a reference model and reduce or concretize it.
Further application instances would be a pattern comparison and the start with recurring (routine) processes. The latter reverses the above-mentioned case and allows the embedding of special characteristics of process flows into generalized process architectures. The pattern comparison, on the other hand, represents a kind of control process in which the completeness or correctness of a model can be checked by means of a generalized pattern.

Quality Control: Validation and Optimization
Validation is closely related to modeling. In modeling the process flow is described according to the objective. This means that during the modeling activity the following question resonates: 'Does the model correspond to the set qualitative and quantitative objectives?' The examination, whether a process model corresponds to the set goals, is called validation and/or optimization. This means that validation and optimization are constantly performed in the course of modeling. After the decision to complete the modeling process, a final check is made as to whether the overall model meets the set objectives. Validation shows whether the process meets all requirements and achieves the intended results. It is also essential for a process whether the desired results are achieved with the least possible effort. Quality control in business processes therefore has two main tasks. It is intended to test the effectiveness and efficiency of processes. Effectiveness means that the process meets the requirements placed on it, i.e., delivers the desired result (output). The process is efficient if it can be carried out with as little financial and time resources as possible in order to deliver the desired result. This is to be achieved through optimization.
Both quality controls must be implemented as early as possible, before IT systems are developed at great expense and later users are trained. Figure 6.15 summarizes the individual aspects of validation and optimization. The verification of a process model is supported by appropriate tools and reference models. For the validation there are manual tools such as checklists or role-plays, while for the optimization simulation software must be used. The results of the check are prepared and entered into 'ToDo' lists for processing, i.e., modeling activities are started again. This cycle is repeated until the verification leads to a result considered to be good enough.

Validation
The prerequisite for validation is a model that reflects the subject matter to be represented. It is checked whether the model delivers the expected result according to the specified quality characteristics and whether the process contributes to the goals of the company. This aspect is called semantic correctness. This results from the consensus of the managers as well as the technical and methodological experts who consider the model to be appropriate.
The semantic validity is to be distinguished from the syntactic correctness, which concerns the adherence to the fixed description rules, i.e., the description means are used according to the defaults of the modeling language. Figure 6.16 shows a general procedure for manual validation. Here the process documentation is checked with the help of checklists. The process documentation includes the description of the goals, inputs, results, triggering events, and of course, the model of the process. The process documentation should be checked by all parties involved in a process on the basis of the checklists.

Manual Process Validation
The findings of the individual parties are consolidated and clarified in a joint workshop and the necessary revisions are jointly determined. This cycle is repeated until it is jointly decided that no further revisions are necessary. To prepare a review, the process description and a checklist, according to which the process description is to be verified, are distributed. This checklist contains questions to be answered by the evaluators regarding the process.

Examples of such questions are:
-Does the process support the company's goals? -Are the objectives of the process defined? -Is the benefit of the process clearly described in the objective and is it clear what added value it delivers and for whom? -What risks does the process entail? -Is a process owner assigned? -Have the authorities of the process owner been defined and are these sufficient? -Are there any performance indicators with which the achievement of objectives can be evaluated? -Are the measurement procedures for the performance indicators clearly defined? -Are the target values for the performance indicators of the process systematically defined and do they provide an assertion about the value contribution of the process? -Does the process support the policy and strategy of the company or IT organization? -Is the process flow described? -Are the inputs and results of the process described? Fig. 6.16 Sequence of a manual process check -Is it clear who (organizations, roles, people) provides which inputs and who receives which results? -Are the description conventions for processes adhered to? -Is it defined who is responsible for the individual steps of the process (organizations, roles or persons)? -Is the procedure in the process aligned to the interest groups (e.g., customers)? -Is the procedure in the process clearly justified? -Are there sufficient tools for executing the process (checklists, work instructions, etc.), in addition to the process description? -Is the scope of the process clearly defined? -Are the relationships of the process to other processes described or defined?
The above list of questions is only exemplary and not complete. Companies often use lists with up to 100 questions.
Reading extensive process documentation and comparing it with long checklists is very tedious. Experience shows that the intensity of the check decreases with an increasing number of pages. The first pages are still read in detail. Then the accuracy decreases continually. In order to compensate for the weaknesses of a visual assessment, a more formalized version of the review, the so-called "walk-through", was developed, whereby the walk-through refers predominantly to the process model.

Walk-throughs
Similar to code inspection in programming, in a walk-through a process is discussed step by step with selected process participants. In order to make the step-by-step process more engaging, a formal process description can be run through with the help of a practical example. A process participant goes through the business process description step by step using a concrete example. For each process step, an expert asks specific questions in order to question the effectiveness of the process description.
For example, the understanding of technical terms, the technical necessity as well as the completeness of the process description are questioned. In this way, the process description is evaluated. A walk-through is performed with about two to four process participants representing different user groups.
The 'authors' of the process description (e.g., process managers) should remain in the background so that criticism can be formulated openly. All points of criticism and suggestions are collected, documented, and then evaluated with the process participants. This evaluation leads to a revision of the process.
The step-by-step analysis of a process can be supported by appropriate tools. The tool used shows the process model on the screen and the current process step is highlighted in color.

Role-Plays
The next level for a tangible review of process models are role-plays. These are particularly useful when communication-oriented modeling languages are used. The actors are then already identified and the roles are subsequently assigned to suitable persons. A game leader triggers the process and provides the necessary input. These process instances are then executed by the individual role holders according to the process descriptions. These 'process flows' are observed by other affected parties and the anomalies identified are noted. After a number of process instances has been executed, the findings are evaluated and necessary adjustments identified.
The execution of role-plays can be supported by suitable IT tools. The role owners of a role-play do not receive their role descriptions on paper, they are guided through the process by software that, in particular, implements the flow logic. This software is generated directly and automatically from the process model. The prerequisite for such an approach is that the semantics of the process modeling language used are clearly defined. This prerequisite is, for example, only partly met by BPMN and not at all in the case of EPCs. However, S-BPM entirely fulfills this requirement due to its clearly defined formal semantics. Figure 6.12 shows what an IT-supported validation can look like. The advantage of an IT-supported role-play is that the preparation time is very limited and the process experience is very close to the subsequent productive process execution ( Figure 6.17).

Optimization
After checking the effectiveness (do the processes deliver the desired result at all?), it must be checked whether the result is achieved with the least possible use of resources. Optimization through manual testing, walk-throughs or role-plays is only possible to a very limited extent. The knowledge gained in this way only provides an approximation for determining the resource requirements for an assumed number of process runs. A systematic determination of the resource and time requirements is only possible through simulation. However, the prerequisite for a simulation is that the process model can be executed.
When business processes are simulated, the business cases handled by a process are generated randomly according to an assumed probability distribution. As a rule, this is the exponential distribution with a presumed or observed expected value. The individual work steps are assigned the corresponding resources with the required working time. The required working time usually follows a normal distribution with expected values and standard deviations determined from observations. Within the framework of simulation instances, information is provided on the execution capability of processes, on process weak points, and on resource bottlenecks. On the basis of the simulated Process Performance Indicators, various alternatives can be evaluated and a realistic benchmarking carried out in advance of cost-intensive process changes within a company.
Modern tools and simulation methods enable the analysis and optimization of processes with regard to costs, lead times, capacity utilization or bottlenecks. In addition, the simulation of business processes forms a starting point for introducing activity-based accounting instead of the relatively inaccurate cost-plus pricing. The As already mentioned, conducting a simulation study requires a precise description of the process under consideration. This means that a formal method must be used to define the process flow. In addition, the most precise knowledge possible of the probability distributions, their parameters and the examined performance indicators is required. In practice, simulations are not often used due to the high effort involved, although the findings can be compelling.
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.