Enabling Emergent Workplace Design

Abstract

This chapter offers a synthesis of the conceptual and methodological considerations of the previously presented frameworks and instruments. It adjusts the methodological concepts for eliciting, representing, and processing work knowledge for practical use. Based on elementary modeling constructs we provide a unifying framework that guides the design of organizational interventions when enabling the emergence of novel digital workplace designs and work practices. According to the architecture, support systems for organizational learning enable augmenting processes with work-relevant knowledge, including the execution of specified behavior representations. Overall goal is developing consensually shared workflow designs—developed for and by the actual set of people executing a workflow. The structured procedure allows a generalized architecture based on a common organizational memory and dedicated components for articulation, informed alignment through organizational learning support, and process prototyping.

This chapter offers a synthesis of the conceptual and methodological considerations of the former chapters. It brings together the lines of argumentation offered in Chaps. 3, 4, and 5 and provides a unifying framework that guides the design of organizational interventions that enable emergence of novel digital workplace designs and work practices.

Process-oriented organizational learning (OL) approaches assume the existence of commonly agreed upon or prescribed work processes (Wargitsch and Wewers 1997; Abecker et al. 2001; Diefenbruch et al. 2002; Hinkelmann et al. 2002). OL support systems then augment these processes with work-relevant knowledge during execution of the workflow (Abecker et al. 1998). These systems, however, do not explicitly allow for or even consider deviations from the prescribed work process. Such deviations, however, happen regularly due to contingencies that arise during execution of a workflow. Another reason of process deviation is individual expertise that allows for shortcuts or emphasis on certain aspects of the workflow depending on the actual set of people executing it. In knowledge-intensive business environments (Dalmaris et al. 2007), both triggers for deviations are rather a standard case than an exception (Marjanovic and Freeze 2011).

Business process support in knowledge-intense environments requires three dimensions to be brought together:

• Business processes describe how actors work together and perform their work in an organization to pursue a common goal

• Knowledge is required to perform the business processes and enables actors to make their decisions on how to continue work based on their perceptions of the environment

• Actorsare those entities in an organization who actually carry out business processes based on their knowledge

In the light of these dimensions, the two major goals for support measures can be defined as follows:

• Agility is the ability of allowing actors to deviate from a given business process based on their knowledge about their work and their perceptions of the environment

• Actor-awareness is the ability of a support system to adapt its behavior to a specific actor being active in a business process and provide the actor with any information that is necessary to build up knowledge and make informed decisions

Any two of the three dimensions have already been brought together in earlier research. The frameworks resulting from this earlier works, however, always omit the third dimension:

• The Knowledge Lifecycle (KLC) of Firestone and McElroy (2003) brings together business process management and knowledge management. It, however, does not explicitly consider actors and how they perform the activities described in the KLC.

• Subject-oriented Business Process Management (S-BPM), as developed by Fleischmann et al. (2012), explicitly considers the role of actors during process design and execution. The primary elements of structuring are subjects that separate a process along who performs work in the process. How to deal with knowledge, however, is not explicitly taken into account in this approach.

• Mental Model Theory (MMT), as initially described by (Johnson-Laird 1981), provides a way of understanding how people make decisions based upon their perception of their current work situation and their prior knowledge. Being a generic approach, the theory is not specific to people’s behavior in business processes and thus does not explicitly consider this dimension.

The KLCand S-BPM augment each other. The KLC focuses on the identification of knowledge needs, knowledge production, and knowledge distribution. S-BPM focuses on business process execution and monitoring. Both, however, provide overlapping aspects that act as docking points to intertwine both frameworks. Mental Model Theory, however, does not easily integrate with the other two frameworks. MMT is a psychological approach focusing on the cognitive processes of individuals. The KLC and S-BPM, however, take an organizational perspective and consider individuals as atomic entities in the organizational knowledge base (KLC) or interacting with each other (S-BPM). The remaining gap can be bridged by the sociological theory ofArticulation Work (Strauss 1993). Articulation Work describes the phenomenon of resolving work situations that are considered problematic by the participating individuals. Problematic work situations occur whenever the application of the current mental model of any participant does not lead to the desired outcome (Pirnay-Dummer 2006). The resolution of such problematic work situations leads to changes in the workflow among the involved actors and eventually can be a trigger for learning processes in an individual and inter-individual (i.e., organizational level).

