Keywords

This chapter demonstrates the use of the proposed framework and the embedded methods. It shows their interplay and describes the impacts that could be observed in real-world cases. This chapter is practice-oriented and could provide students and practitioners with anchors to reflect on the proposed methods and underlying theories from a “doing” point of view.

The first case (Sect. 8.1) demonstrates how meaningful work-model entities can develop in the course of articulation and guide aligned re-structuring of work. It stems from a complex setting, namely, planning in clinical health treatment requiring the structured elicitation of contextual knowledge from all stakeholders involved to develop working procedures in time-critical situations. Sharing expert knowledge from doctors, nurses, technicians, administration, and patients was supported by collaborate development of instruments and tools.

The CoMPArE/WP (Collaborative Model Articulation and Elicitation of Work Processes)-case (Sect. 8.2) has its focus on alignment when bridging from intuitive or semi-structured models to techno-centric (formal) models that can be executable for some workflow engine. It demonstrates effective stakeholder participation while eliciting and consolidating elicited work knowledge. The illustrative case shows an application of the respective concepts explained in Chap. 4.

The third case (Sect. 8.3) targets articulation and alignment of educator knowledge, a highly complex task, as it involves domain knowledge, didactic competence, and social skills. However, applying the instruments and the concepts presented in this volume helped generate a working model for digitalizing learning support in a transparent and intelligible way for educators. Thereby, semi-structured elicitation and stepwise refinement to digital support features turned out to be essential facilitators.

The Me2Me2You-case (Sect. 8.4) has its focus on alignment when bridging from intuitive or semi-structured models to techno-centric (formal) models that can be executable for some workflow engine. It demonstrates effective stakeholder participation while eliciting and consolidating elicited work knowledge. The illustrative case represents a proof of the respective concepts explained in Chap. 4.

Our starting point in revisiting the cases is the framework for articulation, alignment, and processing developed in Chaps. 6 and 7. We indicate the involvement of each component by giving visual clues in the framework diagram. Then the case study is described as it evolved in the specific application context. Overarching objective of each presented case was to achieve stakeholder-driven digitalization of work processes, thus transforming existing socio-technical systems to be perceived by actors resilient to socio-technological capabilities rather than disruptive for the respective organization.

8.1 Categorical Knowledge Building Support—A Planning Case

This case concerns the transformation of an expert organization performing critical tasks in healthcare. The frame of reference for digital work design enabling expert participants to gradually develop a model of their planning process in a cooperative way can be mapped to the case, as shown in Fig. 8.1.

Fig. 8.1
Two images. The first image depicts the interconnections among components enclosed within a triangle, a rectangle. and a circle. The second is a process-flow diagram that includes the front end, B P M, back end and the repository. The repository connects to content and social media.

Embodying the planning case into the digital work design framework

This healthcare planning case has been part of an organizational development process of an Austrian healthcare institution. The case targeted qualifying clinical staff on the fly in system thinking and organizational learning, when dealing with a common problem in healthcare—planning (Bardram and Hansen 2010). It affected around 40 experts from different fields and involved 14 of them in developing systemic treatment planning. The organizational learning step concerned aligning human and resource planning. It involved doctors, nurses, technicians, administration, and patients when collaborating in planning.

The facilitator’s task was to design and facilitate eliciting mental models of doctors, nurses, and technical and administration staff in order to create a systemic orientation space for changes. That space should enable team learning while reflecting personal mastery (Senge 1990). Content-wise, the organization of planning, in terms of both scope and flow of information, should be re-designed.

Stakeholders also play a crucial role in the organizational change processes. Their reflections and ideas open the opportunity to further develop work systems. Figure 8.2 reflects the cognitive and social involvement of stakeholders and knowledge management activities in the course of organizational change.

Fig. 8.2
A chart depicts the knowledge interaction and knowledge management activities. The activities include cognitive focus, comprising knowledge generation and learning, and social focus, comprising sharing and exploration.

Leveraging stakeholder knowledge for organizational change

Most of the modeling approaches for work knowledge analysis provide a notation, which might be more or less oriented towards execution, such as the UML (Unified Modeling Language) or BPMN (Business Process Modeling Notation) (see www.omg.org). In order to minimize the cognitive burden and bias towards a specific notation, the project management team decided to provide means for articulation or elicitation rather than focusing on representation. Such approaches allow emergent semantics in the course of articulation.

Even in the field of Business Process Modeling, this direction has been followed. For instance, Cohn and Hull (2009) use (business) artifacts combining data and process as basic building blocks of modeling. Artifacts are key business entities (business-relevant objects) evolving when passing through a business’s operation. They can be created, modified, and stored. As a result, business operations can be decomposed along various levels of abstraction. Artifacts are typed using both an information model for data about the business objects during their lifetime and a lifecycle model, describing the possible ways and timings that tasks can be invoked on these objects. In this case, the representation “enables strong communication between a business’s stakeholders in ways that traditional approaches do not. Experience has shown that once the key artifacts are identified, even at a preliminary level, they become the basis of a stakeholder vocabulary” (ibid.).

From this kind of studies, we could conclude that evolving element and relation categories are of benefit for developing a stakeholder-oriented modeling and analysis approach. In addition, we suspected knowledge that would be conversed from tacit to explicit (Nonaka and Krogh 2009), since we focused on individuals’ experiences on a system-critical work situation, namely, a treatment planning procedure in radio oncology, and accurate articulation of these experiences. Such an approach goes beyond accumulating experience, as individuals and groups should figure out what works in which way, and why, and what could be changed in the execution of an organizational task. The facilitation task was driven by forming the group as a team in order to create sustainable models (Hillier and Dunn-Jensen 2013) while avoiding misinterpretations from external stakeholders in the course of articulation (Sandberg 2005).

In work, knowledgearticulation teams make a cognitive effort to enhance their understanding of the causal links between actions and outcomes while engaging in collective reflection to gain insight (see also Fig. 8.2). The codification, and thus collective availability of individual work knowledge, are considered key enablers, as they overcome barriers resulting from established relationships and conventions.

Facilitation did not start in the traditional way with predefining an articulation space through a dedicated notation to represent work elements. The facilitation rather targeted the capability of the involved stakeholders to express knowledge using their semiotics according to their individual perception of the functional roles involved in treatment planning of the patients. The reflection of the presented meaning has been used to justify the results of the common sessions on the current organization of worktasks, otherwise misinterpretations are likely to occur when post-processing generated knowledge (Sandberg 2005).

In the beginning of the series on change workshops, the involved stakeholders (doctors, nurses, administrators, and device experts) agreed on the goal of the endeavor, namely, maximizing the clinics’ treatment service for patients in terms of minimizing planning time. Knowledge codification was performed using concept mapping. It is used by groups to develop a representation of a domain, situation, or procedure (Novak 1995), and to capture content in its systemic context (Trochim 1989). The participants started by drawing or putting nodes (concepts, meaningful items) and relationships on a virtual or paper surface, according to their experiential knowledge—see Fig. 8.3.

Fig. 8.3
A photograph of blocks on the mapping of interactive concepts.

Interactive concept mapping (see also Oppl and Stary 2009, 2011)

8.1.1 Sample Case

Figures 8.4 to 8.7 show the start pattern pictured from the tabletop. It allowed revealing essential relations and language constructs for representing meaningful information from the group (Rentsch et al. 2010). The participants came up with an overview of roles and functional units (concepts) involved in patient treatment planning (red rectangles in Fig. 8.3 referring to doctor roles, e.g., case manager, and experts, e.g., LINAC system specialists). The (blue) half circle (Stereotaxie group) represents a group of people working on a particular topic involving several functional units (out-patient department, LINACs). The relationship the participants set was either ‘part-of’ ones, such as establishing the Stereotaxie group, or addressing the exchange of patient data (‘mutual communication’), the latter being central to coherent and consistent planning. The facilitator asked whether the concept map represented the relevant part of the organization before proceeding. Then, the participants enriched the map with auxiliary and enabling actors/work group, such as the secretary and device management group (yellow hexagons) in Fig. 8.4.

Fig. 8.4
A start map consists of various nodes including konventionelle, linacs, brachy, station, chef ambulanz, and ambulanz.

Start map

After having created the overview of involved actors and roles, as displayed in Figs. 8.4 and 8.5, the scope (situational context) has been set. Subsequently, the group decided to pick out major actors, such as the out-patient department, and to detail the patient planning-relevant process parts. They put the major steps to be followed for patient treatment planning into the middle row (red rectangles) of the map to arrange all other information along actual planning steps.

Fig. 8.5
A network of 14 blocks depicts the completion of the organization's relevant parts.

Completing the relevant part of the organization

Figure 8.6 reveals three categories of elements the group needed to detail the patient treatment planning procedure:

  • functions (red rectangles), that is, process steps according to their temporal order (from top to bottom)

  • decision and operation bodies (blue half circles) required to proceed

  • roles (yellow hexagons) representing medical or administration staff handling the process steps either in the sense of front or back office

Fig. 8.6
A network of 11 blocks depicts the planning of out-patient-oriented treatment.

Patient-oriented treatment planning (out-patient department)

Figure 8.5 also reveals three categories of relationships required to represent work tasks for further analysis:

  • temporal order of functions, that is, directed edge between functions

  • hand-over functions, that is, directed edge between roles, depending on who takes care of the patient in a certain step

  • dedicated assignments of roles to functions or organizational bodies, that is, directed or non-directed edge

Both types of information are required to specify process-relevant settings. Structural elements, such as functions, are the prerequisite to set temporal relationships and need to be put in mutual context with other structural elements, such as roles. Interestingly, the participants specified several flows, namely, the function flow, and the ‘responsibility’ flow in parallel distinguishing information flow in addition to the function flow.

Figure 8.7 shows how this (re)presentation logic could be kept until the envisioned steps of planning have been articulated. The LINAC team does the fine-grain adjustment of plan data to enable the actual treatment of a patient by the respective technical system.

Fig. 8.7
A network of 16 blocks depicts the treatment planning finalization. The three sections of interconnected blocks are the instruments and tools triangle, the work process building blocks rectangle, and the back office oval.

Finalization of treatment planning (LINAC)

Figure 8.7 also shows the spatial grouping of notational elements the stakeholders identified when being facilitated to develop their planning process. The middle part was dedicated to the functional core in terms of the objectives, namely, patient orientation throughout treatment planning. The left part reveals the instrument part, both in terms of tools required for planning and treatment, and organizational decision-making, such as the tumor board. The right part denotes the back office roles and exchange patterns that are required to accomplish the core work process tasks shown in the middle part.

8.1.2 Insights

What kind of support could stakeholders need when getting involved actively in transforming work processes? The findings indicate that:

  • Eliciting knowledge requires an open format for articulation and collaborative reflection (semantic openness). Hence, predefined notations, such as BPMN (www.bpmn.org), would restrict articulating work knowledge and inputs for change, as the case study reveals, considering functions and actors as integrated concept in the beginning.

  • Knowledge codification needs to be accompanied by sharing knowledge to be accessed and reflected by others—representations, such as concepts or business process models, serve as baseline for discussion and discourse.

  • Middle-out tops top-down and bottom-up analysis—it reflects social dynamics within the scope of modeling.

  • Intertwining the content perspective with social processes helps not only for reflecting a situation ‘as-it-is’ to come up with ideas ‘as-it-could-be’, but also setting the context of work procedures in terms of relevant factors for task accomplishment.

Consequently, it seems neither developers nor stakeholder is prepared for effectively participating in developing work (re)designs. Hence, a learning perspective open for content generation and dissemination seems to be appropriate for stakeholder-driven organizational development.

Of crucial importance seems to be the role of the facilitator who should pre-condition the process by clarifying the semantic openness when expressing experiences and ideas for change. Another observation concerns the interface between individual learning and organizational development: Each mental model needs to have its place and space before starting the team learning process.

8.2 CoMPArE/WP Facilitating Project-Based Business Operation

This case reflects on developments towards human-centric modeling of work. The frame of reference enabling process participants to gradually develop a comprehensive model of their business process in a cooperative way can be mapped to this case, as shown in Fig. 8.8.

Fig. 8.8
A schematic framework depicts the digital work design for the CoMPArE approach from the front end to the back end.

Embodying the CoMPArE approach to the digital work design framework

We provide the illustrative case ‘project set up’ as it has been performed in the course of validating the approach.

As already mentioned, the design of the CoMPArE/WP method is based on conceptual considerations derived from the aims of intuitive human modeling. Its components are informed by procedures and concepts identified to be supportive in reaching those aims in existing research. The novelty of CoMPArE/WP lies in the combination of those procedures and concepts in order to reach the aims of natural modeling while providing a well-defined bridge towards techno-centric modeling. The goal of validation in this article therefore is to show that the method facilitates natural modeling and at the same time enables participants to produce a techno-centric model of the business process. Consequently, the validation questions can be derived from the design goals, as formulated in Chap. 4:

  • Q1. Are the modeling participants able to semantically interpret the used notation(s) intuitively in the way specified by the method?

  • Q2. How do the created models facilitate knowledge sharing and promote negotiation?

  • Q3. To what extent does the approach enable the modeling language to emerge dynamically based on the situation at hand?

  • Q4. Do the final modeling results provide the syntactic and semantic quality of techno-centric models and allow for further processing in IT-systems?

