Keywords

1 Introduction

Process modeling is an important part in the design of modern information systems [1]. With topics like model-based business-IT-alignment gaining more attention recently [2], the question of how to qualify non-IT-proficient stakeholders for actively contributing to modeling activities in IS design is highly relevant [3]. Process modeling traditionally has been considered an experts’ discipline, where stakeholders with domain-specific knowledge were solely considered providers of unstructured input, which subsequently had to be translated to sound conceptual process models [4]. The ubiquitous deployment of IS and IT artifacts in daily business operation, which all intervene in or influence peoples’ alternatives to act in their professional environment, challenges the distinction between (non-modeling) domain experts and (model-creating) system analysts. This challenge is met in research by either providing means for pre-structuring domain expert’s inputs in a way that makes it easy to be adopted in information system models (e.g., [5]) or using modeling languages and/or facilitation techniques that are more accessible to domain experts than traditional technology-centric approaches like UML (e.g., [6]). Industry has also recognized the need for such approaches and has reacted with systems that are recently referred to as low-code platformsFootnote 1.

While these approaches seem to be successful with respect to the aim of designing information systems that meet the needs and requirements of its prospective users, they do not explicitly address how to support the development of an understanding of modeling concepts and skills in appropriately applying them. Research in areas like end-user development [7] and programming education [8] has explicitly adopted this perspective. It, however, has so far largely been ignored in business and information systems research. This paper makes a first step towards addressing this issue. It introduces an instrument that supports domain experts without modeling experiences to develop an understanding of the relationship between conceptual process models and actual work processes by interactive participatory simulations. Following the experiential learning paradigm, we hypothesize that anchoring the discovery of modeling concepts in the actual work process should enable domain experts to articulate their perceptions about their work in appropriate process modeling constructs. In this paper, we focus on the design of the support instrument that will enable us to examine this hypothesis in future research.

We proceed as follows: First, we revisit approaches on teaching process modeling concepts and support modeling skill development to position our approach in the body of available prior research. We then elaborate on the approach of introducing process modeling concepts through participatory simulations. In the following section, we introduce our proposed support platform. We finally briefly report on our initial experiences when deploying the platform educational settings.

2 Teaching Process Modeling - State-of-the-Art

Process Modeling has been recognized as a teaching challenge as early as the 1960s [9]. Existing research has addressed this challenge largely from a didactical perspective on curriculum- or course-level. In formal, curriculum-based educational settings, teaching process modeling has been a topic of research. It has been examined on a curriculum level by Stewart [10]. Single course designs have been proposed and evaluated in this area [11,12,13]. All these works, however, focus on content and course organization and largely omit methodological questions that examine how an understanding for process modeling concepts can be developed.

In terms of global methodology, Powell [14] calls for teaching conceptual modeling in a setup that allows to work with prototypes, enabling students to iteratively build and assess their models. Recker and Rosemann [11] suggest to take modeling cases from disciplines familiar to students, enabling them to focus on the development of the ability to identify, and critically reflect upon, relevant “process” concepts. Stewart and Rosemann [10] report on successful teaching interventions in information systems education with an inverted curriculum approach, letting students experience modeling in a practice-oriented context first, and only subsequently learn the detailed conceptual foundations.

Regarding operative teaching methodology, Powell and Willemain [15] have empirically examined mathematical modeling processes of novice learners and derive qualitative insights and implications for teaching from their observations: (a) students need to be guided to develop an abstract understanding of a problem from concrete instances of this problem; (b) students require support in progress-monitoring during problem solving, e.g., by pointing them to open issues in their current model version; and (c) prototyping helps in developing increasingly complex and insightful models.

Desel [16] stresses the importance of using interactive simulations to validate behavioral models of systems. Validation through simulation is used as a means of learning about the properties of a model from its simulated behavior and eventually adapt it to meet expected behavior or other desired properties. Interactive simulations incorporate users’ activities and allow them to experience the modeled behavior. In the same line—with a focus on socio-technical business systems as a whole—Buur et al. [17] argue for participatory simulations via interactive role playing to validate business models and develop an understanding about fundamental modeling concepts. It is important to stress here, that the simulations proposed in these works focus on behavioral simulations of socio-technical systems under the interactive involvement of users rather than simulations of the input/output behavior of information systems that are considered black boxes.