In the following sections, we outline how methodological inputs from MMT and Articulation Work help to inform learning practice to finally develop an integrated framework.

6.1 Articulation Work and Mental Models

Work is an inherently cooperativephenomenon (Helmberger and Hoos 1962). Whenever people work, they have interfaces to others, either cooperating directly to perform a task or mediated via artifacts of work, which they share (Strauss 1985). The cooperative nature of work and its support with social and technical means have been subject to research for decades now (Schmidt and Bannon 1992).

Cooperative work requires that participating parties have a common understanding of the nature of their cooperation. This includes dimensions such as when, how, and with whom to cooperate using certain means. The mutual understanding of cooperation has to be developed when cooperative work starts and has to be maintained over time, as changing environment factors may influence cooperation (Fujimura 1987). All activities concerned with setting up and maintaining cooperative work are summarized using the term “Articulation Work” (Strauss 1985). Articulation Work mostly happens implicitly and is triggered during the actual productive work activities whenever contingencies arise (Gerson and Star 1986). Cooperative practices are established without a conscious act of negotiation in “implicit” Articulation Work, relying on social norms and observation to form a mutually accepted form of working together (Strauss 1988).

Implicit Articulation Work, however, is not sufficient when cooperative work situations are perceived to be “problematic” or “complex” by at least one of the involved parties (Strauss 1993). The terms “problematic” and “complex” here explicitly refer to individual perceptions and are intrinsically subjective. As such, they cannot be detailed from an outsider’s perspective. Consequently, implicit Articulation Work can influence cooperation substantially. Different understandings of the same work situation impact the way of accomplishing tasks and the quality of work results, once Articulation Work remains on an implicit level.

The act of negotiation and development of a common understanding of the cooperative work processes has to be carried out deliberately and consciously in such cases. This act has been termed “explicit” Articulation Work by Strauss (1988). It has not been detailed methodologically initially, but rather omitted deliberately (Strauss 1993, p. 131). However, explicit Articulation Work has to be carried out whenever problematic or complex work situations arise. Its expected outcome is to enable involved stakeholders starting or continuing their cooperative work towards a shared goal. The roles and activities of stakeholders involved in explicit Articulation Work need to be clarified, as they go beyond implicit Articulation Work and prevention of “problematic” (as termed by Strauss) situations. Existing studies largely focus on the support of implicit Articulation Work and the prevention of “problematic” situations (e.g., Schmidt and Bannon 1992; Grinter 1996; Sarini and Simone 2002a). The findings do not explicitly address the individual dimension of explicit Articulation Work (e.g., Schmidt and Simone 1996 or Herrmann et al. 2002), nor remain on a conceptual level without deriving implications for supporting explicit Articulation Work (e.g. Fjuk and Dirckinck-Holmfeld 1997).

Conducting Articulation Work facilitates the alignment of individual views about collaborative work. Strauss (1993) argues that these individual views (termed as “thought processes” and “mental activities”) affect human work and direct individual action. Research in the field of Articulation Work and its methodological support has hardly ever addressed the roles of the involved individuals in the alignment process. Both Herrmann et al. (2002) and Jørgensen (2004) present approaches that state that explicitly considering the individuals’ views on work is crucial for successful Articulation Work, but it does not explicitly consider complex work situations. Consequently, a common understanding of the concepts used for describing work cannot be taken for granted (Sarini and Simone 2002b) and should be subject to alignment itself (Sarini and Simone 2002a). For problematic or complex work situations in particular, where social means of alignment (Wenger 2000) might not be sufficient and even a common understanding of the used terms cannot be expected (Sarini and Simone 2002a), a closer look at the individuals’ understandings of their and others’ work is of development interest. It should support designers to provide effective support measures. From how “thought processes” are described by Strauss (1993), they correspond to instances of the concepts of “schemes” and “mental models” in cognitive sciences (Johnson-Laird 1981).

6.2 Mental Models Theory and Articulation Work for Organizational Learning

Both mental model theory and Articulation Work can be linked to different steps in the organizational learning approach taken by the KLC. Together with the S-BPM, a comprehensive picture is taken of how an actor-centric, process-oriented approach to organizational learning can be supported methodologically and technically.