These questions imply the existence of an organizational context in which actors can develop different views on a business process, calling for case study research. We thus present in the following an illustrative case study that demonstrates the implementation of the CoMPArE/WP approach in a real-world setting. Methodologically, the validation requires to qualitatively document and analyze both the process and the result of modeling in the different method components with respect to the formulated questions. Consequently, the modeling process of the case study was video-taped and analyzed with respect to the validation questions asynchronously. The modeling results of components 1 and 2 were photographed and transcribed to digital versions for easier assessment. The results of component 3 were exported from the used BPMS. The documented results and observations made in the case are used to discuss how the requirements of natural modeling are met while maintaining the bridge towards a technically interpretable business process model.

8.2.1 Sample Case

The case presented in the following is situated in an organization that undertakes software development projects. At the beginning of every project, the project set-up process is conducted aiming at agreeing upon the project’s scope, the relevant stakeholders, the timeframe, and so forth. The project teams always consist of a set of developers, who are led by a team leader. Ongoing communication with the client is ensured by a dedicated contact person (who might also be a developer). In addition, there are mentors who formally do not belong to the team, but are experienced project managers supporting the project teams and acting as backups, in case interventions become necessary.

The aim of the CoMPArE/WP workshop was to investigate the effectiveness of the CoMPArE/WP approach regarding a) the active involvement of process participants in business process design and b) the transition to a comprehensive process model. Representatives of the following roles took part in the workshop: a team leader, a mentor, a contact person, and a client. In addition, a facilitator was involved to guide the process methodologically. One observer was present to document the results and the process of the workshop for later evaluation. The workshop was carried out in two parts. The first three-hour block was dedicated to the first two components of CoMPArE/WP. Based on the outcomes of this first part, a model was built using the CoMPArE/WP language (based on the who, what, exchange constructs). This was used for virtualenactment in the second part of the workshop, which lasted two hours.

8.2.1.1 Component 1: Setting the Stage

The four modeling participants implemented the first component of CoMPArE/WP by creating a model that described the relevant concepts in the context of clarifying the scope of a new project. They individually collected concepts each of them considered important, and subsequently consolidated them in a shared model.

The identified concepts were complementary, as the modeling participants focused on different aspects of the business process. Consolidation consequently required effort in making mutually transparent the individually selected foci and explaining their meaning. However, no discussions on the relevancy of certain concepts arose, and all concepts were finally incorporated in the model.

Figure 8.9 shows a conceptualized transcript of the model. On the right, a photo of the workshop’s actual card setting is presented. As shown in this photo, the cards bear the visual markers for digital recognition mentioned earlier. Also, a big table constituted the sharing modeling surface, and thus connecting arrows were drawn directly on the cards.

Fig. 8.9
A chart and a photograph depict the result of the component, setting the stage.

Result of component 1—“Setting the Stage”

The identified concept classes largely centered on the different involved roles (operative in the project team—OpRole; as well as roles that support the process within the organization—SupRole; and client-side roles—ClientRole) and relevant information items (InfoItem) that were backed with sub-items in the case of the project description (visualized at the bottom of Fig. 8.9). In addition, skills required within the project team (ReqSkill) as well as the aim of the process (Aim) were identified.

The concepts were clustered along two dimensions: the sequence of elements running from top-left to the bottom-right of the model, indicating the fundamental procedure of clarifying the project scope with the customer. It thus can be considered to represent an “external perspective” on the project setup process. The ostensible sequence in the first cluster, however, does not describe a process, as it does not rely on activity-describing concepts, but mixes other, structurally motivated concept classes. The second cluster of concepts can be considered to cover the “internal perspective” on the project setup process and has identified the necessary skills and involved operative and support roles.

The open semantics used in this component enabled both the agreement on relevant conceptual classes (like aims, skills, roles, and information items) and their clustering in terms of perspectives to be considered when thinking about the business process for project setup (internal needs vs. externally visible collaboration and artifacts). The elements marked with bold outlines were directly reused in individualarticulation and subsequently were incorporated in the consolidated model version. The remaining elements (drawn with narrow stroke outline) were not incorporated in the following steps but left as contextual information, describing the context of the process.

The outcome of the first modeling step thus clarified the scope of the business process to be reflected upon and outlined its fundamental building blocks. It furthermore validated the selection of the involved roles. Consequently, concepts specified in the first component were reused in later modeling steps indirectly by the modeling participants, who picked them up again during individualarticulation.

8.2.1.2 Component 2.1: Individual Articulation

In the second component, the modeling participants individually described their own perceived involvement in the business process and their interaction with others. The individual modeling results are shown in the following. As the connecting arrows were drawn directly on the cards, explicit representations of sources and targets in communication acts have been added in the conceptual transcriptions for easier understandability.

Figure 8.10 (left) shows the model created by a modeling participant representing the client. Content-wise, one notable modeling choice here is the strong involvement of the team leader in communication, while at the same time communication with the formally responsible contact person is completely omitted.

Fig. 8.10
Two charts and two photographs display the result of the component, individual articulation, representing the client and the contact person respectively.

Result of component 2.1—“Individual Articulation” for participants representing “Client” (left) and “Contact Person” (right)

The perceived involvement of the contact person is shown in Fig. 8.10 (right). The modeling participant representing the contact person basically described the formally prescribed procedure of acting as the primary contact for the client and involving the mentor during project implementation, after the problem description has been settled upon.

The model incorporates a syntactic deviation from the proposed modeling language as EXCHANGE elements were used to describe mutual communication processes. The proposed syntax defines EXCHANGE elements to always have exactly one source activity and one target activity, representing a unidirectional flow. In terms of natural modeling, however, this is a valid use of the element as it takes a coarser approach to describing exchange of information, which can be refined in later steps when developing towards a model that is useable for workflow execution.

The model shown in Fig. 8.11 (left) represents the mentor’s view on the business process. It describes an intervention in the late stage of the scope clarification, where the mentor communicates with a management representative of the client and the operative contact regarding relevant stakeholders in the client company and then agrees on a follow-up meeting during the project with the customer contact person in the project team. The mentor was the only modeling participant, who distinguished between different client roles.

Fig. 8.11
Two charts and two photographs display the result of 2.1, individual articulation representing the mentor and the team leader respectively.

Result of component 2.1—“Individual Articulation” for participants representing “Mentor” (left) and “Team Leader” (right)

The forth individual model shown in Fig. 8.11 (right) represents the team leader’s view on the business process. It largely matches the view of the client, in which the main tasks of project setup are shared by the two of them—in contrast to the company-wide guideline, which stated that the contact person should be the sole face to the client. Structurally, the model contains bidirectional exchange attached to single activities, like in the model of the “contact person.” Similar to that mentioned earlier, the participant was not able to describe a more detailed interaction process for his perceived tasks and thus—as proposed in principle 3 of natural modeling—dynamically adapted the modeling language to be able to represent his perceptions.

Overall, individual articulation lasted around 30 minutes and was carried out without any communication between the modeling participants. The facilitator intervened methodologically once in clarifying the meaning of EXCHANGE elements for the person representing the customer contact. The other modeling participants did not have any issues with understanding and using the modeling elements according to their description.

8.2.1.3 Component 2.2: Collaborative Consolidation

Figure 8.12 shows the agreed upon card-based model of the business process of the collaborative consolidation, using the same unique identifiers for elements as specified in the individualarticulation models. The only element that has not been incorporated in the shared model was “final meeting” (originally contributed by the contact person). This EXCHANGE element was agreed during collaborative modeling to be superficial, as it was beyond the scope of the business process. Some elements have been added, mainly to reflect the activities of the originally underestimated role of the team leader. Added elements are marked with a bold outline in the schematic drawing in Fig. 8.12. In the following, we describe the changes made during consolidation and outline their rationale as given by the modeling participants (extracted from workshop recordings).

Fig. 8.12
A chart and a photograph display the result of 2.2. colaborative consolidation.

Result of component 2.2—“Collaborative Consolidation”

The consolidated model shows the business process from an overall perspective. In a collaborative effort, the modeling participants reached common ground on the issue of who should be the primary contact to the customer during project setup. The modeling participants followed the argumentation of the client representative, who claimed that it was crucial to involve the team leader in the early phases of a project to create a clear and unbiased image of the client’s needs. Consequently, the role of the customer contact was reduced to acting as a supporter for the team leader during the project setup phase and only taking over operative communication after the successful kick-off of the project. The modeling participants also recognized the need for phases of intense communication between the team leader and the client, which is indicated by the double-linked EXCHANGE elements “clarify scope and content” and “potential new systems.” Following the argumentation of the team leader, the other modeling participants also refrained from detailing the communication any further and identifying distinct acts of information exchange in those phases. The same holds true for the communication between the mentor and the customer contact at the very bottom at the model (indicated by the matched and merged EXCHANGE elements “info about project progress”). Additions to the model (all elements with a bold outline) were added by the modeling participants representing the affected roles. In all four cases, this was triggered when they were confronted with EXCHANGE expectations of communication partners which they could not meet with existing WHAT-elements.

The CoMPArE/WP methodology should lead to pair-wise matching EXCHANGE elements, one element representing provided EXCHANGE created by the sender and one representing expected EXCHANGE created by the recipient. This matching, however, was done only three times. The lack of further matches can be attributed to the role shift in interaction with the customer, which was not reflected in the individually articulated models of the customer contact person and the mentor. In addition, the EXCHANGE elements “ask for meeting with stakeholders” and “sends meeting dates,” originally targeted at the client in the individually articulated model of the mentor, were not matched by the client in the consolidation phase. The representative of the client was not able to describe a WHAT-element that would have been triggered by the received message and would have led to send the response, and thus left those two EXCHANGE elements dangling. This leads to a temporary under-specification of the model, which causes issues that need to be resolved during virtualenactment.

In a final step, the results of component 1 (“Setting the stage”) were checked against the outcome of collaborative consolidation. Regarding constructs, the participants were not able to match the concepts describing skills and the aim of the process. These concepts were left aside for later consideration.

As far as content is concerned, the participants discussed the concepts representing roles and information items. They were able to confirm semantic equivalence to WHO and EXCHANGE items, respectively: “Team Leader,” “Contact Person,” and “Mentor” were directly matched. “Client CEO” and “Client contact” were only used as separate items in the mentor’s individual articulation, whereas all other participants only worked with a single “Client” element. During reflection of collaborative consolidation, this issue was addressed again. The participants used a single client element in the consolidated version, as they agreed that distinguishing between the Client CEO and Client contact was not necessary and relevant for the depicted scenario. “Problem description” was directly reused in component 2 by the contact person, “Current situation” was reused by the client. Other InfoItems were identified during reflection on semantical equivalence: “Necessary Improvement” was matched with an element by the contact person, “Responsibilities” and “Project Scope” were covered by elements contributed by the team leader, and “Stakeholders” was subject to modeling in the sequence stating at “ask for stakeholders” in the lower part of the consolidated model. The remaining concepts that were considered to be potentially relevant during component 1 have not been incorporated in the result of component 2. They were still considered relevant for understanding the business process and consequently remained as context information.

8.2.1.4 Component 3: Virtual Enactment

For virtual enactment, the model was transformed to a syntactically correct process model (cf. Fig. 8.13). The source model has some semantic ambiguities that hamper direct enactment, as the BPMN model is semantically underspecified.

Fig. 8.13
A framework depicts the business process modeling notation that includes a mentor, contact person, team leader, and client.

Result of transformation to BPMN

The affected elements are EXCHANGE elements of the team leader and the contact person, where the exact point in time of EXCHANGE is not specified. In addition, the EXCHANGE elements of the mentor directed at the client are not explicitly considered by the client for receiving and sending, respectively, at all. Consequently, the first group of ambiguities was transformed to mutual message flows connected to the respective activities, whereas the second group of messages was transformed to message flows connected to the targeted pool representing the client. All other exchange elements were mapped to message flows, with corresponding throwing and catching message events.

This model was used for virtual enactment to identify necessary refinements and extensions of the process model. This was done in a second workshop, in which a representative of the team leader role was also involved. An example for refinements through virtual enactment in shown in Fig. 8.14, where the initial refinement step made in the workshop is shown. The original version of the team leader’s behavior is shown on the left and the refined description of the behavior is depicted on the right. The elements with task names set in italics have been added during refinement. The refinements in this step do not affect any other pools; thus, no cascading changes were necessary.

Fig. 8.14
Two process diagrams depict the difference in the framework between the original process and the refined process.

Example of refinement (left: original process; right: refined process)