The review of existing methodological considerations as presented above on how to develop generalizable conceptualizations of ones’ perceptions of a work process point at following an experiential learning approach [18] for operatively supporting the learning process. In the context of the present work, this means that an appropriate approach should let learners experience processes, which are represented in conceptual models, and—based on their perceptions—reflect on their underlying structure. Following the experiential learning paradigm, this should start with experiencing the behavior exposed by actors in a work process, facilitate the development of an abstract conceptual understanding, which then in turn should be validated by actively experimenting with process modifications (i.e., iteratively altering the model and experiencing the changed process).

Such experiential learning approaches have been successfully deployed in different disciplines to introduce learners to domain-specific concepts and facilitate the development of their skills in appropriately handling them. Thatcher [19] discusses how experiential learning in general can be facilitated through games and simulation, stressing the importance of such simulations being of participatory nature and accompanying them with a debriefing-phase that is used to reflect on the experiences and conceptual findings of the involved participants. Several researchers have examined participatory simulations to aid the development of abstractions skills: The interactive programming environment ScratchFootnote 2 has been successfully deployed to support novices to develop an understanding of fundamental computer science concepts via guided iterative experimentation and modeling activities [8, 20].

Research in the area of end-user development provides evidence that live evaluation via interactive simulation of models supports understanding of the effects a model has on the actual work process [21] or on the software described in the model [22], in particular when the effects of changes made to a model are immediately visible in the simulation [23]. Experiential learning based on simulation has also been deployed in other disciplines, such as industrial management [24] or work system design [25]. Clancey et al. [25] call for simulations based on interaction-oriented modeling rather than flow-oriented modeling to enable a more immediate connection to practicioners’ perceptions of their work systems. De Smedt et al. [26] show, how gamified simulation of declarative process models can aid the understanding of the semantics represented in the models.

Summarizing, the reviewed related work in general proposes a practice-oriented introduction of modeling fundamentals, and indicates that interactive simulations can enable linking the behavior represented in a process model to its constitutive elements. Concrete methodology on an operative level or tools support for such learning processes, however, have hardly been a subject of research. We thus examine related disciplines such as programming education in the next section on how interactive simulations can be used methodologically and technically for the aims of the present article.

3 Participatory Simulation Support Instrument

The requirements on an instrument supporting participatory simulation can be derived from the results of our literature review. The state-of-the-art in process modeling education indicates that learning processes on understanding process modeling are supported by anchoring them on actual experiences of the process. The findings on how to support experiential learning processes by interactive model simulation leads us to hypothesize that mapping perceptions of the simulated process and the underlying model can be supported by interactive experimentation with the model. This leads to an indicative list of four requirements on the instrument itself:

  • R1: Enable experiential learning through participatory interactive simulations of (work) processes in an actor-centric way [8, 25]

  • R2: Enable to experiment with the simulation and change the underlying model [14, 16, 17], where changes to the underlying model have to be immediately explorable (i.e., without re-starting the simulation) [7, 23]

  • R3: Provide support for learners using different abstractions of the work process when exploring and/or altering processes to help them understand the link between their perception of the work process and the underlying model [15, 20]

  • R4: Provide interactive guidance during the phases of experiential learning [15, 24], including ex-post debriefing phases to discuss individual learnings and explicitly reflect on the generic concepts identified during participatory simulation [10, 19].

Based on these requirements, we have designed and implemented an instrument that should support learning about modeling concepts via participatory simulation. It is supported by a web-based platform, which we introduce in the following. The technical design of this platform has been described in [27]. Here, we focus on those features that aim at supporting the development of a conceptual understanding about process modeling.

The instrument is built using the Vaad in frameworkFootnote 3. It follows an actor-centric approach for simulation processes. The instrument is designed to be used in group settings, where at least one person representing each of the actors modeled in the process should participate. The components of the instrument (cf. Fig. 1) are designed along the requirements identified in the former section.