Figure 6.1 gives an overview about where mental model theory and Articulation Work play a role in the KLC. Starting with the Articulation Work, the mapping of the different concepts to the KLC is straightforward. All activities that are carried out to the reach the goal of work are referred to as “Production Work.” As soon as a problem arises (i.e., some outcomes do not meet the expectations of any of the involved people), Articulation Work is triggered. How these problems are identified cannot be explained using Articulation Work; Mental Model theory will provide support here. If a problem can be compensated without any dedicated engagement in revising the work process, “implicit Articulation Work” happens. This is equivalent to what is referred to as single-loop learning in the KLC. Following the approach of “implicit Articulation Work”, the modes for performing single-loop learning are extended in reference to the S-BPM instantiation of single-loop learning. More informal, even completely unobservable alignment activities among the workers might compensate the problem and affect the distributed organizational knowledge base (DOKB) only in terms of the actor’s knowledge that has assimilated the new information of which contingencies can occur in a particular process and how it can be resolved.

Fig. 6.1

Mental model theory and Articulation Work in the KLC

If a situation appears to be too problematic to be resolved without any interruptions in the work process (i.e., stepping out of the business processing environment), “explicit Articulation Work” is triggered. Explicit Articulation Work refers to dedicated negotiation and alignment activities that are carried out to enable people to effectively perform their work. Both, the activities included in knowledge production as well as those in knowledge integration, can be considered to be part of explicit Articulation Work. With this mapping of the KLC knowledge processing environment to explicit Articulation Work, the spectrum of methodological support for the latter is opened up for implementing organizational learning support.

Mental model theory augments the KLC in two specific situations: It can be used to explain how matches and mismatches in outcomes are identified by actors, and it provides a frame of reference for learning and behavioral change processes on an individual level.

People involved in a work process perform their activities according to their perceptions of the current situation and their schemes and mental models (i.e., their beliefs about how the environment will react to their activities). As soon as a scheme does not provide a starting point on how to determine what to do next or if the environments’ response to a certain activity does not match what has been expected, a problematic situation occurs (this is equivalent to the match/mismatch section within the KLC). People try to compensate this problem using their mental models. This might or might not involve other people participating in the work process but will always lead to learning in the sense of the KLC. The situation is considered too problematic to be compensated, if the existing mental models of the involved people do not allow for compensation of the problem. In these cases, explicit Articulation Work, that is, activity in the knowledge processing environment is triggered.

During different phases of the knowledge processing environment, the mental models of different groups of people are altered. Those involved in developing the knowledge claim accommodate the new theories about how to resolve or avoid the problematic situation during the individual and group learning steps. In the course of integrating the new knowledge claim in the DOKB, the mental models of other people for whom the claim can be important during work need to accommodate it in their mental models. Instruments supporting model-based learning activities can potentially be of use here.

An alternative to immediate distribution of a new knowledge claim throughout an organization is to delay delivery to the affected people until they are confronted with the problematic situation. Following the theory of model-based learning, people are able to accommodate new information in their mental models more easily if the accommodation process is triggered by an actual situation (Ifenthaler 2006). This, in turn, requires an appropriate form of representation for the knowledge claim that allows for individualized and situated delivery of the information necessary to resolve a particular problematic situation. The requirements on this representation and a conceptual approach on how to implement it are presented in the next section.

A support system making use of such a representation is able to provide agile—that is, appropriately situated—and actor-aware—that is, personalized and individually adaptable—process implementation and improvement support, and in this way realizes the foundation for implementing an integrated learning framework.

6.3 Towards an Integrated Framework

In order to establish a common framework for the design of work processes in digitally augmented organization, we outline a framework on how to describe work in such organizations in the following. It should allow for situation-specific agreements on work carried out by a group of organizational actors that dynamically match their skills and work processes to reach a shared organizational aim. Work processes are not considered to be static flows of activities and interaction throughout a whole organization in this approach but vary in their implementation depending on the current situation and the actors carrying out the process.

This approach requires introducing concepts to describe such processes and their variations as well as the situations that determine which variation of a process is actually carried out. The relevant concepts are printed in italics in the following section and are put into mutual context in Fig. 6.2.

Fig. 6.2

Conceptual framework

6.3.1 Relevant Concepts

Organizations are the frame of reference for work processes. An organization here not necessarily corresponds to a single company but might span across any number of legal or administrative entities. An organization is determined by the persons that participate in it. Persons are active entities that carry out work within the organization. Persons are the carriers of knowledge and determine with their expertise how work is actually carried out.