In the later phases of virtual enactment, the semantic ambiguities still contained in the model were resolved. For the underspecified EXCHANGE elements, a more detailed description of the communication procedure (to be implemented in future) was created, whereas the dangling EXCHANGE elements of the mentor were removed, reducing the mentor’s role to an internal one, only interacting with the client contact person and the team leader. When making these changes, the model gradually evolved from depicting the as-is-process to depicting a to-be-process, envisioning improvements to the collaboration setup via playing through the process model. The case study was concluded after this first iteration through the modeling and virtual enactment process.

8.2.2 Observed Effects

The following discussion of the evaluation results is structured along the validation questions formulated earlier.

  • Q1—Intuitiveness of modeling: Ex-post feedback of the workshop’s modeling participants revealed that they enjoyed their engagement in process modeling. They felt that they had generated added value for their understanding of the business process itself and how it is embedded in the process landscape of the organization. In the case study, the incremental rise in the modeling language complexity throughout the phases in particular helped the inexperienced modelers become familiar with reading and understanding models and using them as a form of expression for their own viewpoint, facilitating in this respect the externalization of tacit knowledge. Tangibility of the modeling elements (i.e., their physical presence in the form of cards and the chance to directly manipulate them) seemed to have a positive impact on the “intuitiveness” of the modeling process itself. One participant in the case study, agreed by the others, stated that “not having to master a computer tool before being able to contribute” provided added value over more traditional computer-screen-based means of modeling support.

  • Q2—Facilitationofknowledge sharingandnegotiation: The process of modeling and refining the model through virtual enactment is inherently cooperative in all its components, which have been successfully implemented to this respect in the case. Alignment of concepts and constructs in particular has been facilitated in the second component, which, by design, focuses on uncovering ambiguities and different perceptions and facilitates the development of a shared understanding. The fundamental content-wise revision of the business process during collaborative consolidation in contrast to the individually created model parts is an indicator that knowledge was not only successfully shared among the modeling participants but also has been actively co-constructed via negotiation processes. This observation is confirmed by results of further studies of a variant of this component reported on in Oppl (2016).

  • Q3—Emergenceof modeling language semantics: During concept mapping applied in component 1, the used language constructs emerged fully dynamically during modeling. In component 2, the set of language constructs was more restricted, but still left room to adapt to the situation at hand due to their abstract nature. The modeling elements used in component 2 (WHO, WHAT, EXCHANGE) were intuitively used correctly (i.e., according to their prescribed semantics). A drawback of the reduced set of modeling elements, however, became apparent during collaborative consolidation. The lack of a structured approach to specify the content of EXCHANGE elements led to “vague” definitions (Herrmann and Loser 1999) that neither reflected nor facilitated the achievement of agreement on the transferred information or artifacts. This, however, could be compensated for during virtualenactment, when the resulting “vague” message flows were refined with scaffolds provided by the facilitator.

As it can be seen in the case description, nearly half of the concepts identified in component 1 were reused in component 2 as a foundation for individualarticulation and for collaboratively reflecting on the outcome of consolidation. The benefit of open semantics as used in component 1 is that it makes visible how to reconcile fundamentally diverging viewpoints on the scope of the process and the vocabulary used to describe it. Both issues were hardly present in the case study, so that the added value of component 1 was to confirm the already shared understanding of what the project setup process was about and to produce an artifact that later could be used for reflection of the process modeling results.

  • Q4—Evolutionof techno-centric models: The model resulting from performing component 2 semantically depicted a single scenario of the complete process and was syntactically compatible to BPMN. The transformation process led to a model that already met the aim of producing a syntactically correct business process model. This model was then used for semanticrefinement through virtualenactment in component 3. Only at this point, a semantically fully refined modeling language (BPMN) was used for representing the process. During virtualenactment, the participants, however, were not directly confronted with the BPMN model representation, but performed refinement by describing their additional or altered process steps in the BPMS. The process of refinement, however, was perceived to be cumbersome due to the lack of appropriate tool support in the prototype. Participants had difficulties to appropriately describe their additional process steps appropriately, in particular when additional message exchange was required. Picking up sent messages on the receiving side was confusing for the participants, as the user interface did not appropriately guide them to resolve such temporary process inconsistencies. Although these situations could be resolved by the facilitator, they require further research and development.

Summary: According to our overall experience acquired through the case study, the method has succeeded in implementing the principles of natural modeling and has achieved to actively involve process participants in modeling, leading at the same time to the production of a BPMN model, which can act as the basis for further techno-centric processing. The case study, however, also illustrated challenges in the design process, in particular at the gateways between the methodological components. The role of a facilitator still appears to be of high importance for guiding through the articulation and consolidation process. The major challenge here seems to be prompting participants in a way that facilitates description of their work so that the semantics of BPMN elements the model is transformed to later on is accommodated. This has not been fully successful in the described case, which caused higher effort during transformation to BPMN. Facilitator’s guidance appears also to be required for applying correctly the modeling guidelines. It is notable that participants failed to correctly refine the labels of the EXCHANGE elements, after their transformation to BPMN message flows, for use in component 3. In component 2, they partially used verbs instead of nouns that are normally used to indicate exchanged messages in BPMN and were not aware of the need to change that until the facilitator intervened.

8.2.3 Insights

The approach aims at actively involving participants in business process modeling to adjust elicitation and modeling steps of work processes. Active involvement of process participants creates several challenges, as the latter are not expected to have modeling skills, and thus require facilitation for elicitation and formulation of the models in a way that allows for technical processing of the results. The CoMPArE/WP approach meets successfully this goal by operationalizing the principles of natural modeling while, at the same time, providing a transition to a representation of a business process that can be enacted by a BPMS.

As also revealed by the case study, the gateways between the methodological components constitute the major challenge in the application of the approach. CoMPArE/WP has tackled this issue by introducing a simple intuitive modeling language (consisting of the fundamental process concepts who, what, and exchange) that bridges the gap between the human-oriented card-based model of the first components, which uses open semantics and the techno-centric process model created in the last component.

The approach enables participants to gradually develop structured business process models and does not confront them with the complexity of fully elaborated process models. While the transparency of the complexity of the developed model has been a design goal, it can be, at the same time, considered the most fundamental disadvantage of the approach, as it prevents to develop an in-depth understanding of the resulting process model by the modeling participants. Furthermore, the elicitation strategy of the methodology is focused on the individual perceptions of the business process contributed by the participants and does not consider potentially divergent process views of other stakeholders, which are not directly involved in the modeling process.

8.3 Articulating and Aligning Digital Learning Support Features

This case reveals the benefits of eliciting, encoding, and different perspectives on information elements relevant for human-centered work design. The case ranges from articulating educational designs and tagging didactic content to purposeful navigation and traceable digital learning spaces, featuring concept maps as overarching representation scheme. By understanding such application development as a learning process itself, representation techniques need to enforce systemic understanding (Christian Stary et al. 2015). The frame of reference for digital work design enabling educators to elicit and align didactic concepts with learning support for collaborate classroom design can be mapped to the case, as shown in Fig. 8.15.

Fig. 8.15
An infographic on digital work design framework depicts charts, screenshots, and process diagrams.

Embodying the educator case to the digital work design framework

Since this case requires some insights into the domain of digital learning support, we will briefly provide the rationale for the addressed work practices and knowledge representation concept. Details on this case can be found in in the works by Auinger et al. (2007), Neubauer et al. (2011), Oppl and Stary (2009, 2011), Christian Stary (2016), Christian Stary et al. (2015), Weichhart (2014b), and Weichhart and Stary (2014).

Although digital learning support has been investigated and developed for quite a while, the quest for goal setting in technology-supported education and digital learning support is still valid (Feldstein 2014). With respect to the effectiveness of pedagogical models, one of the commonly agreed cornerstones of learning support developments, a shift in design thinking seems to be required; quoting George Siemens (from Feldstein 2014):

The connectionist view that learning is a network creation process significantly impacts how we design and develop learning within corporations and educational institutions. When the act of learning is seen as a function under the control of the learner, designers need to shift the focus to fostering the ideal ecology to permit learning to occur. By recognizing learning as a messy, nebulous, informal, chaotic process, we need to rethink how we design our instruction. Instruction is currently largely housed in courses and other artificial constructs of information organization and presentation. Leaving this theory behind and moving toward a networked model requires that we place less emphasis on our tasks of presenting information, and more emphasis on building the learner’s ability to navigate the information (i.e. connectivism). (Siemens 2005)

Such “educational goals … are framed in direct contrast to the traditional methods and goals of schooling” (Feldstein 2014, p. 4). They need to take into account cultural factors beyond cognition and technology and are likely to affect the role of understanding of teachers and learners, such as induced by Richard D. Garrison’s (unifying) transactional perspective:

While knowledge is a social artefact, in an educational context, it is the individual learner who must grasp its meaning or offer an improved understanding. The purposeful process of facilitating an outcome that is both socially and personally worthwhile goes to the heart of the teaching and learning transaction. This transaction is common to all educational experiences, including digital learning support.

Hence, an educational experience has a dual purpose. The first is to construct meaning (reconstruction of experience) from a personal perspective. The second is to refine and confirm this understanding collaboratively within a community of learners. At first glance, this dual purpose would seem to reflect, respectively, the distinct perspectives of the teacher and student. However, closer consideration of the transaction reveals the inseparability of the teaching and learning roles and the importance of viewing the educational process as a unified transaction. We are simply viewing the same process from two different perspectives. These two perspectives raise fundamental questions concerning issues of responsibility for learning and control of the process. (Garrison 2011, p. 62)

In digital learning support designs, reflection of educators and increased learner control have been parts of shifting from teacher-controlled to self-directed learning processes (cf. Dabbagh and Kitsantas 2012). Since it affects educational settings, didactic elements increasingly get questioned by principles of mathetics (Gilbert 1962; Scott 1968). When educators share the responsibility of the learning process with learners, the preparation of the environment becomes essential for self-managed learning (Eichelberger et al. 2008). It is for digital learning support of particular importance to get learners interested in being exposed to various learning modes (termed polyvalent by Leclercq et al. 1977), exploiting a variety of methods and resources on provided content elements (Duckworth 2006). As such, digital learning support designs require not only transparent acquiring and representing how content is prepared for learning, but also revising interaction facilities and information structures, for example, recognizing the social character of transfer processes (Derouin et al. 2005).

Concept maps (Novak and Canas 2006) are widely used as effective and valid means to elicit, represent, and share knowledge (Moon et al. 2011). Albeit being traditionally utilized in educational settings (Markham et al. 1994; Novak 1995; Kinchin 2000), they have been introduced to organizational learning (Peris-Ortiz et al. 2014; Kolb and Shepherd 1997), as they allow

  • making ‘thinking visible’ in a socially accepted way (Collins et al. 1991)

  • embodying cognitive and social learning experience (Roth and Roychoudhury 1993; Roth and Roychoudhury 1992)

Their fundamental structure and handling is kept simple and can easily be conveyed to different stakeholders. As such, they qualify for engaging the various stakeholders in learning processes and knowledge management activities, including experts (Coffey et al. 2002). The ease of use while ensuring a high degree of expressiveness due to their diagrammatic nature lays ground for user-/usage-centered design. The various stakeholders, in particular curriculum designers, educational content providers, authors, tutors, facilitators, and learners, need to interact within and across their peer group when aiming to put to practice the interactionist and connectionist stance addressed earlier. A coherent use of concept maps should bring digital learning support developments closer to achieve Dewey’s objective that, finally, there can be no difference between an educator and a learner’s understanding, in particular, in democratic educational institutions (Dewey 2013).

In the course of learning and interaction, the complex cognitive and social fabric develops dynamically, requiring stakeholders, on the one hand, to stay tuned to their role and its adjunct perspective(s)—for example, educators being domain expert and knowledge transfer designers—while, on the other hand, meeting contextual objectives at the same time—for example, formal (institutional) qualification requirements and sense-making skill development for individual learners. To that respect, concept maps allow not only encoding different types of relevant information but also elaborating different perspectives on information elements (Kinchin and Alias 2005). By exchanging perspectives (Boland and Tenkasi 1995), they allow stakeholders’reflection (McAleese 1998), concerning the meaning of conveyed content and features for interaction in the case of digital learning support developments (Hughes and Hay 2001).

The successful use of concept maps as tools for orientation, such as in navigation in digital learning support systems (Hwang et al. 2011), in addition to content organization, recommends their use when increasingly focusing on learner-centered designs besides presenting information (in the sense of Siemens 2005). Since concept maps allow for both, non-intrusive and non-disruptive user- and usage-centered design of learning environments should become possible.

Finally, the more self-organized the process of (re-)constructing knowledge can be organized, the better problem-solving capabilities can be developed by learners (Hwang et al. 2014). Although from these empirical findings it can be concluded that integrating concept mapping into digital learning support environments helps learners acquire knowledge in a more effective way, a recent study reveals “it remains an open issue to find a suitable way of integrating concept maps into the learning process without introducing too much extra cognitive load” (Hwang et al. 2014, p. 77). The connectionist view on learning (Siemens 2005) together with intertwining roles according to the interactionist approach as proposed by Garrison (2011) could help to minimize cognitive load along learning processes.

