=Paper=
{{Paper
|id=Vol-3779/paper3
|storemode=property
|title=Discovering Process Framing for AI-Augmented BPM Systems in a Multi-Process Setting
|pdfUrl=https://ceur-ws.org/Vol-3779/paper3.pdf
|volume=Vol-3779
|authors=Anti Alman,Izack Cohen,Avigdor Gal,Fabrizio Maria Maggi,Marco Montali
|dblpUrl=https://dblp.org/rec/conf/pmai/AlmanCGMM24
}}
==Discovering Process Framing for AI-Augmented BPM Systems in a Multi-Process Setting==
https://ceur-ws.org/Vol-3779/paper3.pdf
Discovering Process Framing for AI-Augmented BPM
Systems in a Multi-Process Setting
Anti Alman1,* , Izack Cohen2 , Avigdor Gal3 , Fabrizio Maria Maggi4 and
Marco Montali4
1
University of Tartu, Tartu, Estonia
2
Bar-Ilan University, Ramat Gan, Israel
3
Technion – Israel Institute of Technology, Haifa, Israel
4
Free University of Bozen-Bolzano, Bolzano, Italy
Abstract
A core component of AI-Augmented Business Process Management Systems (ABPMS) is framing which
gives the system process-awareness and defines the boundaries in which the system must operate. When
developing an ABPMS, framing can be created manually based on domain knowledge or automatically
discovered from prior process executions. Existing process discovery approaches work well for the
latter, assuming the individual processes can be identified and analyzed in isolation. However, this is not
guaranteed if prior executions were recorded by a system that was not process-aware. In such cases, the
bare minimum requirements for process discovery, namely ordered activity sequences grouped by a case
identifier, may still be met. For example, treatment activities in a hospital can still be grouped by the
patient identifier regardless of how many individual treatment processes (e.g., due to comorbidities) the
patient underwent in the same time frame. In this paper, we present a process discovery approach for the
above setting. Our focus is on discovering concurrently executed procedural processes, in the presence
of shared activities, while the approach itself relies on interpreting declarative process discovery results.
Keywords
process discovery, process framing, concurrent processes, multi-model paradigm, Petri net, Declare
1. Introduction
A recent research manifesto on AI-Augmented Business Process Management Systems (ABPMS)
outlines a vision in which traditional BPMS lifecycle is augmented with AI technologies to
allow the system to “reason about the current state of the process (or across several processes) to
determine a course of action that improves the performance of the process” [1]. In that vision, a
core component of any ABPMS is framing, which provides the system process-awareness and
defines the boundaries in which the system must operate to achieve its goals. Framing can be
expressed in a variety of business process modeling languages, and even hybrid combinations
of procedural and declarative languages are acknowledged as a possible option [1].
PMAI@ECAI24: International ECAI Workshop on Process Management in the AI era, October 19, 2024, Santiago De
Compostela, Spain
*
Corresponding author.
$ anti.alman@ut.ee (A. Alman); izack.cohen@biu.ac.il (I. Cohen); avigal@technion.ac.il (A. Gal);
maggi@inf.unibz.it (F. M. Maggi); montali@inf.unibz.it (M. Montali)
0000-0002-5647-6249 (A. Alman); 0000-0002-6775-3256 (I. Cohen); 0000-0002-7028-661X (A. Gal);
0000-0002-9089-6896 (F. M. Maggi); 0000-0002-8021-3430 (M. Montali)
© 2024 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
ceur-ws.org
Workshop ISSN 1613-0073
Proceedings
Despite the importance of framing, little indication of how it would be created for an ABPMS
is given in [1]. Broadly speaking, we see two options here. The framing could be modeled
manually during the analysis and development of the ABPMS, or it could be automatically
discovered from the recordings of past executions of the related processes using process mining
techniques. There are numerous process discovery algorithms available for this purpose, all of
which assume input data in the form of an event log.
In general, event logs are only required to contain sequences of activity executions grouped
by case identifiers, where each unique case identifier is assumed to distinguish separate execu-
tions of the same underlying process. For example, each treatment instance of a heart attack
(regardless of the variance between instances) is required to have a unique case identifier and
is assumed to be in an event log containing only instances of other a heart attack treatments.
We refer to the latter as the process uniqueness assumption, and it can be easily met if process
executions have been recorded by a Process-Aware Information System (PAIS) [2]. In absence
of process-awareness, event logs could still be created on the basis of more general identifiers
such as personal codes of the patients. However, this may result in mixing activities of multiple
processes (e.g., heart attack may occur at the same time with a trauma injury [3]), and therefore
the process uniqueness assumption would no longer be guaranteed to hold.
In this paper we present a process discovery approach that can handle separately defined
processes being seemingly executed with the same case identifier, thus foregoing the process
uniqueness assumption. Furthermore, this approach can handle semi-concurrent process execu-
tions (e.g., one process being paused to address an immediate concern in another process) and
interdependencies between processes (e.g., one process requiring input from another process or
a single activity progressing multiple processes simultaneously). The former means that we can
no longer rely on directly-follows relations, which are the basis of most current process discov-
ery algorithms, while the latter necessitates handling of synchronizations between otherwise
separate processes. In contrast to existing approaches, the proposed approach first discovers a
constraint-based declarative representation of the behavior in the given event log, which is then
processed to provide a procedural model of the underlying processes and their interactions.
In the context of ABPMS, the proposed approach enables the automated discovery of (at
least partial) framing based on past activity executions recorded by non-process-aware systems.
While the discovery of the complete framing cannot be guaranteed from the past executions
alone (e.g., some currently allowed behavior might not be executed in the past), the proposed
approach should nevertheless be a valuable tool for the analysis and development of ABPMS.
In the remainder of this paper, Section 2 outlines our proposed approach and demonstrates
its output in a multi-process setting. Section 3 provides a comparison to two existing process
discovery approaches. Sections 4 and 5 highlight limitations and related works respectively.
Finally, Section 6 concludes the paper by outlining directions for future work.
2. Approach
Our approach relies on two modeling languages, namely, Declare [4] and Petri nets [5]. The
former is used for discovering and working with specific types of eventually-follows relations,
while the latter is used to represent the final discovered model. Next, we describe the eventually-
follows relations used in our approach (Section 2.1), the patterns for combining sets of these
relations into Petri net fragments (Section 2.2), and the procedure for creating a complete Petri
net from these fragments (Section 2.3). Finally, we conclude this section by demonstrating the
output of our approach in a multi-process setting (Section 2.4).
2.1. Discovering Eventually-Follows Relations
As the first step, we use Declare Miner [6] to discover a Declare model of the following relations
between the activities in the given event log (with A and B serving as activity placeholders):
• Succession(A, B) – A occurs if and only if it is eventually followed by B;
• Response(A, B) – If A occurs then it will be eventually followed by B;
• Precedence(B, A) – If A occurs then B must have occurred some time before;
• Not Co-Existence(A, B) – If A occurs then B will never occur (and vice-versa);
• Co-Existence(A, B) – If A occurs then B will eventually also occur (and vice-versa);
• Not Succession(A, B) – If A occurs then B can no longer occur.
Intuitively, Succession identifies potentially optional activities that always occur in the same
order, Response identifies mandatory followers of potentially optional activities, and Precedence
identifies prerequisite activities of potentially optional activities. Additionally, Not Co-Existence
identifies mutually exclusive activities, Co-Existence without (Not) Succession identifies parallel
activities, and Not Succession together with Co-Existence identifies any fixed activity orders.
All aforementioned relations are discovered between all pairs of activities assuming there is
at least one positive example and no counter examples for the given relation with the given
activity pair. Additionally, to simplify processing, an artificial start and end activity is added to
each execution trace, ensuring the discovery of at least one Response and one Precedence (or
Succession in case of a mandatory activity) per each activity. Finally, the discovered relations
are pruned [7] to remove relations which are implied by other relations (e.g., if both Succession
and Response hold for the same pair of activities, then the Response relation is removed).
2.2. Patterns
Our approach uses four pairs of patterns, each of which corresponds to the manifestation of
some procedural behavior (e.g., sequence flow, choice, etc.) in the Declare modeling language.
All pairs are symmetric (similarly to Alpha Miner [8]), such that one pattern of the pair handles
procedural split gateways and the other handles the corresponding join gateways. Next, we
describe the pattern pairs as they would apply to the relations of a single activity, while more
complex processing is discussed in Section 2.3. The relations for each pattern are given on the
left side of its figure, while the matching Petri net fragment is given on the right (e.g., Fig. 1(a)).
Simple sequence flow and parallelism. Patterns 1a and 1b (Fig. 1) are used for simple
sequence flows and parallelism. For example, Succession(A, B) is interpreted as a Petri net
fragment where the transition A has one output place that provides a token for the transition B.
Multiple Succession relations originating from the same activity are interpreted as the start of
(a) Pattern 1a. (b) Pattern 1b.
Figure 1: Patterns handling simple sequence flows and parallelism based on Succession relations.
(a) Pattern 2a. (b) Pattern 2b.
Figure 2: Patterns for handling exclusive choices based on Precedence, Response, and Not Co-Existence
relations.
parallelism (i.e., AND-split), while multiple Succession relations leading to the same activity are
interpreted as the end of parallelism (i.e., AND-join).
Exclusive choice. Patterns 2a and 2b (Fig. 2) are used for mutually exclusive choices. The
beginning of a mutually exclusive choice (i.e., XOR-split) is matched by pattern 2a, where
the relations intuitively mean that B, C, ... can be executed only if A has occurred some time
before (due to the Precedence relations), and at most one of B, C, ... can be chosen (due to
Not Co-Existence relations). Meanwhile, pattern 2b matches the end of a mutually exclusive
choice (i.e., XOR-join), with the intuition being that B, C, ... must be eventually followed by
D (due to the Response relations). By default, both patterns add a silent transition into to the
corresponding Petri net fragments to allow all of the mutually exclusive activities to be skipped.
However, if the frequency of the mutually exclusive activities is equivalent to the frequency of
A in pattern 2a or D in pattern 2b, then the silent transition is omitted.
Optional parallelism. Patterns 3a and 3b (Fig. 3) match a special case of parallelism where the
entire parallel structure may be skipped. The intuitive meaning of Precedence and Response
relations is the same as in patterns 2a and 2b, however, the Co-Existence relation (instead of Not
Co-Existence) means that if any of B, C, ... is executed, then all of them must be executed. We
note that, activity frequencies do not need to be considered here, since equivalent frequencies,
would lead to Succession relations instead of Precedence and Response relations.
Inclusive choice. Patterns 4a and 4b (Fig. 4) are used, effectively as fallback patterns, for cases
where a single activity has multiple outgoing Precedence or incoming Response relations, but
patterns 2a, 2b, 3a, and 3b do not apply. Intuitively, pattern 4a corresponds to the beginning of
an inclusive choice (OR-split), while pattern 4b corresponds to the end of an inclusive choice
(OR-split). In both patterns, the activities B, C, ... are placed in parallel together with an option
to skip each individually, thus also allowing cases where none of B, C, ... are executed.
(a) Pattern 3a. (b) Pattern 3b.
Figure 3: Patterns for handling optional parallelism based on Precedence, Response, and Co-Existence
relations.
(a) Pattern 4a. (b) Pattern 4b.
Figure 4: Patterns for handling inclusive choices and optional activities based on Precedence and
Response relations.
(a) Source Petri net. (b) Discovered Declare model.
Figure 5: Source Petri net and the corresponding discovered Declare model with pruning applied (Not
Succession and Co-Existence relations omitted for understandability).
2.3. Creating the Procedural Process Model
The procedural behavior of a given event log can be reconstructed, given the eventually-follows
relations from Section 2.1 and the patterns from Section 2.2. The basic idea is to begin with a
Petri net containing only the artificial start (cf. Section 2.1) and then applying the patterns to it
in a specific order. In doing so, additional transitions are added to the net, each of which will
be processed in the same way, until one transition is created (and processed) per each activity.
This results in a single Petri net representing the behavior of the underlying processes and the
interactions between them. The corresponding procedure is summarized in Algorithm 1.
As an example, we use an event log containing the executions of Fig. 5(a) (with no violations
and at least one occurrence of each activity). From this log, the Declare Miner will discover the
relations presented in Fig. 5(b). To construct a corresponding procedural process model we start
with an empty Petri net, into which we add a transition start with one input place. This leads
to processing the relations of the activity start, which has only the relation Succession(start, A).
Therefore, we can directly apply pattern 1a to add a transition A into the Petri net, together
with a place that gets a token from transition start and provides it to transition A.
Next, we move to processing activity A. For this activity, we have multiple outgoing relations:
• Succession(A, D) matches pattern 1a directly and would lead to correct placement of D in
the Petri net;
• Relations between A, C1, and C2 are a direct match to pattern 2a, but would lead an
incorrect placement of the corresponding XOR-split directly after A.
• Relations between A, B1, and B2 are a direct match to pattern 2a, but B2 is also in a Not
Co-Existence relation with B3, which also matches pattern 2a;
We employ the following three additional rules to handle this situation:
Rule 1. If the outgoing relations of an activity match multiple patterns, then this is solved
through parallelism. In the given example, A would get one output place providing a token
for D (as per pattern 1a), and one additional output place per each application of pattern 4a.
Furthermore, the patterns are considered in the order of 1a, 1b, 2a, 3a, 4a, 2b, 3b, 4b. The main
purpose of this ordering is to apply more specific patterns first (for example, the Co-Existence
relations in pattern 3a make it a more specific version of pattern 4a);
Rule 2. If there is any fixed order between outgoing or incoming activities, then only the
relations to temporally “closest” activities are considered. In the given example, if any of B1,
B2 or B3 occurs, then it must be before either C1 or C2 occurs. This is determined based the
existence of Not Succession and Not Co-Existence between the pairs of activities. For example,
the Declare Miner would find a relation Not Succession(C1, B1) (omitted from Fig. 5(b)) without
finding relation Not Co-Existence(C1, B1). This indicates that B1 and C1 may occur in the same
trace, and, if they do, then C1 must occur after B1. As a result, we can ignore outgoing relations
to C1, and also to C2, while processing A, as both will transitively appear at some point after
B1. An analogous comparison is later also required for the incoming activities of E;
Rule 3. If pattern 2a (or 2b) can be applied to sets of partially overlapping activities, then
pattern 2a (or 2b) will be applied once per each of these sets. This rule is necessary because of
the non-transitive nature of the Not Co-Existence relation, meaning that Not Co-Existence must
be observed between all pairs of activities to be placed after XOR-split (or before XOR-join).
Given Fig. 5(b), the pattern 2a could be applied to { A, B1, B2 } and { A, B2, B3 }, with B2 being
the overlapping activity. In this case, pattern 2a must be applied to both sets of activities, such
that A produces a token into a place providing it to B1 and B2 (first application of pattern 2a),
and A also produces a token into a place providing it to B2 and B3 (second application of pattern
2a). In more complex cases, this can be solved by finding all maximal Not Co-Existence cliques
among the activities (e.g., by using [9]) and applying pattern 2a (or 2b) once per each clique.
This leads to transitions B1, B2, B3, and D being added to the Petri net, all of which will be
processed one by one based on the above rules and the corresponding patterns.
Finally, the Petri net (𝒫𝒩 ) returned by Algorithm 1 is post-processed to handle optional
behavior. More specifically, all patterns, except for 1a and 1b, can produce silent transitions,
which either do not have any output places (indicating the start of some optional behavior, i.e.,
skip start) or do not have any input places (indicating the end of some optional behavior, i.e., skip
end). For each skip start, we first find all outgoing activities from places that may provide a token
for that skip start. For each of these activities, we then find the outgoing Precedence relations.
This indicates all the activities that must also be skipped if the given skip start transition is fired.
Then, we do the same for each skip end while finding the incoming activities from all places
into which the skip end produces a token. For each of these activities, we find the incoming
Response relations, which gives a set of activities that must also be skipped if the given skip
end transition is fired. Then, each skip start is merged with the skip end for which the sets of
skipped activities are equivalent.
Algorithm 1 Petri net construction from activity relations.
input : relations ℛ // as discovered in Section 2.1
output : Petri net 𝒫𝒩
1 Θ := (1𝑎, 1𝑏, 2𝑎, 3𝑎, 4𝑎, 2𝑏, 3𝑏, 4𝑏) // see Section 2.2 and Rule 1 in Section 2.3
2 Σ𝑈 := {start} // initialize Σ𝑈 with the artificial activity ‘start’
3 𝒫𝒩 := {𝑝0 ∧ 𝑝0 ∙ = start} // initialize 𝒫𝒩 with place 𝑝0 and transition start
4 while Σ𝑈 ̸= ∅ do
5 𝛼 := 𝛼 ∈𝑅 Σ𝑈 // choose random activity from Σ𝑈
6 ℛ𝑈 := {ℛ𝑖 |𝐿(ℛ𝑖 ) ∋ 𝛼} // consider only the relations containing 𝛼
7 ℛ𝑈 ← {ℛ𝑈 𝑈
𝑖 |ℛ𝑖 𝑡𝑒𝑚𝑝𝑜𝑟𝑎𝑙𝑙𝑦 𝑐𝑙𝑜𝑠𝑒𝑠𝑡 𝑡𝑜 𝛼} // see rule 2 in Section 2.3
8 for each 𝜃 ∈ Θ do
9 𝒫𝒩 𝑈 := 𝜃(𝛼, ℛ𝑈 ) // instantiate pattern 𝜃 using 𝛼 and ℛ𝑈
10 Σ𝑈 ← Σ𝑈 ∪ {𝐿(𝒫𝒩 𝑈 ) ∖ 𝐿(𝒫𝒩 )} // add activities not yet in 𝒫𝒩 to Σ𝑈
11 𝒫𝒩 ← 𝒫𝒩 ∪ 𝒫𝒩 𝑈 // extend 𝒫𝒩 (merging same-labeled transitions)
ℛ𝑈 ← {ℛ𝑈 𝑈 𝑈
12 𝑖 |ℛ𝑖 𝑛𝑜𝑡 𝑐𝑎𝑝𝑡𝑢𝑟𝑒𝑑 𝑖𝑛 𝒫𝒩 } // remove relations added to 𝒫𝒩
13 end
14 Σ𝑈 ← Σ𝑈 ∪ {𝐿(ℛ𝑈 ) ∖ 𝐿(𝒫𝒩 )} // if any remaining relations refer to activities not in 𝐿(𝒫𝒩 )
then add these activities to Σ𝑈
15 Σ ← Σ𝑈 ∖ 𝛼 // finished processing 𝛼 (𝛼 now in 𝐿(𝒫𝒩 ))
𝑈
16 end
17 𝒫𝒩 ← {𝒫𝒩 ∪ 𝑝𝑓 | ∙ 𝑝𝑓 = end} // add final place
18 return 𝒫𝒩 // Petri net of activity relations
Given the relations in Fig. 5(b), Algorithm 1 together with the rules outlined in in this section
will precisely reconstruct the the Petri net shown in Fig. 5(a).
2.4. Discovery Results in Multi-Process Setting
To demonstrate the result of Algorithm 1 in multi-process setting, we use a prototype implemen-
tation of our approach (publicly available at: https://github.com/antialman/multi-model-miner/).
For input we use [10] to generate an event log of the concurrent execution of Figs. 5(a), 6(a)
and 6(b). For these models, we note that C2 is present in both Fig. 5(a) and Fig. 6(a), thus making
it a shared activity between the processes. As a result, C2 can only be executed if both C1 and
C3 are not executed. Furthermore, Fig. 6(b) refines this interplay, by specifying that if C3 (in
Fig. 6(a)) is executed then D (in Fig. 5(a)) must be executed afterwards. The process model
discovered by our approach form the generated event log is shown in Fig. 7.
The behavior of the discovered model is correct, and, furthermore, the individual input
processes (Figs. 5(a) and 6(a)) are fairly well recognizable in the resulting model (Fig. 7), especially
when ignoring the artificial start and end events (highlighted by number 1). In that case, the
(a) Additional Petri net. (b) Interplay refinement.
Figure 6: Additional process specifications to demonstrate discovery of hybrid model-sets.
Figure 7: Process model of the concurrent execution of Figs. 5(a), 6(a) and 6(b). Numbers 1–3 highlight
regions that are further discussed in text.
two processes would only be connected by the transition C2 (highlighted by number 2), and the
place 30 (highlighted by number 3). The transition C2 is correctly placed to represent that the
corresponding activity is shared between the input processes. Meanwhile, place 30 represents
the additional interplay refinement Response(C3, D) in Fig. 6(b).
With regards to the latter, it must be noted that there is a silent transition that is connected
to place 30 and does not have any input places. This silent transition is caused by Response(C3,
D) enforcing behavior which matches pattern 4b, without there being any corresponding match
for pattern 4a (i.e., pattern 4b created a silent transition to end optional behavior, but no start
for that optional behavior was created). As a result an unbounded number of tokens can be
produced into place 30, which, while undesirable, does not enable any unintended behavior.
Nevertheless, such cases of declarative behavior are something we plan to handle in the future.
3. Comparison to Contemporary Approaches
In this section we demonstrate that contemporary process discovery approaches are likely to
give incorrect results in our setting, when considering shared activities and other relations
between processes. More specifically, we reuse the event log generated in Section 2.4 for
discovering process models with Flexible Heuristics Miner [11] and Split Miner [12].
The model discovered by Flexible Heuristics Miner (Fig. 8) is relatively close in terms of the
its behavior, but not in terms of structure. The overlapping XOR between B1, B2 and B3, while
difficult to see, is captured correctly. The relation between activities C1, C2, and C3 is also
identified; however, this results in the inability to execute, for example, both C3 and B1 without
deadlocking the model. Furthermore, the interplay relation between C3 and D is not captured.
The Split Miner (Fig. 9) achieves better results, coming fairly close to the structure of the
initial models. The overlapping XOR between B1, B2 and B3 is captured correctly and easy to
see. Also, C3 does lead into D, thus accurately reflecting the corresponding interplay relation.
Figure 8: Flexible Heuristics Miner with default settings.
Figure 9: Split Miner with maximum sensitivity to parallelism and all nodes and arcs displayed.
However, this model has two main drawbacks. First, it is difficult to interpret the gateways and
thus the behavior of the model. For example, the AND-splits after A and C3 seemingly lead to the
same XOR-join. Secondly, the initial input models, while relatively accurately represented, are
also relatively strongly intertwined, making it difficult to disentangle the individual processes.
We also note that, while not presented in this paper, both Flexible Heuristics Miner and Split
Miner performed well when the individual processes did not have shared activities and there
were no interplay refinements (such as Fig. 6(b)) between the processes. In these cases, the
individual processes were discovered as parallel branches of a single larger process model.
4. Current Limitations
The approach presented in this paper has some limitations we plan to tackle as future work.
The most important among these are handling of repetitions and improving tolerance to noise.
Repetitions (i.e., self-loops, short-loops, long-loops) were not considered in this paper, how-
ever, we note that, almost all patterns presented in Section 2.2 be used within larger outer-loops
with little to no adjustments. Furthermore, given that a loop can be viewed as a choice between
executing an iteration or continuing beyond the loop, patterns 2a and 2b will match the entry
and exit points of loops, respectively.
Our approach, as presented in this paper, is likely to be sensitive to noise in the event log. For
example, a single counter example to Succession(A, B) would lead to discovering Co-Existence(A,
B) instead. Here, we could consider adopting the causality measure of Heuristics Miner [13],
but, it would likely require some modifications as it is designed for directly-follows relations.
Finally, the approach could be simplified by using target-branched Declare discovery [14],
which can discover Response and Precedence relations on disjunctions of activities. For example,
in Fig. 5 this would lead to discovering relations such as Response(A, (B1 or B2)), thus making
the discovery of Not Co-Existence(B1, B2) unneeded and simplifying patterns 3a and 3b.
5. Related Work
We are not aware of any approaches that explicitly address business process discovery in
multi-process setting nor that forego the process uniqueness assumption.
However, a similar setting can be found in the context of local processes [15] where the goal is
to discover common (and possibly concurrent) sub-behaviors within one process. Conceptually,
this could be reformulated such that the sub-behaviors to be discovered would instead be seen
as parallel processes, for which the process identifier is missing. However, [15] is not developed
with our setting in mind and, as shown in [16], produces very small models (often 2-3 activities).
In relation to local processes, we also highlight region-based discovery techniques, which
use region theory for discovering characteristic regions that match the behavior seen in the
log. These regions, formulated as Petri nets, represent partial views of the behavior captured in
the log that are integrated to a complete process model [17, 18]. While our approach shares
some mutual ideas with region-based discovery, we rely on Declare discovery and hybrid
semantics providing us the flexibility of representing any relation between (or within) the
processes declaratively, should the relation be difficult to incorporate into a Petri net.
There are also some parallels with multi-agent systems (MAS), where larger systems are
modeled through decentralized decision units referred to as agents. While the focus of MAS is
more on the behavioral rules of the agents rather than the related business processes, there is
some research on integrating MAS with process discovery techniques, e.g., the work in [19].
The combination of Petri nets and Declare is also used in some other hybrid process discovery
approaches, such as [20, 21], however none of them are designed to tackle our setting. For a
broader overview of various hybrid approaches we refer to [22].
It is feasible that the approach presented in this paper, and the discovery of ABPMS framing
in general, could be further enhanced by leveraging additional domain knowledge. This idea
is underexplored thus far, but ontological domain knowledge has been leveraged in process
discovery to, for example, guide event abstraction [23].
Finally, we highlight that a core part of our approach is (partially) transforming (patterns of)
Declare constraints into Petri nets. A more general version of this transformation has already
been explored in the literature, with [24] providing a full lexicon of constructs for Declare
constraints. However, due to the generality of that work, it leads to significantly more complex
Petri net structures, requiring, for example, weighted, reset and inhibitor arcs. We have instead
side-stepped this complexity by considering only a relatively small number of specific patterns
consisting of only a limited set of Declare constraint types.
6. Conclusion
In this paper, we focused on the discovery of ABPMS framing in a multi-process setting. More
specifically, we proposed a process discovery approach that can handle interleaved executions
of multiple processes based on some shared identifier (e.g., patient id). This enables automated
discovery of (at least partial) ABPMS framing based on the activity executions recorded in
non-process-aware systems. The proposed approach makes it possible to discover the individual
processes as well as the relations between them in a single model. While the approach currently
has some limitations related to process repetitions and noise tolerance, we nevertheless believe
it is a solid foundation for future works in the same direction, especially given that, in this
paper, we rely only on the temporal orderings of activities in the given event log.
The next major extension of the work presented in this paper will be incorporating the core
ideas of the recently proposed multi-model paradigm for BPM [25] and the related semantics [10].
In essence, this means the discovery of multiple separate process models (corresponding to
the multi-process setting) from a single event log, together with models defining their interac-
tions. This may be achieved by identifying and adopting suitable graph decompositioning and
clustering techniques to further analyze the current output Petri net. For example, the result
presented in this paper (Fig. 7) could be relatively easily decomposed by identifying a minimal
set of nodes, which, when removed, would make the Petri net graph disjoint. However, further
research in that direction is still required.
In addition, we plan to explore the inclusion of domain knowledge and data perspective in our
approach. This could be used to further guide the process discovery towards better separating
the individual processes. For instance, knowing ontological relations between activities and
which resources execute them may provide hints about the nature of the underlying processes.
Finally, our approach would benefit from an empirical evaluation based on real-life datasets.
Acknowledgments
A. Alman was supported by the Estonian Research Council grant PRG1226. F.M. Maggi was
supported by the UNIBZ project PRISMA.
References
[1] M. Dumas, F. Fournier, L. Limonad, A. Marrella, M. Montali, J. Rehse, R. Accorsi, D. Cal-
vanese, G. De Giacomo, D. Fahland, A. Gal, M. La Rosa, H. Völzer, I. Weber, AI-augmented
business process management systems: A research manifesto, ACM Trans. Manag. Inf.
Syst. 14 (2023) 11:1–11:19.
[2] W. M. P. van der Aalst, Process-aware information systems: Lessons to be learned from
process mining, Trans. Petri Nets Other Model. Concurr. 2 (2009) 1–26.
[3] F. B. Irfan, R. I. G. D. J. Consunji, R. Peralta, A. El-Menyar, L. B. Dsouza, J. M. Al-Suwaidi,
R. Singh, M. Castrén, T. Djärv, G. Alinier, Comparison of in-hospital and out-of-hospital
cardiac arrest of trauma patients in qatar, Int. J. Emerg. Med. 15 (2022) 1–8.
[4] M. Pesic, H. Schonenberg, W. M. P. van der Aalst, DECLARE: full support for loosely-
structured processes, in: EDOC, IEEE Computer Society, 2007, pp. 287–300.
[5] M. de Leoni, P. Felli, M. Montali, A holistic approach for soundness verification of decision-
aware process models, in: ER, volume 11157 of LNCS, Springer, 2018, pp. 219–235.
[6] F. M. Maggi, C. Di Ciccio, C. Di Francescomarino, T. Kala, Parallel algorithms for the
automated discovery of declarative process models, Inf. Syst. 74 (2018) 136–152.
[7] F. M. Maggi, R. P. J. C. Bose, W. M. P. van der Aalst, A knowledge-based integrated
approach for discovering and repairing declare maps, in: CAiSE, volume 7908 of Lecture
Notes in Computer Science, Springer, 2013, pp. 433–448.
[8] W. M. P. van der Aalst, T. Weijters, L. Maruster, Workflow mining: Discovering process
models from event logs, IEEE Trans. Knowl. Data Eng. 16 (2004) 1128–1142.
[9] C. Bron, J. Kerbosch, Finding all cliques of an undirected graph (algorithm 457), Commun.
ACM 16 (1973) 575–576.
[10] A. Alman, F. M. Maggi, M. Montali, A. Rivkin, Generating event logs from hybrid process
models, in: Business Process Management Workshops, volume 492 of Lecture Notes in
Business Information Processing, Springer, 2023, pp. 289–301.
[11] F. Mannhardt, M. de Leoni, H. A. Reijers, W. M. P. van der Aalst, Data-driven process
discovery - revealing conditional infrequent behavior from event logs, in: CAiSE, volume
10253 of Lecture Notes in Computer Science, Springer, 2017, pp. 545–560.
[12] A. Augusto, R. Conforti, M. Dumas, M. La Rosa, A. Polyvyanyy, Split miner: automated
discovery of accurate and simple business process models from event logs, Knowl. Inf.
Syst. 59 (2019) 251–284.
[13] A. J. M. M. Weijters, W. M. P. van der Aalst, Rediscovering workflow models from event-
based data using little thumb, Integr. Comput. Aided Eng. 10 (2003) 151–162.
[14] C. Di Ciccio, F. M. Maggi, J. Mendling, Discovering target-branched declare constraints,
in: BPM, volume 8659 of Lecture Notes in Computer Science, Springer, 2014, pp. 34–50.
[15] N. Tax, N. Sidorova, R. Haakma, W. M. P. van der Aalst, Mining local process models, J.
Innov. Digit. Ecosyst. 3 (2016) 183–196.
[16] M. Brunings, D. Fahland, B. F. van Dongen, Defining meaningful local process models,
Trans. Petri Nets Other Model. Concurr. 16 (2022) 24–48.
[17] J. Carmona, Projection approaches to process mining using region-based techniques, Data
Mining and Knowledge Discovery 24 (2012) 218–246.
[18] M. Solé, J. Carmona, Region-based foldings in process discovery, IEEE Transactions on
Knowledge and Data Engineering 25 (2011) 192–205.
[19] R. H. Bemthuis, M. Koot, M. R. K. Mes, F. A. Bukhsh, M. Iacob, N. Meratnia, An agent-based
process mining architecture for emergent behavior analysis, in: EDOC Workshops, IEEE,
2019, pp. 54–64.
[20] J. De Smedt, J. De Weerdt, J. Vanthienen, Fusion miner: Process discovery for mixed-
paradigm models, Decis. Support Syst. 77 (2015) 123–136.
[21] F. M. Maggi, T. Slaats, H. A. Reijers, The automated discovery of hybrid processes, in:
BPM, volume 8659 of Lecture Notes in Computer Science, Springer, 2014, pp. 392–399.
[22] A. A. Andaloussi, A. Burattin, T. Slaats, E. Kindler, B. Weber, On the declarative paradigm
in hybrid business process representations: A conceptual framework and a systematic
literature study, Inf. Syst. 91 (2020) 101505.
[23] S. Montani, G. Leonardi, M. Striani, S. Quaglini, A. Cavallini, Multi-level abstraction for
trace comparison and process discovery, Expert Syst. Appl. 81 (2017) 398–409.
[24] J. De Smedt, S. vanden Broucke, J. Weerdt, J. Vanthienen, A Full R/I-net Construct Lexicon
for Declare Constraints, Technical Report, KU Leuven, 2015.
[25] A. Alman, F. M. Maggi, S. Rinderle-Ma, A. Rivkin, K. Winter, Towards a multi-model
paradigm for business process management, in: CAiSE, volume 14663 of Lecture Notes in
Computer Science, Springer, 2024, pp. 178–194.