An organization pursues one or many organizational goals. Such goals determine the scope of work of the organization and are specified by the entities being responsible for the organization. Each organizational goal is pursued by a particular type of process. A process type is not an actual process but a means of structuring the activities of the organization. Process types are specified independently of any influence factors except the organizational goal to be pursued. A process type thus contains a number of actual work processes that are determined by the basic conditions under which an organizational goal is pursued.

The basic conditions for process execution are determined by the context influencing the process variation. This context is determined by two major sources. Organization-specific context refers to the general conditions within the organization under which a process is carried out. This includes financial and administrative guidelines as well as business rules to be adhered. Organization-specific context is identical throughout the whole organization and equally affects all process types. Process-type-specific context refers to aspects that are only relevant for pursuing one specific organizational goal. This includes varying legal circumstances, potentially changing partners from outside the organization, or requirements specified by internal or external entities such as superiors or customers, respectively. The actual values these factors take in a particular situation make up the basic conditions under which a process of a particular process class is executed.

A process type consists of a set of work processesthat allow reaching the organizational goal. Work processes are distinguished by goals that can be pursued separately and finally lead to archiving the overall organizational goal. The sequence of work processes and the question whether a particular work process is executed at all are determined by the basic conditions. A work process might not be relevant under certain conditions and thus is omitted. The sequence of work processes might be of importance under certain conditions, whereas it might not matter otherwise.

6.3.2 Implementation of Work Processes

Work processes are described by determining the required actors, who interact based on behavioral fragments, which determine the tasks to be completed and interaction to be carried out in any case. A required actor is described by the set of tasks it is responsible for (as will be elaborated on in more detail later). The set of required actors and behavioral fragments is not static and predefined for a particular work process. Which actors are actually required, and which behavioral fragments have to be implemented, are determined by the context factors described earlier as well as by the persons who act as members of asituation-specific interdisciplinary team (SIT) in a particular work process instance. As noted, persons are the carriers of knowledge and implement processes according to their expertise and the situation they perceive while performing their work.

The situation a process is implemented in consequently is determined by the organization-specific and process-class-specific context factors as well as the persons that are involved in the process. Furthermore, unforeseen contingencies can affect process execution, as ad hoc adaptations and workarounds might become necessary. Contingencies are a part of the situation a work process is carried out in but cannot be described at the time the execution of the work process starts. They are thus specific to a particular execution of the process, in contrast to the other influence factors that remain stable for identical situations (given that such identical situations would occur).

6.3.3 Responsibilities and Skills

Based on the aforementioned description, work processescan be considered collections of areas of responsibility, as visualized in Fig. 6.3.

Fig. 6.3

Work processes and areas of responsibility

The notion of team member refers to a set of activities that are completed by a single person in a work process. Team members are required to interact with each other as part of a SIT to achieve the aim of the work process. In the context of the work process, these team members play different roles when carrying out the work process.

Persons can take these areas of responsibility as visualized in Fig. 6.4.

Fig. 6.4

Persons and areas of responsibility

Persons are active entities in an organization that are able to perform tasks. A person can act as an actor in one or more teams within a work process and can even take over the responsibilities of several team members.

Organizational roles are used to cluster areas of responsibilities across work processes. Persons can take organizational roles and still take over areas of responsibility not included in this specific role, as visualized in Fig. 6.5.

Fig. 6.5

Organizational roles clustering areas of responsibility in different work processes

The notion of organizational role refers to an area of responsibility within an organization. Organizational roles are specified by the set of team memberships they comprise. Persons take a specific role in a defined part of an organization. The role a person takes designates the person’s formally necessary competences, that is, which team memberships the person has to take in the work processes it is involved in. The skills of a person (i.e., the set of team memberships a person is able to take in general) might go beyond those required by the person’s organizational role.

Team Members (areas of responsibility) are specified regarding their interface towards other subjects and the behavior required to fulfill the responsibilities, as visualized in Fig. 6.6.

Fig. 6.6

Interfaces and behaviors of team members

A team member is described using a set of requirements that specifies it expected behavior towards other team members and guides its actual behavior in a specific work setting. Vague behavior blocks specify the minimum requirements on expected behaviors, whereas behavior block implementations show the actual behavior variants for different variants of a work process.

6.3.4 Towards Instantiation