Consequently, we have tested concept maps for eliciting mental models of educators (instructors, content providers, etc.), including their domain and didactic understanding for a certain education task (Kinchin et al. 2008), for example, in terms of subject-specific learning paths. Subsequently, we offer learners to use representations of such kind as a means of orientation for navigation and individual learning path development (as part of content individualization). Implementing this concept should increase problem-solving capacity without burdening learning with existing domain and educational structures.

We introduce informed learning design along the following structure:

  1. (i)

    Articulation support for intentional education

  2. (ii)

    Semantic navigation

  3. (iii)

    User-/usage-centered design spaces

Articulating educational design and using it for navigation lay ground for structuring design spaces (iii), as they link features of learning environments to domain structures and didactic models. They contain all required information for contextual design due to their systemic representation, enabled by concept maps. All conceptual findings have been tested in the field, allowing to present concrete data and to instantiate methodological or technological concepts in each section. All sample cases refer to learner-centered didactics and/or the same application domain, namely, Business Process Management (BPM). BPM is applied in practice across disciplines, in particular economics, organization, and information and communication technology (Weske 2010). Moreover, coherent design in higher education, as proposed by Kinchin (2014), requires rethinking learning in terms of processes—Business Process Management captures these essentials from an organizational and technology perspective.

8.3.1 Articulation Support of Intentional Education

In this section, concept mapping for eliciting educator knowledge is discussed. Being part of various acquisition approaches when designing learning environments, concept mapping allows identifying several categories of relevant knowledge (Novak 1995; Trochim 1989):

  • Domain structures

  • Didactic patterns, including envisioned learning paths

  • Context of learning processes, such as situations of use

Knowledge articulation is primarily a (meta-)cognitive effort to reflect on inputs to actions, such as educational resources and causal links between actions and outcomes, triggering learning activities through engaging resources (cf. Strauss (1988) referring to explicit Articulation Work). Concept maps, in particular when scaffolding (meta-)cognitive processes as hierarchy, cluster, or chain (O’donnell et al. 2002), codify knowledge—a necessary precondition to enable others accessing and using externalized or generated knowledge (Swan et al. 2010). Such documentations serve well as focal point for further processing, for example, curriculum design (Toral et al. 2007); however, they require to justify elicited knowledge (cf. Sandberg 2005).

In the following, we apply concept mapping for educational knowledge generation, i.e. for identifying and documenting concepts or nodes in their mutual context. Once a topic or question is provided (Novak 1995; Novak and Canas 2006), the setting can be designed differently for effective utilization. We start with the open format by giving a certain topic, such as the design of a course. Such a scenario fits well for educators starting to reflect on their experiences and skills from a perspective of their choice, such as domain, institutional, or didactic perspective (Kinchin et al. 2008). It also meets the objective when ‘an empty sheet’ approach is required to open up for novel ideas. As Lee and Nelson (2005) revealed, generative concept maps could outperform pre-fabricated ones.

We proceed with elicitation procedures via structured interviews that turned out to set the stage for designing digital learning support application in a comprehensive but focused way. It fits well to concept mapping, as concept maps facilitate analyzing existing learning resources, such as textbooks, in a structured way. Explicit content structures, finally, allow designing learning support systems including the didactic arrangement of content and its context, such as social interaction features.

8.3.1.1 ‘Open’ or Non-directed Elicitation and Reflection

This type of concept mapping starts with an objective, which the participants need to agree upon. It may concern either an individual topic or a group task. Typically, the trigger to elicit and document educational knowledge and resources for educational design is the (re-)development of a course, or the occurrence of an educational challenge. The involved stakeholders start constructing a concept map by identifying nodes (concepts, meaningful items) and relationships on a virtual or paper surface, articulating their experiential knowledge. A variety of media for interaction can be provided, in particular paper, GUI-based applications, such as the Cmap tools (Novak and Canas 2006; Canas et al. 2004), and tabletop approaches, such as Comprehand (Oppl and Stary 2014, 2011)—see Fig. 8.16 and the introduction of the system in Chap. 7.

Fig. 8.16
A photograph of the angebot tabletop concept mapping.

Tabletop concept mapping

Interactive tabletop mapping in that context targets at tangible information spaces. Correspondingly, concepts/nodes as physical representations can be put on a tabletop surface and linked by pushing two nodes against each other. Nodes and links may be provided with text that is then displayed on the tabletop. The 3D-elements also allow 3D-nodes to be opened, in order to put in other artifacts.

The example given in Fig. 8.17 stems from the preparation phase of the International Summer School on Subject-Driven Role-Guided Externalization of Organizational Models (Erasmus Intensive Programme sponsored by the Lifelong Learning Programme of the European Commission). The figure shows some educational design principles for an introductory lecture on Business Process Management (BPM). Since the summer school is intended for students from different European countries and curricula (economics, organizational studies, computer science, business computing, information systems), the crucial task is to align their understanding with respect to major concepts of the field and their nature.

Fig. 8.17
An illustration displays the sample patterns of tabletop concept mapping that include learner groups 1 and 2 and B M P modeling foundation along with the type of blocks.

Tabletop concept mapping for articulating educational design—sample patterns

The tabletop map reveals on the left side a chain (sequence) of two learning steps involving different learner groups. In a first step, Learner Group 1 (upper-left part of the figure) receives a bundle of information on BPM, composed of modeling foundations and the language standard on the Business Process Modeling Notation (BPMN) 2.0 (upper-right part). Learner Group 1 is asked to annotate the BPM lifecycle that can be found in ‘Modeling foundations’ with examples according to their own experiences and background (Haslhofer et al. 2014). These annotations, together with the other resources, are passed on to Learner Group 2 to accomplish a practical BPM modeling task, namely, Process Analysis for a service industry. The container function of the tabletop system (Map artifact in Fig. 8.17) has been used to put the map denoted by the rectangle into the red tabletop element (by using the artifact marker for a Snapshot) shown at the lower part (Input to Group 2—Practical Assignment).

In contrast to paper-based concept mapping, the process of mapping may be recorded according to the needs of the users. Hence, the process of elaborating a structure may be traced and variants may be developed starting from any recorded state. In the presented system, due to the import into a GUI-based editor, each map/snapshot may be processed further and be manipulated. For the tabletop system, an export to the Cmap tool format (Canas et al. 2004, cmap.ihmc.us) has been implemented, in order to allow processing the maps with a widely used GUI tool set. For procedural chains, such as shown on the left side in Fig. 8.17, an export has been developed to a business process suite.

8.3.1.2 Setting Up Didactic Requirements

Benefits for education design can be created from reflecting and exploring didactic approaches, again using concept mapping. In this section, we exemplify such an endeavor for progressive education, a learner-centered approach oriented towards self-organization and constructivism (cf. Eichelberger et al. 2008; Weichhart 2012, 2014a; Weichhart and Stary 2014). Such comparative analyses for educational design follow a four-step procedure:

  1. 1.

    Specifying the universe of discourse, such as identifying didactic approaches relevant for progressive education.

  2. 2.

    Detailing each constituent, collecting and structuring according to the information available, for example, procedures, assumptions, empirical findings.

  3. 3.

    Cross-checking according to capabilities, for example, degree of self-organization, effort of preparation.

  4. 4.

    Consolidating for further action, in particular requirements for digital learning support.

Figure 8.18 exemplifies step 1 for progressive education, naming all analyzed educationists, and thus scoping the universe of analysis. Color codes are introduced, facilitating traceability when cross-checking findings.

Fig. 8.18
An illustration depicts the words, is, and a, branching out into 8 components related to educationists.

Approaches to progressive education, according to Weichhart and Stary (2014)

In step 2, each approach is detailed according to the source of information in the sample case documented findings. Dewey (1928) (Fig. 8.19) puts emphasis on educating children using democratic principles, and educating them to acquire experimental, self-organized learning capabilities, thus allowing them to contribute actively to societal developments. Parkhurst (1922) (Fig. 8.20) appreciated Montessori and Dewey. She developed the role of the teacher further, namely, towards guiding learners rather than controlling them. The developed pedagogy is centered on two instruments, which allow the provision of guidance and progress monitoring. Assignments provide scaffolds instead of details of how to solve a task. The progress of the students along these scaffolds is monitored, using process graphs. Learning incorporates group work and cooperation.

Fig. 8.19
A framework depicts the network of John Dewey's approach according to Weichhart and Stary.

John Dewey’s approach, according to Weichhart and Stary (2014)

Fig. 8.20
A framework depicts the network of Helen Parkhurst's approach according to Weichhart and Stary.

Helen Parkhurst’s approach, according to Weichhart and Stary (2014)

In step 3, cross-check according to educational tasks is performed. Hereby, parts of the aforementioned concept maps on the individual pedagogical approaches are put into a single map, thus providing an aggregated view on progressive education. In order to be able to identify the source of information of each concept and link, they are colored differently, as indicated in Fig. 8.21. Concepts that are represented by a rectangular shape represent the core concept of the particular map.

Fig. 8.21
An illustration of multiple interconnected blocks displays the network of various words used in the learning principles according to Weichhart and Stary.

Learning principles, according to Weichhart and Stary (2014)

The following map shows learning principles facilitating learner-centered capacity building. The analyzed approaches require learners to take care about the freedom to select or develop their individual problem-solving capability in a self-responsible manner. The requested active exploring of problems promotes analytical thinking, creativity, practical abilities, and social capabilities for problem solving, since learning should also occur in groups.

Finally, in step 5, requirements for educational design in digital learning support environments may be derived from the map in Fig. 8.21. The concept map in Fig. 8.22 conceptualizes a learning environment providing learning facilities according to the aforementioned principles, by showing enablers to achieve major objectives of progressive education.

Fig. 8.22
An illustration of multiple blocks displays the network of various requirements for the progressive learning environment, according to Weichhart and Stary.

Progressive learning environment requirements, according to Weichhart and Stary (2014)

8.3.2 Developing Digital Learning Support Baselines (Course and Content Models)

Although Rye and Rubba (1998) could not demonstrate essential benefits for generating knowledge, incorporating concept maps into interviewing, their work laid ground to structure narratives according to concepts, and thus apply concept mapping in the context of collecting educators’ experiences for further engineering (Middleton et al. 2008). The presented content engineering process has been developed and evaluated in the projects ELIE (E-Learning in Engineering) (Auinger et al. 2007) and mobiLearn (Zaharieva and Klas 2004; Ferscha et al. 2004). It has been enriched with concept mapping, not only facilitating note taking through providing a structure according to the interview, but also encoding domain structures that can be annotated with additional information. Of particular interest are domain-specific refinements and educational metadata.

The approach comprises five main steps: preparation, preliminary document analysis, structured interview, extended document analysis and mapping of didactics, and the actual content authoring and delivery to a digital learning support system (Fig. 8.23). The core process steps aim to identify domain-didactic items based on relevant learning items and interview findings from domain experts, and to specify didactically enriched learning content.

Fig. 8.23
A process map of digital learning support includes the preparation phase, preliminary document analysis, structured interview, content authoring, and L C M S delivery.

Process map for digital learning support content engineering according to Auinger et al. (2007)

In the course of the preparation phase, resources for content development have to be identified, mainly by educators who are also domain experts. A content outline map, including building blocks of a course, such as learning goals, target learner group, basic structure, depth, and granularity of content, is specified. According to that structure, resources can be structured and analyzed. A set of resources forming an educational baseline serves as input for the didactic enrichment (tagging) process. Figure 8.24 shows an outline map (step 1).

Fig. 8.24
A content outline map for business process management depicts the relationships among the components of model building, business process organization, organization work, business process modeling and business process processing.

Content outline map for business process management

It contains relevant topics for Business Process Management for beginners in Business Information Systems at the university level. As such, it reveals a stepwise theory-to-practice introduction. A possible starting point is fundamentals in modeling and models (upper-left corner) before either introducing theoretical models of organizations (upper-right) or business process modeling (center). Business process execution is grounded on understanding modeling organizations in terms of processes.

Figure 8.25 shows the annotated map (step 2). The elementary structure displayed in Fig. 8.24 allows annotating:

  • Refinements of the fundamental structure, such as detailing business process execution in terms of performance engineering and workflow management (lower-left part of Fig. 8.25)

  • Essential aspects, such as ‘structure’ and ‘behavior’ for understanding ‘business process organization’

  • The assignment of elementary didactic tags along refinements, such as ‘case study’, ‘definition’, ‘explanation’

  • Information on didactic orientation according to objectives of a course, such as assigning theory- or practice-laden didactic terms to topics, for example, ‘tool’ to ‘business process processing’

Fig. 8.25
A content outline map for business process management has several annotations placed against the blocks.

Annotated structure map