Fig. 1.
figure 1

Architectural overview

Full size image

The core of the instrument is the simulation engine, which enables users to interactively simulate process models and explore their structure in an experiential way (R1). Simulation is based on the process representation, which is stored in an actor-centric way (R1). During simulation, the current progress in the process and its history are represented in an instance representation. Process models can be stored in and loaded from an XML-based format for accessing earlier results.

The guided elaboration module enables users to alter the process underlying the simulation and continue the simulation immediately at the modified position (R2). It does not require users to manipulate the process model directly, but guides them through the elaboration process using prompts that elicit the required information based on the simulation state the elaboration process was triggered in (R3).

Simulations of a process can be carried out an arbitrary number of times, where the instrument keeps track of which aspects of the model have not yet been explored (R2). The scaffolding module, among other features, provides hints at how to progress with the participatory simulation to explore all aspects of the underlying process (R4).

The process visualization module provides graphical representations of the process model with various complexity that can be used based on the participants’ needs and capabilities (R3). It is furthermore capable of visualizing the current state of the simulation and the path taken through the process so far (R4), as well as the modification history of the process, which should eventually lead to users recognizing the relationship between modeling constructs and their impact on the activities represented or influenced by them (R3). In the following, we describe the different components in more detail.

Process and Instance Representation.

The process representation is based on an actor-centric business process modeling approach [28]. The behavioral models of actors are separate processes and are only linked through messages that actors can send and receive. This resembles the semantics of pools and message flows in BPMN. Such loosely coupled processes enable local changes to the model (i.e., only immediately affecting the behavior of one actor).

Elaboration activities can leave the model in an inconsistent state (e.g., an actor could expect a message, which is not yet provided by another actor). Such inconsistencies are kept track of in the process representation and can be resolved later in further elaboration steps.

The instance representation only stores the currently available activities for each actor and the path taken through the process until there (to enable “undo” actions for easier exploration). In a simulation step, the next available activities are always derived directly from the underlying process model. In this way, process changes immediately affect the simulation.

Simulation Engine.

The simulation engine uses the data provided by the process and instance representation to render a user interface that enables participatory simulation of the process. It simultaneously displays the current state of each actor and, according to this state, offers interaction options to the participants (cf. Fig. 2).

Fig. 2.
figure 2

Simulation interface

Full size image

This simultaneous visualization of each actor provides a permanent display of the overall context of the current simulation in the participatory setting. Participants thus can track the impact of their interactions with the simulation and in this way learn about the different types of activities (i.e., action, send message, receive message) that constitute the behavioral model of a single actor.

The simulation engine also serves as the gateway to guided elaboration. Process changes are always situated, anchored on the current state of the simulation. In this, way participants can immediately see the impact of their changes on the simulation. They additionally have the option to undo changes if they did not achieve the intended effects. This supports exploratory behavior, strengthening the opportunity to not only explore the process but also gain experience with different types of process changes. In combination with the visualization component described below, this allows to link modeling constructs to experienced simulated behavior during reflection phases, thus further supporting experiential learning.

Scaffolded Exploration.

Guidance in the experiential learning process is provided by the scaffolding module. Scaffolding is a concept from the field of educational tutoring [29]. It originally refers to having an experienced person help an unexperienced learner to acquire knowledge about a particular topic. Scaffolding is a metaphor adopted from construction industry and refers to a temporary means of support that is present until the scaffolded entity (here: people acquiring knowledge about process modeling via participatory simulation) can accomplish a given task itself. In order for scaffolds to be acceptable for learning subjects and provide added value to them, they need to be directed appropriately at their current skill level [30]. In the context of the present work, this means that tips on how to explore the simulation need to be provided on different levels of concreteness, depending on the users’ proficiency in using the tool.

Figure 3 shows the main scaffolding interface, that allows to navigate through the currently available tips. The mechanism to identify relevant tips has been designed in a flexible way, so that they can target different aspects of the simulation, such as previously unexplored model parts or remaining inconsistencies in the model (for details on which types of tips are relevant, cf. [31]). The right part of Fig. 3 shows a tip on two different levels of concreteness. The tip descriptions are dynamically created based on the current state of the simulation (e.g., the list of required steps in the lower left part of the figure is created based on the currently available activity of the respective actor).