For single behavioral fragments, this leads to a three-tier conceptual structure, as shown in Fig. 6.7.

Fig. 6.7

Instantiation of behavior fragment

Areas of responsibility can be interlinked by matching their behavioral interfaces, as shown in Fig. 6.8.

Fig. 6.8

Linking behavioral interfaces

6.3.5 Behavioral Interfaces for Interaction Coordination

Expected behavior towards other team members is described in a behavioral interface. The behavioral interface contains all messages a team member is able to receive and provide. If particular messages are interdependent of each other within the work process, they are grouped usingcollaboration brackets. Messages inside a collaboration bracket follow a specified order, where order specification can include sequences, optional parts, and alternatives. A behavioral interface can comprise multiple collaboration brackets, thus enabling a team member to collaborate with different other team members while completing its part of the work process. Collaboration brackets are independent of each other. If dependencies exist, they are to be handled within the implementation of the subject and thus are reflected in the behavioral requirements of a team member.

Behavior fulfilling an area of responsibility can be implemented by executing differently refined behavioral requirements as shown in Fig. 6.9.

Fig. 6.9

Different behavioral requirements for a single behavioral interface

6.3.6 Behavioral Constraints for Individual Actions

Behavioral fragments constrain and guide the actual implementation of team member activities. Behavioral requirements refer to orders or interdependencies among collaboration brackets and constraints and guidelines of how an actor may implement a subject’s activities (e.g., in which order communication with different subjects has to be carried out or which activities have to be performed in any case before a message is sent).

Behavioral fragments can be specified in a procedural way. They remain vague where no constraints apply, but are specified in more detail where particular activities or collaboration sequences are required.

Each set of behavioral fragments can be realized in different behavioral implementations, as shown in Fig. 6.10.

Fig. 6.10

Meeting behavioral requirements through different behavioral implementations

Collaboration requirements set on a subject separate different vague behavior blocks from each other. Each of the vague behavior blocks can be constrained by additional requirements. The actual implementation of the vague blocks is specific for a particular situation the business process is carried out in. The overall implementation is referred to as behavior implementation.

6.3.7 Varying Degrees of Freedom in Individual Activity

This structure can be put in the context of the theory developed earlier and allows implementing organizational work support for SITs, as shown in Fig. 6.11.

Fig. 6.11

Conceptual framework for situation-specific interdisciplinary teams

The parameters relevant to describe a situation involving self-organizing actors are organization- and process-specific, and additionally include the set of persons participating in the SIT.

A particular team membership thus might be implemented by different behavior implementations. Given potentially specified collaboration requirements, the granularity of behavior implementation is brought down to the level of vague behavior blocks. A vague behavior block is delimited by specified incoming and outgoing messages and might be constrained by requirements on the activities that are carried out during its implementation.

6.4 Articulation Engineered for Organizational Learning

In this section, we provide a conceptualarchitecture for developing learning support for situated team members and organizational actors. We ground the component-based approach on the concepts detailed in this chapter so far, in particular focusing on (i) mental model elicitation and articulation, (ii) continuous documenting of organizational knowledge (creation), and (iii) coupling execution with modeling facilities for actor-centric prototyping and probing of work processes. Hence, any technical support system for elicitation, articulation, and exploration of knowledge needs some kind of shared repository for storing all different types of (created) content, including social media entries—thus prepared material. Preferably, it also contains information about the learning process itself, including social media interaction, in order to trace learning steps and model construction processes. Such a component can be based on intelligent content management and networked social media to inform project management (including contracting with responsible persons) and execution—see Fig. 6.12.

Fig. 6.12

Articulation engineered for organizational learning (Chris Stary 2014)

Since learning is not only an intertwined cognitive and social endeavor, front- and back-end components help strengthening stakeholder commitment allowing deep enquiry and sustainable capacity building. The component framework abstracts from concrete applications in terms of generic learning support systems and consists of:

• A set of front-end technologies forarticulation support: It comprises state-of-the art devices, such as tablets with touchscreen structure elaboration as well as on-the-edge to market devices, such as tabletop systems for concept mapping and process modeling (e.g., Metasonic.de/touch, Comprehand Oppl and Stary 2014; Wachholder and Oppl 2014). These technologies serve as means to structure, share, and reflect on individual and collective mental models, either in the beginning of a project (idea development), in between (orientation), or when completing a project (reflection of achievements, check for completeness).