In the course of the preliminary document analysis, source content chunks and documents are scanned to identify the level of granularity, content for orientation and navigation, and elementary didactic elements. The level of granularity of resources can be quite different: presentation slides, textbook elements, animations, and apps. In the concept map, annotations are used to identify relevant content items. Depending on the intended use of the content, different levels of detail may be useful. Finally, elementary didactic elements, such as definition (e.g., case study), can already be identified. A concept map structuring all sources of relevant input also contains the rationale why this element should be included, relationships between the documents, and metadata, such as modality of information (video, text, etc.). Hence, the final map contains all relevant associations (links) including navigation and navigational guidance. It forms the guide for the structured interview to validate the findings so far.

The structured interview with the educators concerns the following issues (Auinger et al. 2007), supported by a structured mind map (see Fig. 8.26) to condense all provided inputs:

  1. 1.

    Organizational context. Organizational issues include content profiles, learner profiles, and the organizational learning environment:

    • Number of educators and learners

    • Current didactic quality of resources, including metadata of different kinds

    • Structure and procedure of educating and facilitating learning

    • Criteria most important for facilitating learning processes, ranging from quality and adaptability of content to learner satisfaction and innovation

    • Target group(s) in terms of background, motivation, literacy, learning style, professional orientation (technical, business, and the like)

    • Guiding principles of learning processes: (i) to make new knowledge accessible, (ii) to practice and deepen linking knowledge, (iii) to link existing knowledge, and (iv) to embed knowledge in a global context

    • Type of education in terms of learning (self-directed/instructor-driven, project/assignment-driven, etc.) processes

  2. 2.

    Individual positioning. This section should clarify the individual approach of educators with respect to supporting learning processes:

    • Time spent with learners (either face-to-face or in virtual settings)

    • Fundamental individual didactic principles and preferences, for example, less is more

    • Potential of (re-)designing learning resources

  3. 3.

    Learner/learning support. It comprises

    • activities of educator along

      • preparation phase, for example, selection of content elements, establishment of specialized didactics, learner consultancy

      • implementation of the course, for example, classroom teaching, feedback sessions, quality checks

      • assessment

      • evaluation

    • improvement of learning resources, didactic approach, and tools (based on evaluation results)

    • didactically motivated content elements utilized for learning (codification such as text, pictures, multimedia, drawings; content types such as examples, cases, definitions, directions; interactive elements)

    • structure of learning resources: linear/sequencing, linked/hyper medial, hierarchical, hybrid;

    • completeness of learning resources with respect to didactic design

    • organization of learning support, including feedback to learners

    • grading and examination

  4. 4.

    Communication. Social interaction and skills of the interviewed educator refer to

    • frequency of contact with other stakeholders (educators, learners, etc.)

    • particularities of interaction, such as Hot Potatoes, organizational issues, tools, taking lead

  5. 5.

    Technical support. It addresses

    • categories of ICT-tools, such as content management, social media

    • technical interface issues when linking of two or more tools is required for learning support

    • meta-cognitive (learning-to-learn) support tools

    • learner profiling, identity management, and integrity/security issues

Fig. 8.26
A structure map for interviewing and result presentation has the component Interview branching out into organizational context, individual positioning, knowledge transfer, communication, and technical support.

Structure map for interviewing and result presentation

The structured interview should clarify individual, organizational, and technical aspects of the learning support process. In the core part of the interview, didactically motivated elements such as didactic content types, and interactive elements are identified by the interview partner.

In the next phase, the didactic elements and structures are mapped to the (XML-)content structure. In case content has been already tagged, as some text books are generated according to metadata or didacticontologies (Meder 2006; Schluep et al. 2006; C.-M. Chen 2009), these data can also be generated automatically (Tseng et al. 2007) or semi-automatically (Leake 2006; Larrañaga et al. 2008).

Since the early days of digital learning support, the need for encoding didactic quality into content has been demanded (Schulmeister 2017). Content elements should not only contain but also visualize metadata, such as definition, for orientation and selection. Figure 8.28 shows such an approach (Auinger et al. 2007). Learning units are part of modules courses are composed of. They contain content blocks with various domain- and education-relevant tags assigned to content elements. These elements can be text, graphics, video, or audio information.

Table 8.1 shows part of a typical didactically enriched structure developed for a course on Business Process and Communication Modeling at the University of Linz, Department of Business Information Systems. The course is given as an introduction to BPM to students in the Business Information Systems curriculum in the first year of the corresponding bachelor degree program. Modules and Learning Units can also be shared with other courses (Initiative 2004), either in Computer Science or Business Information Systems, such as Communications Engineering. In those cases, the assignment of metadata (block types in Fig. 8.27) needs to be reconsidered (Leidig 2001), as, for example, some definition in computer science may need to be re-categorized as explanation in Business Information Systems due to its explanatory character when focusing on application of computer science theories and concepts.

Table 8.1 Example of tagging a BPM content structure
Fig. 8.27
A framework depicts the structure of educational metadata and includes the components of implicit learning paths and hierarchies, content-equivalent blocks in different levels of detail, and block hierarchy.

Educational metadata structure

Tagging follows the structure of the content outline map shown Fig. 8.25, leading to the following modules (see also Fig. 8.28—navigation area on the left side of the screenshot):

  • Introduction, providing the relevance of the field

  • Models and modeling, giving some background on abstraction and representation

  • Organizations and processes, introducing the nature of business processes and their history in organization science

  • Process modeling, detailing functional, object-, und subject-oriented approaches to business process modeling, with practical guidelines on how to construct models in the respective paradigm

  • Process engineering, providing fundamentals of performance engineering, architecture designs, and workflow management, in order to implement business process models by ICT systems

Fig. 8.28
A screenshot of a web page in a foreign language.

Tagged BPM content—‘background information’ and ‘practical guideline’ on the development of process-based organizations (released under a Creative Commons Attribution 4.0 International License (CC BY 4.0))

In Table 8.1, one of the modules, ‘Process Engineering’, is detailed with respect to some of its learning units (Development of Business Organizations, Workflow Management, Process Simulation), and its content elements (blocks), and their tags for the first learning unit.

In addition to tags, distinguishing various levels of detail has turned out to be useful for targeted content delivery. Using several LODs (levels of detail), content developers can structure learning resources on three different levels of granularity. A common instantiation of that concept is to provide slides for classroom presentation on LOD1, text book elements for reading and self-studies on LOD2, and additional information or further resources (links, files, videos, and the like) for exam preparation and in-depth studies on LOD3.

For learners, tags are visualized when content elements are displayed. The content area in the center of the screen (see Fig. 8.30) corresponds to the work space of stakeholders. Navigation is provided initially as tree view on the left side of the screen. It supports nesting of content elements, in order to facilitate structured access to content elements, such as displayed for Process Engineering on the bottom-left of the screen in Fig. 8.28.

Explicit tags also allow filtering according to learning styles, for example, selection of all examples of a learning unit, in case a learner is more practically oriented when acquiring knowledge. Given the proper functionality (see third entry from left ‘Filter’ in the toolbar beyond the navigation space), the LSS (Learning Support System) displays only those parts in the navigation and content area that contain the selected tags. Hence, both domain structures and didactic expertise contribute to semantic richness of the provided BPM content.

In Fig. 8.28, on the left side of the screen, a tree view for navigating the nested content is shown, whereas in the center, the selected content is displayed, in this case ‘Development of process organizations’ being part of the module ‘Process Engineering’. The tags are ‘background information’ (Hintergrundinformation) and ‘practical guideline’ (see marked areas on the right side of the screen) concerning some text to motivate developing process-based organizations, and a practical guideline on the development of process organizations revealing BPM phases that should be followed in the course of development.

The latter case reveals the intention of tagging, expressing the context of how the content is addressed and could be used. For learners who should find orientation of how to set up BPM projects and participate in BPM lifecycle activities, the tag ‘practical guideline’ indicates this educational intention. In case learners are focusing more on becoming acquainted with frameworks, such as when comparing lifecycles from various BPM approaches, they could be supported effectively using a tag like ‘operational frame of reference’ or ‘value chain’.

8.3.3 Semantic Navigation

Navigation makes up most of the user’s experience (Smolnik and Erdmann 2003). Consequently, navigation features should facilitate the access to domain- or user-relevant information including content and its manipulation features. When using those features, users should build up and maintain a coherent mental representation of the traversed environment, the so-called cognitive map. Such a representation serves as a baseline for learners and facilitators when interacting with a learning support system (Rovine and Weisman 1989). However, for content-rich applications, there is no consensus on (re)presenting content and manipulation features in a user-centered way (Godwin et al. 2008).

The learner support presented so far (see previous section) featured the dynamic selection of metadata, such as ‘explanation’, which allows learners navigate through content and experience it individually. Its design is led by domain concepts which can be created by mining techniques from documents (N.-S. Chen et al. 2008) and could be utilized for adapting to learner needs, such as planning individual learning paths (C.-M. Chen 2009). Tseng et al. (2007) constructed concept maps for achieving adaptive learning. Hereby, they automatically created predefined concept map of course descriptions (ibid.) that could be adapted to individualize learning paths. They can help educators and learners to locate and assign learning resources according to recognized learning goals. However, intentional elements need to be visualized and accessible interactively (Sumner et al. 2005).

In the following, we report on the concept map-based tool developed by Neubauer et al. (2011) that allows encoding of intentional information dynamically, such as learning objectives, domain, and didactic metadata. Using the learning support system shown in Fig. 8.30, they had found that the deep hierarchy levels had been time-consuming for learners with respect to navigation, and thus were hindering learning processes. They developed an associative navigation design, enriched with educational and domain-specific metadata. It allows individual exploration of content and is displayed as concept map. Learners select learning their paths according to the prepared links and may navigate beyond hierarchies (as encoded in the tree view), and across domains or courses.

Figure 8.29 depicts a concept map for the learning unit on ‘Enterprise Architecting’ being part of ‘Process Engineering’. Educational metadata (motivation, definition, etc.—see also Fig. 8.29) semantically describe links to information resources. Hence, the associative navigation provides learners additional structural navigation information that shapes their learning paths.

Fig. 8.29
A flow chart displays the navigation of enterprises architecting didactically enriched concept maps.

Didactically enriched concept map navigation

Individualization support considering the associative navigation is similar to the navigation concept introduced in Chap. 5. It is enabled through features like annotating a concept map and its elements, editing such as adding individual concepts, and filtering links to information resources according to didactic content types, content modality, or user profiles and preferences. Compared to the hierarchic approach, the concept map approach also enables annotation referring to concepts, relations, and links to resources.

In order to support both approaches, a polymorph representation scheme has been developed based on the ISO standard of Topic Maps (Neubauer et al. 2011). For the implementation of the dual navigation approach, the differently organized information structures have been recognized applying an intertwined view concept. The following view types match the different approaches: learning content (structure) view, linking and individualizing view, domain context, and access context (cf. Fig. 8.30):

  • Learning content (structure)view. This view contains didactically enriched learning content typically authored by educators. It serves to present the basic structure of learning resources and communication features. Regarding the given navigation designs, this view includes parts of the hierarchic navigation design. To support authoring of learning resources in this view, didactic topic map templates are useful (Schmiech 2006). Such templates aim to ensure consistent authoring, and finally consistent navigation. Furthermore, didactic topic map templates take into consideration various didactic attempts and singularities of knowledge.

  • Linking and individualizingview. The aim of this view is to allow users embed arbitrary content in their individual learning process or in collaborative learning processes, and thus supporting knowledge transfer. Within this view (individual), semantic relationships between arbitrary content elements are represented, such as relationships between learning content and communication items, learning content and domain concepts, learning content/domain concepts and additional information in the web. Nevertheless, content elements (such as block, communication item, domain concept) provide the focus and serve as anchor to represent associated information. Further aspects of individualization such as annotations, metadata, or comments are also represented within this view. Thus, linking and individualizing views allow recording the knowledge construction process of learners (Fürlinger et al. 2004). Moreover, through allowing relationships between arbitrary content elements, new navigation paths can be offered in contrast to hierarchy-driven navigation paths. Since linking and individualizing views record the knowledge construction process of learners, for learning in teams, sharing and merging facilities for views are necessary to support collaboration among learners. Topic Maps provide an integrative concept to that respect. For efficient migration, Published Subject Identifiers (PSI) are recommended (Sasha Rudan and Rudan 2008).

  • Domain contextview. Within this view, concept of a given knowledge domain and respective associations are represented. Additionally, this view includes domain-overlapping relationships. Besides concepts and associations, relationships between concepts and information resources are depicted within the domain context. Information resources can either be arbitrary content elements of the learning resources or other information resources, such as external web pages. In order to allow individualizing the description of a given domain, individual views can also be represented upon domain contexts.

  • The access contextview. This supports adapting navigation and presentation of content according to different user preferences, devices, or learning situations. It allows adaptive navigation experience for learners, for example, by retrieving content in different levels of detail (e.g., bullet points—LoD1, text—LoD2, additional information—LoD3) and different modalities (e.g., text, audio, video).

Fig. 8.30
A process flow diagram depicts the relationships between the learning material and content structure view, and the linking and individualizing view. The other labels include domain context, resources, and a few websites.