Fig. 3.
figure 3

Interface of scaffolding engine

Full size image

Guided Elaboration

To enable active exploration of different process constructs, guided elaboration is triggered from any currently available activity in the simulation (cf. Fig. 2). The elaboration module renders a user interface that uses dynamically assembled prompts to elicit the information necessary to make the process change as required by the users. Users here are not confronted with modeling constructs, but can specify their changes in a problem-centric way, anchored on the respective activity.

Figure 4 shows a sample prompt for guided elaboration. In this case, the users have chosen that the currently available activity is not appropriate in their current situation, as they would have expected further input to be available before they could execute it. The prompt shown in Fig. 4 asks them to specify the input they would have expected and where they think they can get it from. The list of further prompts dynamically changes according to their selection, as, e.g., selection of an existing actor as the source of the expected input would not require a further prompt, whereas the current selection leads to the speciation of an additional actor.

Fig. 4.
figure 4

Interface of elaboration engine

Full size image

Users are free to navigate through the prompts to explore their options. Once the users confirm their inputs, the changes are applied to the process model. The instance information is adapted, so that users continue the simulation at the modified activity, thus being able to immediately experience the impact of their elaboration. Model changes are stored and can be undone, if the change is recognized to be inappropriate.

Visualization of Models.

To enable users to create a link between the current state of the simulation and the underlying model, visualizations of the model can be displayed at any time during exploration. The visualizations are available in different levels of complexity and from different perspectives on the process (view per actor, overall actor-centric view, overall flow-oriented view), and are augmented with information about the current instance, such as the currently available activities and the path through the process. The visualizations are created dynamically using the GraphViz software suite [32].

Figure 5 shows visualizations for an instance that has been simulated halfway through a sample process. The four models at the top of the figure together form the least complex visualization, where the behavior of each actor is shown as a separate model. The model at the very left shows the interaction among the actors. The greyed-out boxes indicate already executed activities, whereas green boxes represent currently available activities. The lower left model in Fig. 5 compiles the separate actor models in a single visualization and enriches them with connections representing the exchanged messages. The lower right model removes the actors as the primary structuring dimension for the overall model and, in this way, provides a flow-oriented view on the process. Users can switch between the actor-specific behavior models, the interaction overview and the two overall views at any point in time and, in this way, can focus on different aspects of the model in the course of simulation or during reflection phases.

Fig. 5.
figure 5

Process visualizations

Full size image

4 Exploratory Evaluation

The instrument has been deployed in an exploratory evaluation to perform an initial check of its conformance to the requirements formulated above.

Procedure.

The requirements identified in Sect. 3 have been re-formulated to evaluation hypotheses based on their actual implementation in the instrument. They have been examined in an exploratory study. These hypotheses are: H1: Experiential learning can be facilitated through participatory simulations of (work) processes in an actor-centric way. H2a: The provided instrument facilitates iterative experimentation with the simulation and enables changes to the underlying model. H2b: Users understand how to make changes to the model and how to validate them immediately in the simulation. H3: Users actively use the different forms of visualization to explore different abstractions of the process. H4: The tips provided by the instrument are perceived to be useful in the process of experiential learning.

The hypotheses have been assessed in the study via observation of learners using the instrument and subsequent discussion of their experiences. Observation has been performed by the researchers, who used a semi-structured template for taking notes for each group of learners. Discussion was carried out in the same groups of learners. The discussion was structured along the hypotheses formulated above.

The evaluation was carried out in a course on interactive systems design with 52 students of business information systems in the second or third year of their studies (40 male, 12 female, age ranging between 21 and 45). All participants had initial experiences in business process modeling with BPMN. The participants formed 12 groups of 4–5 participants. They were asked to perform 3 participatory simulations with different tasks. Task design was oriented towards experiential learning, starting with exploratory tasks and progressing to active experimentation (task 1: focus on exploration of a given process model, task 2: focus on elaboration of a given model with prescribed changes, task 3: focus on developing a model from scratch, based on a description of the required target behavior).