• A set of back-end technologies forprocess execution: Similar to the set of front-end components, it comprises state-of-the art devices for simulating or prototyping, for example, process management triggering production lines (process execution) (cf. www.so-pc-pro.eu). These technologies serve as means to implement production processes as projected by planning and monitoring, and finally to produce goods.

• A set of capacity building and project management technologies forlearning management and support: It comprises state-of-the art systems, in particular intelligent content management and state-of-the-art social media, either well established, such as Facebook, or on-the-edge to market, such as for video annotation. It is crucial that capacity building is supported by intertwining features from social media, with didactically prepared content, as well as contract and project management, to organize learning steps.

• A storage technology as amemory support: It includes text, diagrammatic information, video material, or hypermedia, and supports storing articulated items or process representations such as interactive structure elaboration of critical incidents. It also provides all prepared material and authoring functionality to create work content, up to executable process models. All information, either stemming from preparation, planning, learning, execution, or simulation, can be kept in that component and reused by searching via metadata and changing the context of use.

The concept supports coupling existing support systems, that is, the concept of federated systems becomes important. Each system of a federated system can then be operated autonomously, while at the same time being an interoperable part of a larger system (Wachholder and Stary 2014). Hence, dedicated effort has to be taken for ensuring the interoperability of the involved technologies.

6.4.1 Featuring OL Processes

In this section, we outline how the different steps in the framework can be supported methodologically and technically. Seven different areas of support have been in line with the KLC and its adjustment with the S-BPM activity bundles:

• Support for repository access is necessary to provide means for input, output, and representation of the codified parts of the repository throughout the whole learning cycle

• Delivering actor- and situation-aware process support aids the execution of a work process by providing access to knowledge about work when needed and also providing the underpinnings of activities during knowledge integration

• In-situprocess collection, adaptation, and refinement are necessary when a problem is encountered during work and can be compensated from directly within the work process

• Identification of the need for explicit acquisition and alignment activities is triggered when in-situ compensation is not possible, and a problem claim needs to be formulated for further processing

• Process knowledgecollection,reflection, and alignment cover all activities concerned with the social interactions during knowledge production

• Process validationand simulation forreflectionand alignment are necessary to evaluate knowledge claims and check their feasibility

• Process visualization for elicitation,reflection, and sharing is a means of support for all activities in the knowledge processing environment that require a codified form of the knowledge claim that is produced and eventually integrated into the repository.

6.4.2 Support for Repository Access

The repository does not solely contain technically represented, automatically executable knowledge claims. It conceptually rather covers all knowledge of the members of an organization, their experiences and expertise, as well as all individual and organizational procedures and facts that have been codified in IT-systems, workflow specification, or other organizational descriptions.

In dealing with this manifold of potentially relevant knowledge while still keeping maintainable complexity of the support tools, we follow a transactive memory approach proposed by Wegner (1987). Transactive memory is a conceptual type of memory (i.e., stored knowledge) that augments the (individual) internal memories and (codified) external memories. It refers to “a set of individual memory systems in combination with the communication that takes place between individuals.” Following this definition, knowledge transfer here is bound to the opportunity of direct interaction among the involved people. The challenge of building transactivememory support systems to facilitate knowledge sharing beyond a directly interacting group level has initially been addressed by Nevo and Wand (2005).

Nevo and Wand (2005) claim that transactive memory in distributed settings can be supported by an organizational memory system providing access to:

• Role knowledge—knowledge that is required by definition to take a certain role (e.g., knowledge about how to write program code in a specific language for application developers).

• Instance knowledge—knowledge a person has but which would not be required by his or her formal role (e.g., experiences in supporting international research projects for a secretary).

• Transactive knowledge—knowledge about how to effectively extend one’s knowledge by interacting with others. This includes:

  • Conceptual meta-knowledge (ontological concepts needed to describe a knowledge domain).

  • Descriptive meta-knowledge (information about role or instance knowledge, like author, scope, format, or creation date).

  • Cognitive meta-knowledge (knowledge about one’s own knowledge and abilities).

  • Persuasive meta-knowledge (knowledge about the credibility and expertise of the source).