Relationships between main views according to Neubauer et al. (2011)

The integration of the aforementioned views provides a holistic perspective on learning content embedded in individual, didactic, communication, and domain context. Considering navigation in such a multifaceted environment, content elements provide a focal point of learning processes. Content elements represent anchors for switching between different views (e.g., domain context, learning resources, and content structure view) or for combining different views.

Finally, reconsidering Topic Maps for the representation of the given views, it is necessary to distinguish the representation of structure (topics+associations) and the representation of content (occurrences). Structure focuses on navigation and supports retrieval of content, while occurrences represent the link to information resources (content). Different statement types support filtering of navigation paths (cf. association types) as well as content types (cf. occurrence types). For instance, occurrence types allow representing various modalities (e.g., audio, video) for a topic, and hereby selecting content according to the desired modality.

Annotating learning content (using hierarchic navigation) with a concrete domain concept allows switching between hierarchic navigation and concept map-based navigation. Besides switching between different navigation designs, the topic map representation approach allows (cf. Fig. 8.31):

  • Flexible embodiment of didactic information into the navigation design

  • Domain-specific adaptation and navigation

  • Reusing of content elements in different contexts (e.g., traditional tree view, concept map)

  • Filtering content according to didactic type, modality, and granularity

  • Filtering navigation paths (associations) within the concept map navigation

  • Individualizing of learning resources, for example, linking blocks or concepts with communication items in order to represent context-sensitive discussions

Fig. 8.31
A flow chart displays the linking hierarchical and associative navigation design for enterprise architecting

Linking hierarchical and associative navigation design

Such an implementation enables a highly flexible learning support system, as it can be adapted to user preferences and navigation styles promoting individual learning experiences. Learners who have been using the associative navigation design mentioned that it helped them to get an overview regarding the content of the lecture and to identify relationships between content elements. However, they indicated to have used the concept map in addition to the provided text book for the lecture, and not as primary source when learning. The content types displayed in the associative navigation have been experienced to support learner navigation. The depicted relationships between concepts as part of associative navigation have been intelligible to most of the learners.

In this way, the empirical findings confirmed some expected benefits, and affirmed that both navigation designs used by learners complement each other (Neubauer et al. 2011). While associative navigation design seems to be used by learners primarily to get an overview of a domain and to recapture associations between the domain-specific concepts and content, hierarchic (tree) navigation seems to be preferred by “top-down learners,” working with content primarily in a linear way.

8.3.4 Alignment in User-/Usage-Oriented Design Spaces

From the findings elaborated earlier, in particular for semantically enriched navigation design, various design dimensions to provide meaning of learning content have become evident—see also Fig. 8.32:

  • Subject-inherent and domain-independent elements: They can be found in most of the educational subjects, as they constitute disciplines. Among these elements are origin, concept, and paradigm. In BPM, typical origins are organizational development or software engineering, concepts are modeling elements to represent business processes, and paradigms are communication-orientation and functional specification.

  • Subject-inherent and domain-dependent elements: These elements are typical for certain domains, and allow differentiating domains, such as software project management and BPM. In BPM, typical instances for domain-dependent elements are business process models, analysis methods, and lifecycle. They concern fundamental elements to understand the field.

  • Learning-inherent elements that are domain- and situation-dependent: This category refers to elements directly influencing the style of presentation, location, and reception of resources as well as learner behavior (Farmer and Hughes 2005). For instance, in progressive education, self-regulated learning, exploration, and informed problem solving are of eminent importance. The domain-dependence is given by looking whether the technical domain, such as BPM, allows such an approach. The same holds for the situation, as the format of lectures influences learner behavior. A course providing project assignments is likely to allow self-organized problem solving in contrast to focused method training.

Fig. 8.32
The design element categories are represented as three rays with a common starting point. The three rays are learning-inherent elements, subject-inherent elements 2, and subject-inherent elements 1.

Categories of design elements

When it comes to implementing didactic settings, the underlying services are of importance (Hung 2012). More particular, a variety of tools supports digital learning today and are part of respective environments. Besides traditional content management, Web 2.0 technologies, such as blogs, wikis, chat rooms, and video streaming, are widely used (ibid.). Few of them aim to create an integrated learning support system (Alario-Hoyos et al. 2013). Hence, a mapping from didactic requirements to services allows for traceability of the development process. Hereby, a middle design layer (see Fig. 8.35) as a focal point in terms of feature bundles turned out to be useful.

Once the underlying education scheme is considered to be a starting point for learning, design (Zardas 2008) features need to be derived from pedagogic elements in terms of technological functionality in the course of development. Concept maps also help to structure and guide this process. In Fig. 8.33, the top layer consisting of domain and didactic structures is related to feature bundles located in the middle layer that allow identifying classes of systems for implementation and refining them in terms of their specific features or services (cf. www.archimate.org).

Fig. 8.33
A chart displays the three layers in the design space of the approach to the user or usage-centered learning, preparation, design specification, and implementation specification.

A layered approach to a user-/usage-centered learning design space

Figure 8.34 exemplifies the principle of this design mechanism based on input presented in the previous sections. For the sake of intelligibility, the link structure of the map is only sketched between the top and the middle layer. The middle layer exemplifies typical ‘design cornerstones’, such as a feature bundle for content management, integration social media into content management, and supportive transfer structures. Each set of features is detailed in terms of tools or tool sets on the bottom layer.

Fig. 8.34
A schematic instance of a design map displays the prepared learning environment including content, content and management, Dalton plan editor, and discussion forum.

Schematic instance of design map according to Weichhart and Stary (2014)

For instance, following the progressive education approach, the Dalton Plan, as introduced by Parkhurst (1922), has been implemented (Weichhart 2012). The Dalton Plan primarily uses assignments and feedback graphs in conjunction with bulletin boards and conferences. An implementation in a learning support system requires a prepared environment, as shown in the top-right of the figure. From the middle design space layer, Content & Communication and Transfer Structures are addressed in line with recent findings with respect to effective digital learning support processes (Dabbagh and Kitsantas 2012).

According to the concept mapping guidelines, each element of the upper layer (encoding the didactic and domain concepts) can be related to one or more elements of the upper and middle layer. For the Dalton Plan implementation, a link needs to be set between ‘teachers plan with students’ (upper layer) and ‘transfer structures’, as the Dalton plan is based on a work plan structuring learning steps.

Using the Dalton Plan editor (systems and specific feature layer in the design map of Fig. 8.34), the different parts of Dalton Plan assignments and their relationships can be specified. Assignments organize learning processes by detailing problems and providing descriptions, namely, in terms of documentation (Written Work) and cognitive activities (Memory Work) involving individual and group tasks.

The Dalton Plan facility enables deadlines and provides feedback to learner achievements (see Figs. 8.35 and 8.36). Feedback graphs allow transparent progress reports. Meetings and the so-called conferences are also part of the Dalton Plan. They can be scheduled on a regular basis or announced on the bulletin board. Figure 8.35 shows the assignment editor for specifying work plans, and feedback graphs (Fig. 8.36) implemented using a web 2.0 technology stack (Tiropanis et al. 2012) in the Learning Support System presented earlier. Each learner can be (re)presented by a feedback graph once working on a specific assignment. For each assignment, all currently involved learners can be displayed according to their state of affairs, both in terms of self- and educator assessment.

  • In general, the introduced design space approach for user-/usage-centered learning designs bridges the gap between educational requirements and technical system features by a middle layer that serves top-down and bottom-up specifications.

  • Educational inputs can be refined to requirements, in terms of domain, didactic, or situational structures (top layer).

  • For each of these maps from the top layer, one or more points of reference in terms of bundles (of features) in the middle layer can be defined, for example, content management for didactic elements being part of learning units.

  • Systems utilized for implementation can be refined in terms of their features (bottom layer).

  • Each feature can be assigned to a system which can be assigned to a class of systems (bottom layer).

  • Each set of features (middle layer) is implemented through (a set of) systems (bottom layer), and vice versa, and each class of systems, system, or feature can be assigned to a bundle of features on the middle layer.

Fig. 8.35
A screenshot of the Dalton plan editor according to Weichhart and Stary.

Dalton Plan editor according to Weichhart and Stary (2014) (released under a Creative Commons Attribution 4.0 International License (CC BY 4.0))

Fig. 8.36
A screenshot of the feedback graphs, according to Weichhart and Stary.

Feedback graphs according to Weichhart and Stary (2014) (released under a Creative Commons Attribution 4.0 International License (CC BY 4.0))

Finally, all neighboring relationships for design and implementation, such as using the Dalton Plan editor together with existing Social Media, may be specified on the top and bottom layers. The middle layer elements should only be linked to upper and lower layer elements, for the sake of coherent assignments of bundles (of features) to systems or system features (bottom layer). Thus, the middle layer may not be considered a separate map.

8.3.5 Insights from the Case

The development of digital learning support systems could have been considered to be an open puzzle so far, both in terms of concepts and instruments, in particular when putting progressive didactic concepts to practice. In this case, we utilized concept maps as overarching scheme and representational glue to support articulation and alignment, once relevant items have been identified. In this way, we could capture educational intentions, meaningful content, and learning process specifications.

When intertwining emotional, social, cognitive, and technological issues, means of orientation and documentation become essential, not only for those who are carrier of these processes, but also for those who initiate and facilitate these processes, namely, educators, content providers, and developers. A living design memory has to keep information in a topic-specific and context-sensitive way, in order to organize knowledge for sharing digital learning support expertise and for providing learning process support.

By Articulation Work on educator knowledge and education-relevant mappings for learner-centered design, we could up a work-relevant alignment and design spaces. It allowed proceeding with content production and navigation design based on intentional and meaningful design elements. Metadata are key to implementing design maps with semantic technologies which can be captured in a layered design space according to generic feature classes. Educational metadata stemming from domain didactics can be effectively used for content and navigation structuring. Concept map-based navigation design, complementary to nested tree structures, can be created using topic maps and support learners along individualized learning processes. Hence, the primacy of didactic design together with dynamic adaptation forms the base for user- and usage-centered interaction, and thus work design. The underlying technologies, such as intelligent content management and social media, need to become part of an integrated system, in order to provide effective stakeholder support.

8.4 Subject-Oriented Organizational Management

In this chapter, we exemplify how subject-orientated digitization works given the communication-oriented perspective on work (knowledge). The presented Me2Me2You technique is based on capturing business operations in terms of pragmatic qualities including role awareness, task accomplishment, and interaction with other stakeholder roles, as reported in a study by Christian Stary (2018). The starting point includes meaningful entities for the articulating stakeholder with respect to each of these aspects. Based on experiential data, a reference procedure can be proposed. It could help articulating behavior in critical situations and for regular or routine tasks.

The frame of reference enabling process participants to gradually develop a comprehensive model of their business process in a subject-oriented way can be mapped to the overall framework, as shown in Fig. 8.37. It reveals that the articulation and execution parts are affected.

Fig. 8.37
An illustration depicts the relationships between the teacher, student, and facility management. The work design framework of the front end to the back end through the repository is also depicted.

Embodying the organizational management case to the digital work design framework

Since the case explores novel ways of designing organizations, and thus digital work, we provide some relevant background information for this study.

8.4.1 Organizational Management

In organizational management, meaningful behavior has already been recognized as a highly individual construct. As Shchedrovitsky (in Khristenko et al. 2014) in his analysis on the engineering nature of organization, leadership, and management of work has pointed out, it requires understanding the semantics of a situation (Shchedrovitsky 2014, p. 42ff):

What is ‘meaning’? It is a tricky question. Really, there isn’t any meaning. Meaning is a phantom. But here’s the trick. I can say a sentence, like ‘The clock has fallen off the wall’ in two situations with two completely different meanings: ‘The clock fell’ and ‘The clock fell.’ The change of accent corresponds to two fundamentally different situations. Imagine this: when I am lecturing, I have got used to the fact that there is a clock here on the wall. At some point, I turn, I see an empty space, and someone in the audience says, ‘The clock fell off the wall.’ They might simply have said ‘it fell’ because, in this instance, the word ‘clock’ carries no new information. I look at the clock, I have got used to it and everyone in the lecture hall has got used to it. We look at that place and someone says ‘it fell off the wall’, and that phrase provides new information.

But now imagine a different situation. I am giving a lecture and all of a sudden there is a crash behind me. What has made it? I am told, ‘The clock fell off the wall.’ The situation is entirely different because what is new in this instance is the message about the clock. I heard something fall—that is a given—and I am told that it is the clock that fell. We pin this down in terms of ‘subject’ and ‘predicate’ in their functional relationships: in the first case, the clock is the subject, and in the second case the subject is the falling. We carry out syntactical analysis and highlight a difference between the two oppositions ‘noun–adjective’ and ‘subject–predicate’. The distinction between subject and predicate is this: when we have a text, the subject is what we are talking about and the predicate is the characteristic that we ascribe to it. So when I hear any text, I understand it through an analysis: I work out what is the subject. Why do I work it out? I relate it to the situation.

