Keywords

1 Introduction

Business process models play a central role in the design and analysis of business processes. As its name suggests, business process modeling specifically takes the (control flow of) business processes as its primary focus. This does not mean that other aspects are not considered, but rather that the (control flow of) business processes are taken as the primary focus. Many different languages are used to model business processes, where some modeling languages are more generic, while others are more explicitly dedicated to the task of modeling business processes. Examples include: Petri Nets [2], UML’s - Activity Diagrams (UML-AD) [7], ArchiMate’s business layer [9, 12], and the Business Process Modeling Notation (BPMN) [5, 14].

While business process modeling specifically takes the business processes as its primary focus, System Dynamics (SD) [20], as a method, takes the analysis of complex and multi-faceted systems as its core focus with the aim of providing advanced simulation models of the complex and multi-faceted dynamics of such systems. As such, both approaches can contribute to the design and management of processes in an organizational context. At the same time, the fundamental difference in the primary focus of these two approaches points at a potential benefit of explicitly combining the two approaches. More specifically, such an explicit combination would have the potential benefit of better modeling and analyzing complex business processes, while also including other relevant (dynamic) facets from the environment of these business processes. Examples of the latter facets include energy consumption, produced waste, workload on workers, usage of equipment, etc. Even more, the inherent ability of SD models to provide simulations of complex dynamics, can be used to simulate the behavior of the different involved processes (covering the business process as well as other relevant dynamic systemic facets).

The authors of [3] also argue, in a broad sense, that existing model-driven development related modeling languages, such as BPMN, need to be complemented with dynamic simulation. The authors of [16] and [10] second this by more specifically arguing the need for a complementary (SD-based) perspective of SD next to business process modeling notation in terms of hybrid process simulations across different levels of detail.

The potential relationship between business process modeling and system dynamics has been touched upon before in [16,17,18,19, 21, 22], where the focus has essentially remained on the control flow aspects only. The work as reported in [19, 21, 22] pioneered the joint grounding of (high-level) SD models and (more specific) business process models on top of a general purpose domain modeling language, with the aim to produce higher quality (in terms of their conceptual fidelity) SD and business process models [22, Fig. 1].

In this paper, we report on initial results towards a more explicit, and multi-faceted, combination of business process modeling and SD. More specifically, we will provide guidelines on how to use BPMN based models and SD models together to model and analyze complex business processes. These guidelines will be illustrated in terms of a case study in the context of maintenance of the facades of building, as part of a project in the Dutch construction sector aiming to improve the recycling of aluminum as used in building facades. This case will also illustrate how BPMN diagrams can be used as the starting point for creating SD models, as they provide a clear and comprehensive picture of the sequence of activities and events in a process. The resulting SD models, in turn, can then be used to simulate the behavior of the business process over time, while relevant additional (dynamic) facets of the operational environment of the business process can be included as well.

In line with this, the remainder of this paper is structured as follows. In Sect. 2 we provide a short introduction to SD. In Sect. 3 we then briefly discuss BPMN, while also more clearly differentiating between BPMN and SD regarding the abilities for (complex) simulations. Section 4 then elaborates the idea of using BPMN in concert with SD in terms of a mapping and associated guidelines. Before concluding, we illustrate these in terms of the case regarding the maintenance of facades in Sect. 5.

The mapping as discussed in Sect. 4 is actually a first (humble) iteration of a design science cycle [23] towards the design of a more complete integration between business process modeling and system dynamics. The case as used in Sect. 5 currently serves both as a case for the initial evaluation (towards the design cycle), as well as to identify ‘use cases’ (towards the relevance cycle) for such an integration and resulting simulation potential.

2 System Dynamics Modeling and Simulation

System Dynamics (SD) was originally developed by Jay W. Forrester at MIT Sloan in 1956 to study the behavior of systems. Presently, SD is used primarily to analyze complex systems by means of simulations [20]. It involves the construction of a model of a system in terms of feedback loops and other causal relationships, and then simulating the behavior of the system over time to gain insights into its dynamics and performance. SD can be used to understand how different facets of a system interact and how changes in one area may impact other areas. SD uses two diagram types to capture SD models: Causal Loop Diagrams (CLDs) and Stock-and-Flow Diagrams (SFDs). CLDs show the main variables, the system boundaries and the overall structure of the SD model. In the process of analyzing a system, these diagrams help to scope the system, to quickly capture hypotheses about the causes of dynamics, elicit and capture the mental models of individuals or teams, and communicate important feedback loops. CLDs show how systemic variables influence each other in terms of a qualitative (positive or negative) influence. However, they do not operationalize this in quantitative terms. Therefore, SFDs complement CLDs in terms of stocks and flows of quantitative accumulations of ‘things’ (materials, value, information, tasks, CO2 emissions, energy, etc) as they ‘move’ through a system [20].