The conceptual distinction between role and instance knowledge is equivalent to the approach of process groups and processes as described earlier, which has been introduced to handle variants of process execution due to personal expertise and situated influence factors. The concept of transactive knowledge allows providing support for distributing knowledge that is not codified in a technically executable way. In providing actors with knowledge about how to interact with other member of the organization, their ability to extend their knowledge in a self-directed way is supported. The concept of transactive memory maps to the meta-information about knowledge claims that need to be integrated in the repository according to the KLC (Neubauer et al. 2013).

The state of the art in organizational memory systems research is to enable situated knowledge delivery by offering technical support systems that monitor the current state of a work process and provide access to information relevant to the current work step (Mühlburger et al. 2017). We go beyond this approach in two respects: (a) it not only focuses on providing support during the operative work process but supports activities throughout the whole KLC (indicated by the arrows reaching out from the repository to different phases in the KLC, and (b) it does not assume the existence of a standardized (i.e., unique) way of carrying out a work process in a particular situation but explicitly also considers the configuration of involved actors and their individual experiences and expertise.

Following this actor-centric approach, the use cases visualized on the right margin of Fig. 6.13 can be identified. According to the terms of Firestone and McElroy (2003), the different types of descriptions representing knowledge can be considered to cover the explicitly codified part of the repository (in contrast to non-codified subjective knowledge and knowledge implicitly codified in technology-based work support systems).

Fig. 6.13

Transactive memory concept used for the codified part of the repository (according to Neubauer et al. 2013)

Role knowledge is considered that part of organizational information that is mutually agreed upon or considered an organizational guideline of how a certain role in a particular work process should act. That corresponds to the task bundles with their proposed roles and tasks described earlier. In addition to role knowledge, each actor has instance knowledge that is different from the formally agreed upon view, goes beyond it, and potentially leads to different behavior in particular situations (dashed frames in Fig. 6.13).

6.4.3 Process Knowledge Elicitation and Knowledge Claim Development

Following the actor-centric approach, process knowledge has to be collected from the people actually performing the work processes. While there might be an organization-wide defined way of carrying out work for a particular class of processes, such models cannot cover all specifics of process execution that come with experience and expertise in knowledge-intense processes. These specifics, however, have to be collected, if individual or—even more—organizational learning processes should be enabled. This includes

• individual reflection of how work processes have been performed historically by oneself, and

• inter-individual alignment of understanding of how a cooperative process is performed introducing actors to how they can implement a role for a particular class of processes under given basic conditions or even in a particular situation

Fundamentally, process knowledge elicitation is a two-step process, where the first step is optional: (i) In-situ process collection, adaptation, and refinement, and (ii) process knowledge collection, reflection, and alignment.

6.4.3.1 In-situ Process Collection, Adaptation, and Refinement

In-situ process collection, adaptation, and refinement refer to activities that are conducted during and as an integral part of the work process (‘in-situ’).

Process collection refers to activities that build representations of process knowledge from directly within the work process. The information necessary to do this can be collected technically or using methods from social and cognitive sciences. On the technical side, information can be collected from workflow support systems or groupware that technologically mediates the work processes and can keep track of the activities performed with its help. If technological means are not available or their use is not appropriate (e.g., due to generated overhead or privacy reasons), methods to diagnose how people perform their work (such as “storytelling”, Santoro et al. 2010) and to diagnose their motivations and reasons for acting in a certain way (such as “thinking aloud”, Van Someren et al. 1994, or “structure elaboration techniques”, Groeben and Scheele 2001) are used, both being recognized methods to learn about an actor’s mental models.

Process adaptation and refinement is a requirement specific to actor-centric process modeling, as deviations from potentially pre-specified task bundles have to be possible and can be kept track of technologically. Even specifying a task-bundle variation from scratch during its execution has to be possible—the virtual enactment instrument described in Chap. 5 allows for such scenarios of operation.

6.4.3.2 Process Knowledge Collection, Reflection, and Alignment

Process knowledge collection refers to dedicated modeling activities that are conducted before or after the actual workprocess execution. Using the KLC as a frame of reference, this step is located in the knowledge processing environment.

This step can be carried out based upon data collected in situ throughout step 1, can build upon previously built process or task bundle models (e.g., for reflective purposes), or can start from scratch if process knowledge is to be represented for the first time.

Methodological support in performing these activities is even more important here than it was in step 1. While some information in step 1 could be collected technologically without any direct involvement of the actors, knowledge externalization in step 2 can only be performed directly by the actors. The process of externalization has to be guided methodologically in order to, on the one hand, not restrict users in expressing their perceptions on their work contributions, and, on the other hand, capturing this knowledge in a communicable form, codified for further processing. Technical tools can be used as support measures; however, their use should be informed and guided by methodological considerations.

Promising methodological approaches for process collection and refinement are structure elaboration techniques and concept mapping approaches. Both have proven to aid externalization of mental models (as noted earlier, these mental models guide individual task implementations) and support the development of a common view on cooperative task bundles.

The second aspect of methodological support, to allow for capturing of knowledge in a communicable form to be further processed, requires to guide actors from their initial, unrestricted form of process visualization (e.g., created using open structure elicitation techniques or concept mapping) towards a more structured, refined version that uses a defined language for representation and is sufficiently specified to be mapped to micro-processes, that, in turn, allow for delivering process support during task execution. While still open at this point in time, this aspect will be approached with a scaffolding approach (as known from individual learning support) that provides guidance for actors in refining their models towards the desired target format.

6.4.4 Process Visualization for Elicitation and Reflection

Situation-specific process representations, as introduced earlier, are not an appropriate means of process visualization for actors refining, reflecting upon, or aligning their views on their work. A more accessible presentation of the model has to allow for in-depth visualization of individual contributions and interactions while still maintaining the overall view on the whole process, or at least the task bundle variant. Additionally, the influencing factors have to be visible and configurable from within this presentation.

6.4.5 Process Validation and Simulation for Reflection and Alignment

Knowledge Claim Evaluation requires checking whether a newly proposedknowledge claim appropriately solves the problematic situation and will work in organizational reality when applied in the business processing environment. For knowledge about work processes, a common approach to evaluation is to conduct validation and simulation activities. In both cases, the process is enacted in an artificial environment to examine its properties during execution and draw conclusions for its real-world implementation.

Validation refers to activities that involve actors in process evaluation and allows them to directly enact the process in an artificial environment. They can uncover problems and inefficiencies in the process in this way and directly apply their experiences to the knowledge claim in the course of the “individual and group learning” feedback cycle in the KLC knowledge production step. Validation can be implemented in different ways, varying in the depth the artificial environment enactment happens in, that is, how closely the model of the environment matches the real-world work environment and how many parameters characterizing the current work situation can be accounted for.

Simulation in contrast to validation does not directly involve actors in the execution of a process for evaluation purposes. Simulation rather applies statistical models to represent environmental parameters (e.g., how often a process is triggered, how long it takes an actor to complete a task) and uses IT-based instruments to automatically enact a process. Process models in general, and the flexible process representation approach proposed here in particular, have a large number of potential instantiations due to the choices that can be made during execution. While during validation only some cases can be evaluated, simulation can be used to check the process as a whole and uncover problems in any of the potential instantiations.

The subject-oriented approach requires simulation to explicitly consider the work being executed in parallel by different actors and being aligned by acts of communication among these actors. The ASM-approach to S-BPM proposed by Börger (2012) provides a starting point here for being able to formally verify a process (e.g., identifying deadlocks) and simulation with an ASM-implementation based on multi-agent system (cf. Lerchner 2015; Lerchner and Stary 2016).

6.5 Conclusion

Starting out with organizational development in an actor-centered way requires a value chain in digital work design that keeps actors involved. Hence, in this chapter, we have integrated the methods and instruments presented in the former chapters in a coherent framework and have identified design space elements for various tool chains supporting stakeholder-based agile work design. The integration process, however, was challenged by the contextual elicitation and alignment activities to be coordinated for stakeholder-centered learning and process development—the conceptual and empirical findings provided a rich set of design elements, such as tasks, business objects, various relationships, and levels of abstractions, and indicated intertwined learning loops which are indirectly synchronized by a design repository (Documented Knowledge Base).

The framework for practical design support proposed in this chapter is based on four elementary components, namely, (i) a front-end for articulation and elicitation of work knowledge, (ii) a learning environment coupling content with communication features, (iii) a container facility for multiple content types, and (iv) a processing component for automatically executing business processes. They allow reflecting on existing work practice and formulating knowledge claims that need to be negotiated before fed back to a Documented Knowledge Base interfacing the operational (business processing) environment. In this way, digital work design becomes a traceable and transparent way for stakeholders.