The subject might be an action. In an algorithm I always treat actions as items, to which characteristics are ascribed. So I am always doing a particular sort of work: I parse the text syntactically, identify its syntactical organization, its predicate structure, and map this onto the situation. This is a process of scanning, of relating the text to the situation. When you understand my text now, you carry out this complex relational work. You are constantly identifying what is being talked about and what I am saying about it. This is the standard work that goes on automatically, you understand what is being said to the extent that you can find these objects and relate the text to them.

These paragraphs reveal several insights that are not only relevant when one perceives a specific situation at hand, but also when aiming to represent or modeling it. Providing information, that is, giving meaning to perceived data, needs to be considered a context-dependent process itself. Simply by focusing on a specific part of a sentence, like shown earlier for ‘The clock has fallen off the wall’, different meanings can be conveyed, and thus different situations and adjacent work practices could be revealed. Shchedrovitsky considers ascribing meaning to a situation as relational work. It requires an active entity identifying elements of concern (perceived) information can be assigned to.

After rephrasing subject-oriented representations, a model of eliciting and structuring perceptual knowledge of stakeholders in a certain situation is proposed based on exemplifying stakeholderarticulations. In these samples, several persons were asked to describe how they make meaning when ‘The clock has fallen off the wall’ in a classroom situation. The articulation model contains several perspectives helping to structure individually perceived situational information for further operation. Each perspective can be enriched with another one, leading to a cascade of perspectives, finally allowing to create subject-oriented process models.

8.4.2 Subjects As Carrier of Work Behavior

We follow the aforementioned example. When learning facilitators in a classroom are asked to describe how they react when ‘The clock has fallen off the wall’, they could identify several carriers of behavior, that is, subjects. Figure 8.38 shows a set of possible subjects, Clock, Facility Management, and Clock Producer that could be considered of relevance for ‘The clock has fallen off the wall.’ The directed links denote the interaction pattern for message exchange.

Fig. 8.38
An illustration of 3 text boxes. The clock relates to facility management, which relates to the clock producer.

Sample universe of discourse for ‘The clock has fallen off the wall’

According to subject-oriented modeling (Fleischmann et al. 2012), any setting or situation can be structured as a set of individual actors or behavior elements. They can be humans or technological artifacts and are encoded in subject diagrams according to their communication with each other. When subject needs to communicate directly with another subject, as required in case of maintenance, a subject-behavior diagram also encodes this link. It is executed during runtime (after technical implementation).

On the modeling layer, the corresponding activity is a request sent to another subject. The sending subject waits until it receives an answer. Then, it processes the received answer—see Fig. 8.39 for that pattern. The rectangles denote the messages which the subjects exchange.

Fig. 8.39
A 3-textbox illustration. The clock relates to facility management with interruption of operation, and facility management relates to the clock producer through service request.

Sample interaction pattern for ‘The clock has fallen off the wall’

Figure 8.40 shows a Subject Interaction Diagram (SID). SIDs provide a global view of a situation, comprising the subjects involved and the messages they exchange. The SID contains a maintenance support process in Fig. 8.40. It comprises several actors (subjects) involved in communication: Facility Management coordinating all maintenance activities, a Clock Producer taking care of providing a working clock, and the Clock providing scheduling support in classroom management. They exchange messages in case of operational problems, as shown along the links between the subjects (rectangles).

Fig. 8.40
A chart of 3 columns displays the sending, processing, and receipt of the request in facility management and clock producer.

Sample Behavior Synchronization of 2 SBDs

Subject Behavior Diagrams (SBDs) provide a local view of the process from the perspective of individual actors (subjects). They include sequences of states representing local actions and communicative actions including sending messages and receiving messages. Arrows represent state transitions, with labels indicating the outcome of the preceding state (see Fig. 8.40). The part shown in the figure represents a service request to the Clock Producer subject from the Facility Management subject.

Given these capabilities, subject-oriented representations can be utilized for articulation due to their (i) a simple communication protocol (using SIDs for an overview) and thus (ii) standardized behavior structures (enabled by send-receive pairs between SBDs), which (iii) scale in terms of complexity and scope.

8.4.3 Essential Principles

In the following, we introduce relevant articulation and representation principles from organizational management according to Shchedrovitsky (2014). We start with the identification of meaningful entities, proceed with interactions of identified entities, and complete the set of basic principles with the alignment of interactions recognizing systemic operations.

8.4.3.1 Identifying Meaningful Entities

When stakeholders perceive situations, they start with spotting relevant elements according to their current perspective:

Now imagine the following device. I project a ray of light from my consciousness as I compare things—first, second, third thing—all the time extracting information and drawing it to myself. And there is a little paint brush with black paint attached to this ray and every time I send out the ray the brush leaves a mark. When I jump to something else the brush leaves a mark again; when I go back it makes another mark. In this way the brush leaves a kind of grid behind it. Then we look at the grid and we say that it is meaning. So, meaning is a particular structural representation—a sort of freezeframe—of the process of understanding. We can look at this another way, by asking a trick question: does movement have parts or not? I make a movement what parts can there be in it? And, generally, how can you stop it and capture it temporally? You cannot do any such thing because in order to obtain parts, you have to cut it up. But my movement isn’t capable of being cut up!

But see what we actually do. Here is a movement. For example, something falls. It leaves a trail. Now we begin to slice this trail into sections, we get parts of the trail and we transfer it to the movement.

So, the movement obtains parts secondarily, by transfer onto it of the parts of its trail. Otherwise, we cannot work with movements in thought. In order to cut them up, transform them, or do something else with them, we have to stop them—to represent some ‘frozen’ part of the movement structurally. This is how we work with any process—whether of understanding, work or something else. We divide it into stages and phases, but in order to do this we have to find and register the traces (the trail) of this process. (Shchedrovitsky 2014, p. 43)

The ‘trail’ may range from realizing the trigger event for the clock’s falling down to watching how the broken glass spreads over the floor in the classroom. Evaluating this trail allows to scope the entire scene in terms of all relevant elements involved, for example, the holder went off the wall, the clock fell down, and the clock fell apart when touching the floor. Hence, meaning could be action-triggered which, in turn, is relevant for the stakeholders in the room. Assuming that nobody got hurt through the event, for the students in the room it may be an event of low complexity, as they do not have to care about the time and are able to watch their steps when avoiding stepping on the clock’s broken parts. For the learning facilitator, it is a major event, as he/she needs to take care about the time and the safety of the students.

As we can see, each stakeholder constructs meaning using some role-specific view. It may require immediate action or reaction to an event. The learning facilitator may take action through interrupting the process of teaching and switching to the role of caretaker of classroom safety, warning the student to be careful when leaving the classroom. From the facilitator’s perspective, in a second step, the time problem needs to be addressed, assuming classes are structured along time slots. The facilitator needs to interact with somebody from the class or facility management to ensure correct timing, in case he/she relies on an external source of information with respect to time. Finally, the facility management needs to be addressed for taking care of all the damage. From a representational perspective, several entities are involved to make meaning out of a situation:

  • The event—being an action itself (falling off the wall ending another operation, namely, the time ticking), or ‘sliced’, a set of small actions or events

  • The role—student, learning facilitator, caretaker, facility management

  • Actions and interactions, such as teaching and warning the students

  • Concerned objects, the clock and the classroom

Each of these elements is constitutional to subject-oriented representations. Subjects denote roles and encapsulate behavior in terms of doing, sending, and receiving messages. Finally, the concerned objects are addressed in or passed through messages exchanged between subjects.

8.4.3.2 Conveying Meaning to Others

Situations trigger not only certain behavior, but also need to be documented and transferred to others, for example, to guide further behavior.

We ought to speak in such a way that those listening cannot fail to understand. How they understand is a very complex question. We all understand through the prism of our own peculiarities. And very often understanding is richer than what the speaker or writer of the text intended. The text always contains much that the speaker, the author of the text, did not personally put into it. This is due, first of all, to the fact that the author uses the tools of language. It is fair to say that language is always smarter than us, because all the experience of humankind is stored and accumulated in it. Language is the principal battery for storing experience. Second, the person who understands carries their own situation with them and always understands in the light of that situation, and often sees something more or something else in the text than its author. (Shchedrovitsky 2014, p. 44)

It could happen that communication is not documented through documentation, and very likely reduced to technical behavior. Subject orientation goes beyond that—it enforces to think in terms of communication and interaction of stakeholders or systems, as behavior specifications cannot exist without interaction. For instance, the teacher subject (i.e., a role) activates the caretaker, who, in turn, activates the facility management.

8.4.3.3 Aligning People

In order to run an organization, it may not be sufficient to develop a chain of interactions from a single perspective. For instance, administration, technically not involved into the clock falling off the wall, needs to be activated to ensure whether the classroom can be utilized by students for the next class.

Everything starts with engineers who master the principles. They do not discover what was already in nature, but create a structure, something fundamentally new something that was not there in nature. They collect the elements and create—by assembling, joining together, ‘bootstrapping’—completely new things not made by nature, and in doing this they are supported by creative—bold, ‘crazy’—thought. All this is bound together in a unity, which does not follow the laws of nature, discovered by science: there was nothing to ‘discover’ until an engineer created something.

The work of organizers, leaders and managers has the character of engineering work: it is structural and technical. Organizers, leaders or managers must always be one step ahead; they have to come up with something new.

Technical knowledge. Suppose that you have to lead or manage people. You must determine their future actions, make a decision concerning their actions. As a result, you have a goal in advance, and you consider this person as a means or tool to achieve this goal. This is how things always are if you are an organizer, leader or manager. But people might resist, ‘break loose’, or act in some unforeseen way. You say one thing to them, and they—perhaps they are creative individuals—do something else. And you do not know whether you need to regulate their manner of execution or if you only need to set the goal. In short, each time you need to have knowledge about the individuals and their actions, but this knowledge must be oriented from the very outset to your goals. You have to achieve a certain goal through these people. And so, your knowledge answers the question: how can you achieve your goal through these people, and adjust their actions and your relations with them as a function of your goals? Such knowledge is what we call technical knowledge. (Shchedrovitsky 2014, p. 7f)

Shchedrovitsky, in the aforementioned statement, indicates that the matter of including or recognizing perspective can be a matter of goal setting, and in this way, scoping responsibilities.

Technical knowledge gives us the answer to a question about an object, its mechanism and its action. However, this knowledge does not have a general nature: it is specifically geared to the achievement by us of our goals. It shows how adequate the object is for achieving these goals, and what we must do with it, how we must act on it in order to achieve our goals.

Technical knowledge is very complex. It is actually much harder than scientific knowledge. And the work of an engineer is actually much more difficult than the work of a scientist. The work of a practical worker is even more complex. … Technical knowledge is not just a matter of goals, it is also about your means of influence. You are not interested in the object in itself, but in the achievement of the goal using your existing tools and methods of action. And you see this object in this context. … Necessary and sufficient information is needed. You need to have adequate knowledge. (Shchedrovitsky 2014, p. 8ff)

According to Shchedrovitsky (2014, p. 11), a stakeholder needs to pursue a specific goal and to know whom to involve in which way for further operation. As we will see in the following, the goal can help identifying intentional actor performing self-contained tasks according to the perception of a situation. In addition, the means of organizing work could be subject-oriented business process which needs to be probed by applying the model.

8.4.4 Structuring Articulation

In this section, the insights of Shchedrovitsky presented earlier are used for developing a cascaded model of perspectives. It is introduced in Subsect. 8.4.4.1 before a report on a field test is detailed. In this test, interviews were conducted with five stakeholders. Their perception of a situation when a clock has fallen off the wall in a classroom has been captured and structured. The interviews reveal some empirical evidence on its plausibility, also in terms of utilizing subject-oriented modes for representing operational work activities for goal-oriented actors (represented by subjects).

8.4.4.1 Cascading Perspectives

The model takes into account the structured findings revealing that perspectives on the situation trigger

  • technical entities encapsulating behavior by focusing on activities needed to be performed to achieve an objective or implement an intention (usually referring to some task), and thereby establishing some functional role

  • communication acts identifying which entity needs to be interacted with

  • the mutually adjustment of encapsulated behavior specifications, as it plays a crucial role not only in acting as a collective in a specific situation but also in completing work processes or reaching intended goals

Accordingly, the model contains several perspectives helping to structure individually perceived situational information for further operation. Once started with an individual perspective, stakeholders can enrich its result with another one, and so on, thus leading to a cascade of perspectives. Since this cascade contains behavior encapsulations and interactions, it finally allows developers to create subject-oriented process models.