3 BPMN and Simulation

BPMN [14] provides a graphical notation to create diagrams that show the flow of activities, decisions, and interactions between different actors. As stated in [14], the main goal of BPMN is to provide a notation that is understandable to all stakeholders involved in the design and analysis of organizational processes such as managers, business analysts, information managers, software developers, and end-users. As BPMN is often used in process improvement initiatives, all these roles are involved in identifying bottlenecks and inefficiencies in a process, while subsequently creating and implementing solutions.

Simulation is often used to help managers and analysts in understanding different solutions and deciding on which to implement. With the aim of assessing the effects of changes made to the processes and/or physical settings (e.g., the ability of resources to perform tasks), without disrupting current operations, simulation is a technique that may be used to understand the behavior of a system [10]. While there are BPM-tool suppliers that offer simulation functionality based on BPMN, Pereira and Freitas [15] found that, to be able to do so, specific elements for simulation needs to be incorporated, as BPMN is not designed for simulation as such. Based on a study into common simulation properties [4] and an analysis of 5 BPM-tools with simulation capabilities, several properties were found to be lacking [15]. None of the analyzed tools had the possibility to define periods of unavailability of resources. Also, functionality for defining transfer time, interruptions and execution priorities were only available in one tool (i.e., BPSim – Trisotech BPMN 2.0 Modeler for Visio version 4.2.0). Finally, the possibility to define an allocation plan for sharing of execution activities as well as stipulating the number of replications of the simulation were only provided by two of the five tools. Still, whether properties were found to be present or not does not say anything about the level of support by the tool, therefore these outcomes can only be taken as a first indication regarding the simulation capabilities and use of BPMN.

4 System Dynamics and Process Flows

SD is often used for high-level organizational analysis, such as strategy development and analysis of policy options, where capturing information flow and feedback are essential considerations [10]. Simulation models that are based directly on BPMN can only perform analyses and decision making at an operational (discrete) level, c.f. [13]. SD, however, can be used on a more abstract level than BPMN in terms of a more continuous approach to everything in the process. For instance, for managers with the responsibility to predict future resource needs and anticipating what various options might cost their organizations, SD offers more than conventional (business process) flow modeling [8]. A conventional flow plan and some simulation in any of the conventional process modeling analysis tools will identify many problems facing organizations. However, a conventional flow plan would not provide much insight into a supply chain problem in which shipping costs, resource costs and personnel costs are all varying in different ways, each affecting the other. SD, on the other hand, is very useful for its feedback options that can influence various related parameters of the process like learning and improvement during the process, communication overhead, error rates and even increasing experience of human resources [11].

In principle, BPMN and SD share a common logic, i.e. sequential progression of activities from start to finish [10]. BPMN’s flow-and-gate based notation are conceptually similar to SD’s stocks and flows. Based on this, Table 1 provides three key mapping patterns to translate (the control flow of) BPMN to SFD.

The mapping as shown in Table 1 provides the requirements on the valves and flows as identified on the system dynamics side. We are currently investigating the most effective way (in terms of representation and simulations) to represent the semantics of the different BPMN gateways in terms of system dynamics.

Table 1. BPMN to SD mapping
Full size table

The first row in Table 1 shows the mapping of a BPMN activity A to an SFD. As an activity would require a time \(T \ge 0\) to finish after it is started, the mapping to an SFD needs to take this into account. Since such a mapping from BPMN to SFD requires this delay to be known, we have added it also to the BPMN side in terms of (a slight ‘abuse’ of) the stereotype notation: \(\text{<< } \mathop {\mathsf {delay:}} T \text{>> }\). On the SFD side, we have to create two stocks for activity A. One representing the instances of A that are active, and one for those that are finished. The flow between them is controlled by a valve h, which depends on the inflow of A_active in the sense that it releases, at point in time t, the entire inflow from \(t - T\). The situation as shown in the first row is actually the basic situation in which there is a fixed waiting time of T for activity A to finish. More generally, however, one could also consider T as a probability distribution function over time, signifying how long it would take to complete an instance of task A, such that:

$$\begin{aligned} \int _{0}^{\infty } T(t) \mathop {{\textbf{d}}t} = 1 \end{aligned}$$