Results.

We briefly describe our findings from the exploratory study with respect to the hypothesis formulated above.

H1: :

The observed behavior throughout all groups indicates that experiential learning about the intended topics took place after an on boarding-phase on using the instrument with varying length. After the participants had explored the instrument and understood its features, they started to reflect on the simulations content-wise and tried to map their observations to process modeling concepts (as they already had fundamental knowledge of BPMN). In the simulations containing elaboration tasks, most groups spent extensive amounts of time thinking about how the prompts of the elaboration guidance module translated to particular model elements. They subsequently confirmed their assumptions using the provided visualizations. Our observations were confirmed in the discussions, where participants frequently stated that they were permanently triggered to think about the underlying model constructs during elaboration. Overall, there are indications that H1 can be confirmed

H2a: :

The observed behaviors during completing the simulation and elaboration tasks indicate that the instrument was perceived to be largely adequate in supporting experimentation. The users actively explored the provided processes and the elaboration options. The option to undo changes was regularly used, if a change did not achieve the intended effects. The users, however, also encountered limitations in the guided elaboration module that prevented them from performing all their changes as intended (i.e., the prompts did not cover all expected change possibilities). Discussion confirmed that the instrument was perceived to be largely adequate and the provided features were considered useful. Overall, H2a thus can largely be confirmed with some limitations for the current version of the instrument

H2b: :

Making changes to the underlying model via elaboration initially caused confusion in some groups, as the participants struggled to link the prompts to their intended process modifications. However, after some exploration of the option, the participants were largely able to complete their task. Discussion confirmed that they had no problems in making changes as intended after they had confirmed their initial hypotheses about the link between prompts and inserted model constructs. H2b thus can be partially confirmed for the current version of the instrument

H3: :

The visualizations were frequently opened during simulations and used for orientation in the process by all groups. When using visualizations, the participants largely used the models of single actor behaviors, sometimes switching to one of the overall views, if they wanted to explicitly track message exchanges. The actor-centric view was preferred over the flow-oriented view. In the discussion, this preference was attributed to the actor-centric orientation of the simulation interface, which made a mapping of the actor-centric model visualization easier than the flow-oriented visualization. In general, however, the less complex visualizations of the single actor models were preferred. Overall, we could find indications that H3 can be confirmed

H4: :

Active use of the exploration and elaboration tips could hardly be observed during the simulation and elaboration tasks. While participants seemed to take notice of the tips, they hardly ever opened the detailed instructions or considered the tips during their activities. During discussion, participants noted that the other elements of the user interface were perceived to be more important and were placed more prominently on the user interface. Furthermore, the ignorance of the tips might also be attributed to the already existing modeling experiences of the participants. Overall, H4 cannot be confirmed for the current version of the instrument

5 Conclusion

In this paper, we have presented an instrument to introduce fundamental process modeling concepts via participatory simulation. The instrument has been designed based on requirements derived from existing research on process modeling education and experiential learning. In an initial exploratory study, we could confirm that the instrument seems to meet the major requirements, but also found some limitations in the modules aiming at supporting the experiential learning process. It needs to be stressed here that the study results are of limited validity due to exploratory nature of the deployed methodology that did not allow to explore potential reasons for observed behavior in-depth, but still provide a starting point for further development.

Our future development will initially focus on fixing the limitations identified in the study. The elaboration engine will be refined to cover further possibilities for process changes and eventually also should allow to trigger changes not only from the simulations, but also from model visualizations (to aid the validation of modeling construct hypothesis in later learning phases). Furthermore, introduction of the instrument’s features needs to be promoted more actively. In this respect, we currently work on an on boarding system that interactively introduces the features.

On a larger scale, we are planning to embed the instrument’s deployment in a whole course design to satisfy the requirement of a debriefing phase. This will allow to study the instrument’s effects regarding the aim of supporting learners in acquiring fundamental knowledge about process modeling constructs.