Figure 8.41 shows the model serving as frame of reference of building organizational capacity based on individually perceived situations. It instantiates Shchedrovitsky’s approach in terms of structuring behavior in a goal-oriented way. The left part shows the cascade of perspectives that finally captures the evidence of a specific stakeholder when perceiving and reflecting on a situation:

  • Perspective 1—IndividualActorView: This perspective captures a set of individual roles in which this stakeholder can act and think about in a specific situation. For instance, assuming the clock has fallen off the wall in a classroom having a teacher and students, the teaching role of the teacher addresses all duties related to classroom teaching, whereas the safety-responsibility role of the teacher concerns the physical safety of students in the classroom. Since humans are intentional beings, we can assume that each stakeholder has at least one role or objective to (inter)act that constitutes an actorview. This role or a set of roles corresponds to the individual (task) profile of a person. Each role refers to a specific behavior that has a driver, namely, an intention. For instance, the driver of the teaching role is increasing the level of competence of students, whereas the driver of the safety-responsibility role is ensuring the safety of all the students in the classroom. Since each role has an intention, each stakeholder can pursue a set of specific goals in a situation, depending on the set of roles.

  • Perspective 2—Individual InteractionView: This perspective looks on the same situation but builds upon the results from taking perspective 1 and the identified roles. It keeps the considered role/objective/intention at the center of interest, but additionally captures a set of individual interactions based on that previously defined intentional behavior set(s). Hence, the set of interactions also depends on the roles in which this stakeholder can act and think about in a specific situation. For instance, we assume the stakeholder identifies the role of the teacher (addressing all duties related to classroom teaching) and the safety-responsibility role (ensuring the physical safety of students in the classroom). Then, from this perspective, the stakeholder needs to think about interactions between these two roles. In case the teacher interrupts the class due to the clock’s falling off the wall, the safety-responsibility role takes over to ensure the safety of the students in the room. It may lead to ending the class, if the teacher cannot guarantee the safety of the students in this situation, as perceived by this stakeholder. In case the safety-responsibility role does identify safety risks, the safety-responsibility role informs the teaching role to continue teaching. In each case, the stakeholder can provide and specify a set of interactions, for sending and receiving information on a certain topic, involving relevant objects, such as safety measures.

  • Perspective 3—Organizational InteractionView: This perspective analogously builds upon existing results, this time from taking the previously described perspectives 1 and 2. They already include roles and interactions, but both from an individual perspective. This perspective captures a set of roles this stakeholder perceives to be relevant for a specific situation in addition to the ones he/she can act him/herself, for example, taking a community or network perspective. It concerns a set of roles the stakeholder having perspective 1 and 2 cannot take or has no privilege to take. For instance, assuming the clock has fallen off the wall in a classroom with a teacher and students, and has been damaging some interior, neither the teaching role nor the safety-responsible role is sufficient to continue with giving a lecture in this classroom, like from perspective 1, another individual actorview is driven by an intention. In the sample case, the goal could be to keep the classes running that are assigned to this room. Then, the interior needs to be restored, which brings in facility management. Its specific behavior needs to be coupled to the safety-responsible role, in order to accomplish the respective tasks. Finally, there may be several perspectives related to the ‘We’, for example, evolving from an internal community of practice to formal department, networks, regions, and global connections.

Fig. 8.41
An illustration depicts the cascade of perspectives that include stakeholders, and triggers of perspectives. The three stages are the initial set of subjects, interacting initial subjects, and collective of interacting subjects.

Cascading perspectives

Since each perspective builds upon a previous one, a cascade of perspectives evolves in the course of specifying work- and process-relevant information. The middle part of Fig. 8.41 reveals the evolving complexity according to refined and networked behavior specifications. The generation of actors and their interaction relations are based on a set of questions that trigger the definition of subjects and their interactions.

Initial set of subjects: The Individual ActorView leads to a set of intentional actor roles that allow stakeholders to perform goal-oriented activities. The stakeholder at hand identifies the initial set of behavior abstractions (subjects) by dealing with the question ‘What can I do now?’ This question targets those behavior abstractions that a stakeholder can name, once a goal to be achieved in this situation becomes evident. For instance, in case the clock falls off the wall of the classroom, the ultimate goal of a teacher is to ensure the students’ safety before proceeding with the lecture. In order to achieve that goal, the stakeholder can perform a set of technical activities.

Interacting initial subjects: The Individual Interaction View leads to a set of intentional actor roles that synchronize their behavior. The stakeholder at hand identifies all those interactions between the initial set of behavior abstractions (subjects) by dealing with the question ‘How do ‘I’ interact?’ when having identified more than one role for handlings a specific situation. For instance, in case the clock falls off the wall of the classroom, the safety-responsible role interrupts the teacher to ensure the students’ safety before signaling him/her to proceed with the lecture. Hence, the interactions are defined in order to achieve the stakeholder goal determined upfront.

Collective of interacting subjects: The Organizational Interaction View leads to a set of intentional actor roles and synchronization of their behavior beyond the stakeholder at hand. This time, he/she needs to answer the question ‘How do “We” need to interact?’ when embedding further actor roles for handling a specific situation. For instance, in case the clock falls off the wall of the classroom, the safety-responsible role informs facility management, in case he/she cannot ensure the students’ safety. Every interaction with facility management needs to be defined in order to achieve the upfront determined stakeholder goal.

Figure 8.42 exemplifies the cascaded perspective. In this case, the stakeholder has identified ‘teaching’ and ‘safety responsible’ as role representatives for perspectives 1 and 2 which need to interact sensitive to the safety of the students. For the repair of the clock and classroom restoring, this stakeholder activates facility management through respective interactions.

Fig. 8.42
The figures of teaching, safety-responsible, and facility management depict the cascade of perspectives. The three stages are the initial set of subjects, interacting initial subjects, and collective of interacting subjects.

Sample diagrammatic representation

The ‘We’ perspective can be extended to bring in additional stakeholders, such as authorities managing school infrastructures, that are contacted in case needed, for example, by facility management to improve the interior. Hence, the number of cascaded perspectives depends on the intention and the goal of the stakeholder, and results in a systemic view. On the one hand, the schema allows focusing on a perceived part of a situation, while on the other hand extending perspectives limiting contextual or systemic thinking by enabling interaction links to actor roles valid from other perspectives.

Both elements are essential, as they allow handling complex situations or events without reducing the complexity itself, but rather offering a multipartite structure. This structure facilitates handling complexity, namely

  • by starting with familiar, since ego-centric behavior encapsulations (roles), and then

  • stepwise enriching this set of roles by

  • sets of interactions between ego-centric behavior encapsulations

  • including non-familiar behavior encapsulations (roles), and

  • coupling them through sets of interaction to all other behavior encapsulations

Hence, without predetermining the number of perspectives and the number of modeling elements (behavior encapsulations, interactions), a stakeholder is encouraged to express his/her perception of a situation based on interacting behavior elements. These elements represent subjects allowing stakeholders to detail pragmatic information in terms of role-specific (internal) behavior. The latter is represented in SBDs. Given the interaction between the subjects, a SID, and thus a stakeholder, can create a coherent pragmatic model of a situation.

8.4.5 Sample Applications

This section contains a report on several field tests. They have been performed to validate the approach. The model has been probed with five persons, aged between 39 and 67, three of them females, three of them instructors or teachers, the others a service provider or consultant, but both with teaching experience. Three of the persons had leadership and organizational management experience. The guide aims to reveal whether the perspectives can be cascaded as proposed by the scheme presented in the previous subsection. The interview guide contains the following items:

Consider a setting in a classroom and you are teaching a couple of students. Suddenly, you recognize the clock has fallen off the wall.

  • What is your first concern?

  • Which role(s) can you identify when you consider yourself acting in this situation?

  • What is your (set of) intention(s) allowing to encapsulate your behavior by the time of the event?

    • What does that mean in terms of interaction and communication?

Briefly indicate direction and exchange of information or goods for each of the identified roles representing intentional activities.

  • What are your further concerns?

    • Which role(s) can you take by yourself in addition to the previously identified ones?

    • What does the inclusion of these role(s) mean in terms of interactions and communication?

Briefly indicate direction and exchange of information or good for each of the additional identified roles.

  • Who else do you think should you also involve in the situation and address due to the event?

    • Which further role(s) do you consider relevant to meet your objectives in that situation and should become part of handling the event?

    • What does the inclusion of these role(s) mean in terms of interactions and communication with your (existing) ones?

Briefly indicate direction and exchange of information or good for each of the external roles.

The interviews lasted about 15 minutes each. They included laddering, in case some context appeared to be relevant for fully grasping some of the answers. For instance, the interview with a teacher, who also has extensive experience in managing schools, has led to the following insights—the collected information is structured according to the items of the interview guide:

Considering the situation where the clock has fallen off the wall.

First concern of person A:

  • Role(s): Role being responsible for safety—since the clock has fallen off the wall, I need to interrupt teaching and deal with the new situation immediately.

  • Interaction and communication: Look at students whether somebody is in danger. In case there is danger, I need to help.

Further concerns of person A: Ego-centric role(s): none

Further concerns external to own role of person A:

  • Role(s): Role being responsible for facility management I would need to inform about the event and whether additional action needs to be taken.

  • Interaction and communication: Look at the damage and student situation—inform facility management accordingly, for example, to address cleaning staff, to order a new clock, to adjust schedule.

The acquired knowledge can be conveyed, as depicted in Fig. 8.43. Person A has taken the three perspectives as guided by the interview items and intended by the scheme.

Fig. 8.43
The figures of teaching, safety-responsible, and facility management depict the cascade of perspectives. The three stages are interrupt request, clarification request with event notification and clarification decision.

Sample of elicited knowledge and sample of subject-oriented representation

Figure 8.43 also shows how we could enrich the cascaded representation to specify role behavior in terms of subject-oriented models. The short description person A has provided indicates a set of subjects—teaching, safety-responsible, facility management—relevant for handling that situation. Person A was able to refine the interaction and communication relationships between the subjects and assign the remaining activities to one of the roles she had identified. The refinements allow creating SIDs, as indicated in Fig. 8.43, by the message exchanged between the actors. The assignments allow generating SBDs and capturing sequences of activities.

In contrast to person A, person B, being a consultant, is teaching only occasionally. He identified a single actor for handling the situation. When being asked for the initial concern, it turns out he manages the situation by delegation—a student will be assigned the task to handle the unforeseen event. Person B perceives the situation to be responsible for teaching exclusively, which excludes any other responsible action in case of disturbance. Figure 8.44 shows the cascade involving ‘teaching’ and ‘student’ and the interaction representing the task delegation.

Fig. 8.44
The figures of teaching and student depict the perspectives. The three stages are individual actor, individual interaction, and organizational interaction view.

Person B’s ‘management-by-delegation’

Person C considers involving responsible actors to be essential. We could term that approach another form of ‘management-by-delegation’, but have to acknowledge that not only a student will be involved but rather a decision-making process is instantiated by activating the head of school. Figure 8.45 shows the resulting SID, in which the subject “teaching” provides the event report, which becomes part of the event notification to the principal of the student.

Fig. 8.45
The figures of teaching, student, and principal depict the cascade of perspectives. The stages are event report and event notification.

Person C—getting responsible actors involved

These small examples indicate how situations or events can be captured by individual stakeholders, giving them the freedom to cascade as many perspectives they consider relevant according to their perception and knowledge. The last case could be valid for all persons not trained as school teachers who have to inform responsible actors about unforeseen events immediately. It could become part of a behavior guide of the organization for handling unforeseen events to be studied by external teachers.

8.4.6 Insights from the Case

This case explored an orthogonal concept based on cascaded actor behavior for capturing stakeholderpragmatic perceptions of situations. We started out with Shchedrovitsky’s work on the engineering nature of managing today’s enterprises, concluding that addressing the pragmatic qualities of business operations allows stakeholders articulating work knowledge. Cascading is based on technical entities identified by intentional objectives and interaction of identified entities. It starts with familiar, behavior encapsulations (roles), and proceeds with enriching this set of roles by sets of interactions between individual behavior encapsulations. The latter include non-familiar behavior encapsulations (roles), finally leading to complete business operations from a stakeholderperspective.

Stakeholders can be encouraged to express their perception of a situation based on interacting behavior elements. These elements represent subjects as known from subject orientation, allowing stakeholders to detail pragmatic information in terms of role-specific (internal) behavior. Given the interaction between the subjects, a stakeholder can create a coherent pragmatic model of a situation. The models are designed to probe representations for operation. For instance, once the Facility Management subject is instantiated, it has to be decided (i) whether a human or a digital device (organizational implementation), and (ii) which actual device, is assigned to the subject, acting as technical subject carrier (technical implementation). Typical subjects are devices and their process-specific services, including smart phones, tablets, laptops, healthcare devices, and so forth. Subjects can also be role carriers controlling or executing tasks. Both types of instantiations can be supported by subject-oriented runtime engines. For an overview, see Krenn et al. (2017). These engines provide services linked to some ICT infrastructure.

Once the runtime engine is tightly coupled to model representations, ad-hoc and domain-specific requirements can be met dynamically. The situation-sensitive formation of systems and their behavior architecture need to be validated before being executed without further transformation. Hence, stakeholders can adapt model representations and proceed to implementation according to their articulation needs.