For a fixed delay, we would then have \(\mathop {\exists !_{t} \left[ T(t) = 1 \right] }\), where that (unique) t is the fixed delay. For this generalized approach, we could define h (when using a continuous time axis) as:

$$\begin{aligned} h(t) \mathop {\triangleq }\int _{-\infty }^{t} \mathop {\textsf{Inflow}}(\mathop {\mathsf {A\_active}}, t - u) \times T(u) \mathop {{\textbf{d}}u} \end{aligned}$$

We take the view that the control flows between activities in BPMN essentially involve two kinds of trees: a join-tree with zero or more join-gateways, and a split-tree with zero or more split-gateways. In between a combination of such trees there will be one trigger b that bridges between the two trees. In the mapping to an SFD, the latter trigger leads to a stock we refer to as the \(\mathop {\textsf{Conflux}} _b\). This is illustrated at the top of the second and third rows of Table 1. In the case of a join-tree with sources \(A_1, \ldots , A_n\), for some n, we have the SDF pattern with \(\mathop {\mathsf {A\_finished}}_i\) stocks and a flow \(f_i\) to \(\mathop {\textsf{Conflux}} _b\). In the case of a split-tree with targets \(B_1, \ldots , A_n\), for some (other) n, we have the SDF pattern right with \(\mathop {\mathsf {A\_active}}_i\) stocks and flows \(g_i\) from \(\mathop {\textsf{Conflux}} _b\).

The lower parts of rows two and three define requirements for the flows contained in the SFD. For a join-tree (second row) we use a recursive definition following the structure of a join tree, involving \(O_i\) which defines the outflow from \(A_i\) into \(f_i\) at point in time t and ratio \(R_i\) with which the outflow from \(A_i\) is translated to an inflow for \(\mathop {\textsf{Conflux}} _b\). The actual outflow \(O_i\) depends on the combination of the different join gateways from the sources to trigger b bridging between the join-tree and split-tree. Depending on the join gateway, the outflow and inflow ratio need to be computed differently.

For the split-tree (third row) we also use a recursive definition. In this case, this only involves the rate \(R_i\) in which the stock from \(\mathop {\textsf{Conflux}} _b\) is turned into an inflow of the target stocks. This rate reflects the division of the stock of \(\mathop {\textsf{Conflux}} _b\) based on the probabilities associated to the different options of the split-gateways. On the left, we see the conditions of on these probabilities (\(r_i\)) depending on the kind of split-gateway.

In the case of a join-tree without any gateway, i.e. \(n=1\), we can optimize the resulting SFD by merging \(f_1\) and \(\mathop {\textsf{Conflux}} _b\) into \(\mathop {\mathsf {A\_finished}}_1\). Similarly, when the split-tree does involve gateways, but the join-tree does not, we can merge \(\mathop {\textsf{Conflux}} _b\), \(g_1\) and \(\mathop {\mathsf {B\_active}}_1\).

It is important to stress that the mapping of the control-flow from BPMN to SFD as shown in Table 1 is only intended to provide the ‘backbone’ of an SD model, which can then be further complemented with other facets such as energy consumption, produced waste, workload on workers, usage of equipment, etc. However, for the flows related to the consumption/production of such facets, the flow(s) through the business activities (as based from the original BPMN model) will be the main driver.

As an integrated procedure to create a BPMN and SD model together, to analyze complex business processes in conjunction with all relevant facets, we propose the step-by-step guide as discussed in the remainder of this section. This guide extends the work of [10], in particular in step 3 (i.e., the way of mapping) and steps 6 to 8 (i.e., new steps). The guide is visualized in Fig. 1.

Fig. 1.
figure 1

Visualized step-by-step guide

Full size image

Step 1: Define the scope and objectives of the process. Identify the key stakeholders, inputs, and outputs of the process, and define the performance metrics to evaluate the process.

Step 2: Create a BPMN diagram of the process using the standard notation by modeling the activities, decisions, and events involved in the process.

Step 3: Translate the BPMN model to the SFD via the mapping from Table 1.

Step 4: Add model logic and variables to the SFD to enable its execution as an SD model.

Step 5: Validate the SD model by comparing it to real-world data or historical performance data for the process. Ensure that the SD model accurately reflects the behavior of the process, and that it is consistent with the BPMN diagram. Note: in practice, this step should draw upon results from e.g. process mining in general [1], and process mining towards SD models in particular [18].

Step 6: Use the SD model to simulate the behavior of the process over time. Test different scenarios and strategies, and observe how the process responds to changes in key variables. Use the BPMN diagram to help interpret the results of simulations, and to identify opportunities for improvement.

Step 7: Use the insights gained from simulations to identify areas for improvement in the process. Modify the BPMN diagram as necessary to incorporate these changes, and test them using SD simulations. Iterate this process until identifying the optimal configuration for the process.

Step 8: Communicate the results of analysis to stakeholders using the BPMN diagram and other visualizations. Explain how the insights gained from simulations can be used to improve the performance of the process, and make recommendations for future improvements.

Fig. 2.
figure 2

Adjusted BPMN diagram for facade maintenance

Full size image

5 The Facade Maintenance Case

The application of our proposed eight-step guide is illustrated by a case study from the project PerpetuAl, which is in the context of circular Aluminum chain. The aim of our case study is to demonstrate the management of facade panels of buildings. Given the confidentiality agreement, although our model is based on a real case, the presented structure and data is not case specific. The software to build our BPMN model was Camunda, while the software for our SD model was Vensim PLE.

Step 1: A group of four researchers visited our focal firm and interviewed two customer service (maintenance) managers to identify inputs and outputs of facade construction and maintenance processes. The initial BPMN diagram was then created.

Step 2: Another researcher with multiple years of experience with BPMN modeling in practice then checked and adjusted the initial BPMN diagram, according to the standard notation. The adjusted BPMN diagram was then validated by the fourth Author of this paper. The adjusted BPMN diagram is shown in Fig. 2.

Step 3: The adjusted BPMN diagram was then translated according to the mapping provided in Table 1 by the second author of this paper. The resulting SFD is shown in Fig. 3.

Fig. 3.
figure 3

Translated stock-and-flow diagram for facade maintenance

Full size image

Step 4: Besides stocks and flows, other variables (mostly related to time/delay) and relationships (i.e. arrows) were added to the SD model (Fig. 4) to enable the simulation runs.

Fig. 4.
figure 4

System dynamics model for facade maintenance

Full size image
Fig. 5.
figure 5

Scenario simulation results

Full size image

Step 5: Authors two and four acquired historical performance data from above-mentioned customer service (maintenance) managers and validated the SD model.

Step 6: Four scenarios were simulated. The base scenario, Scenario 1, is corrective maintenance (CM), which only repairs facades after failure. Scenario 2 is to combine CM with time-based maintenance (TBM). Scenario 3 is to combine corrective maintenance with condition-based maintenance (CBM). While Scenario 4, i.e. the full model, is to combine all three maintenance practices. The scenario simulation results are summarized in Fig. 5. Please note that “Dmnl” is the short term of “dimensionless”.

Step 7 and 8: will be done in the near future. Based on the scenario simulation results (Fig. 5), Scenarios 2 and 3 will be further checked with investment/cost data to calculate whether the investment on TBM or CBM can break even within an acceptable period (e.g., two years).

The above reported case study is a part of the PerpetuAL project, which is a feasibility study for closing the circular material loop of aluminum facades. It was decided, within the project, to use BPMN for the AS-IS analysis of the existing processes, as well as for the design of the TO-BE optimized processes. The fact that BPMN enables easy process automation played an important role in this decision. Another factor that influenced this decision was the possibility to use BPMN models for process simulation. However, the standard BPMN tools do not allow us to append the models with user defined process parameters. In such a context, SD is more suited for process simulation. As reported in [8], it can be a valuable tool for greening the company’s processes, such as the modeling of facade wear, maintenance and repair, as also illustrated in the case study above. Predictive maintenance schemes (i.e., TBM and CBM) could replace traditional maintenance schedules (i.e., CM), anticipating the presence of a failure based on different data. This information can be used to feed continuous simulation models to extend the facade service life [6].

6 Conclusion and Next Steps

In this paper, we reported on initial steps towards a more explicit combination of business process modeling and system dynamics. We provided a step-by-step guide on how to use BPMN based models and system dynamics models together to model and analyze complex business processes, while illustrating this in terms of a case study on the maintenance of building facades.

As a next step, we aim to (1) further elaborate and validate the mapping as provided in Table 1, and the associated modeling guidelines, (2) develop experimental tool support to provide automatic support for this mapping and associated modeling activities, (3) develop standardized patterns to include specific facets such as energy consumption, CO2 emissions, etc., in the SFDs, (4) use these in further case studies, e.g. in relation to the PerpetuAL project and other circular economy efforts.