1212 lines
138 KiB
Plaintext
1212 lines
138 KiB
Plaintext
Computer Standards & Interfaces 97 (2026) 104108
|
||
|
||
|
||
Contents lists available at ScienceDirect
|
||
|
||
|
||
Computer Standards & Interfaces
|
||
journal homepage: www.elsevier.com/locate/csi
|
||
|
||
|
||
|
||
|
||
A requirement-driven method for process mining based on model-driven
|
||
engineering
|
||
Selsabil Ines Bouhidel a ,∗,1 , Mohammed Mounir Bouhamed b ,1 , Gregorio Diaz c ,∗,1 ,
|
||
|
||
Nabil Belala a ,1
|
||
a
|
||
MISC Laboratory, University of Abdelhamid Mehri Constantine 2, Constantine 25016, Algeria
|
||
b LIAP Laboratory, University of El Oued, P.O. Box 789, El Oued, 39000, Algeria
|
||
c Instituto de Investigación en Informática, Escuela Superior de Ingeniería Informática, Universidad de Castilla-La Mancha, 02071 Albacete, Spain
|
||
|
||
|
||
|
||
|
||
ARTICLE INFO ABSTRACT
|
||
|
||
Dataset link: 10.17632/s7rjw8nnvm.2 Process mining analyzes business processes using event logs. Existing tools generate models to facilitate
|
||
this task and improve the original business process, but the results are often unsatisfactory due to the
|
||
Keywords:
|
||
complexity of the obtained models. Among the challenges faced in this context, we identify the misalignment
|
||
Process mining
|
||
Data science
|
||
with specific business requirements, preventing managers from accessing key data and making effective
|
||
Meta-modeling decisions. In this paper, we propose a requirement-driven approach centered on meta-modeling, which can
|
||
Business process management help the development of process mining tools specially tailored to organizational needs. Thus, we introduce a
|
||
requirement-driven method to address the critical challenge of model misalignment with required information.
|
||
The method employs Model-Driven Engineering to simplify how process mining results are formulated,
|
||
analyzed, and interpreted. The proposed method is iterative and involves several steps. First, a service manager
|
||
defines a specific business question. Second, service managers and developers collaboratively establish a
|
||
meta-model representing the target data. Third, developers extract relevant data using appropriate analysis
|
||
techniques and visualize it. Finally, service managers and developers jointly interpret these visualizations
|
||
to inform strategic decisions. This requirement-driven methodology empowers developers to concentrate
|
||
on relevant information. Unlike general-purpose frameworks (e.g., ProM, Disco), this method emphasizes
|
||
specificity, iterative refinement, and close stakeholder collaboration. By reducing cognitive overload through
|
||
focused modeling and filtering of irrelevant data, organizations adopting this approach can achieve faster
|
||
response times to business questions and develop specialized in-house analytical tools. This requirement-
|
||
driven methodology, therefore, improves decision-making capabilities within process mining and across related
|
||
analytical domains. We illustrate our methodology through a real business process taken from the literature
|
||
owned by the VOLVO group. We use several examples of process mining to illustrate the benefits of the
|
||
proposed methodology compared to existing tools which are unable to provide the required information.
|
||
|
||
|
||
|
||
1. Introduction Process Management (BPM) market was valued at USD 16.73 billion in
|
||
2025 and is expected to reach USD 29.26 billion by 2030. This growth,
|
||
Process mining has emerged as a pivotal discipline within data at an 11.83% Compound Annual Growth Rate, is driven by advances in
|
||
science and business process management, enabling organizations to artificial intelligence integration, cloud computing, and robotic process
|
||
discover, monitor, and enhance operational processes by analyzing automation [3]. Similarly, the Business Process Outsourcing (BPO)
|
||
event logs [1]. In this context, an event log is a record of the execution market reached USD 302.62 billion in 2024 and is expected to attain
|
||
of activities within a Business Process (BP). The importance of process USD 525.23 billion by 2030, representing a CAGR of 9.8% over the
|
||
mining is underscored by two key points: the size of the business market same period [4].
|
||
and the necessity to adapt BPs periodically to meet evolving business
|
||
Process models are central to achieving these business improve-
|
||
requirements [2]. Projected market growth further highlights the global
|
||
ments. Often based on Petri nets [5] or Business Process Model and
|
||
relevance of effective business processes. For example, the Business
|
||
|
||
|
||
∗ Corresponding authors.
|
||
E-mail addresses: selsabil.bouhidel@univ-constantine2.dz (S.I. Bouhidel), bouhamed-mohammedmounir@univ-eloued.dz (M.M. Bouhamed),
|
||
gregorio.diaz@uclm.es (G. Diaz), nabil.belala@univ-constantine2.dz (N. Belala).
|
||
1
|
||
Researcher.
|
||
|
||
https://doi.org/10.1016/j.csi.2025.104108
|
||
Received 22 July 2025; Received in revised form 17 October 2025; Accepted 28 November 2025
|
||
Available online 4 December 2025
|
||
0920-5489/© 2025 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY license (http://creativecommons.org/licenses/by/4.0/).
|
||
S.I. Bouhidel et al. Computer Standards & Interfaces 97 (2026) 104108
|
||
|
||
|
||
Notation (BPMN) [6], such models offer critical insight for perfor- organizations can balance flexibility and sustainability when selecting
|
||
mance optimization, compliance verification, and strategic planing. As between generic and requirement-specific analytical solutions.
|
||
a result, organizations across various sectors are increasingly adopting The paper is organized in seven additional sections, where Sec-
|
||
process mining techniques to improve operational efficiency, ensure tion 2 provides background information on process mining and meta-
|
||
regulatory compliance, and drive data-informed decisions. modeling. Section 3 reviews related work in the field. Section 4 in-
|
||
Despite growing adoption and development of sophisticated tech- troduces the running example used throughout this paper. Section 5
|
||
niques, process mining still faces notable challenges. Chief among them, details the proposed methodology. Section 6 presents practical exam-
|
||
as regarded by the literature, is the absence of standardized evaluation ples illustrating the application of the developed method. Section 7
|
||
criteria for process mining algorithms [7]. In addition, current tools discusses the implications and limitations of the presented approach.
|
||
often produce complex and unwieldy process models [8], complicating Finally, Section 8 concludes the paper with key findings and directions
|
||
the selection of methods suitable for specific organizational settings. for future research.
|
||
While powerful, existing process mining tools frequently gener-
|
||
ate overly detailed models that are difficult to interpret [9]. This 2. Background
|
||
issue becomes particularly acute when addressing diverse and evolving
|
||
business needs. Recent developments—such as precision-guided dis- This section introduces the background to the concepts used in this
|
||
covery [10] and improved algorithms for handling noisy or complex work. Specifically, it focuses on process mining, the event log structure
|
||
logs [11] have made progress. Yet, the issue of overcomplexity persists. utilized in process mining, and meta-modeling.
|
||
Furthermore, many widely used frameworks (e.g., ProM [12],
|
||
Disco [13]), are too broad or inflexible to meet the needs of organi- 2.1. Process mining
|
||
zations with specific or evolving analytical requirements [1]. These
|
||
general-purpose frameworks, designed for a wide array of scenar- Process Mining (PM) is a discipline that extracts knowledge from
|
||
ios, may fall short in terms of adaptability and usability to spe- event logs generated by information systems to discover, monitor, and
|
||
cific operational needs, leading to inefficiencies in both analysis tool improve real-world processes. As established by [1], Process Mining
|
||
development. combines methodologies from business process management, business
|
||
This paper presents a novel requirement-driven process mining analysis, and data mining. The field comprises three main phases:
|
||
method to address two critical limitations in current practice of process discovery, conformance checking, and model enhancement [1]. Fig. 1
|
||
mining: the generation of excessively complex models and the inflexi- illustrates these core phases.
|
||
bility of general-purpose tools for specific organizational requirements. Event logs are essential for Process Mining. These logs record se-
|
||
Our approach builds on the principles of Model-Driven Engineering quences of process steps, grouping related events into cases (process
|
||
(MDE) [14,15] and shifts the paradigm from adapting pre-built tools instances). Logs typically include timestamps, resource information,
|
||
towards the construction of lightweight, customized analytical solu- and other contextual data (See Fig. 2).
|
||
tions. In this framework, specific business questions and organizational Using event logs, Process Mining techniques model process flow,
|
||
requirements directly guide the development of these solutions. The capture process variants and deviations, and quantify performance
|
||
methodology detailed herein utilizes meta-models to precisely define metrics such as cycle time, throughput, and quality [1]. Process Min-
|
||
the necessary data and analytical scope, facilitating the development of ing commonly uses models such as Petri nets, BPMN diagrams, and
|
||
focused, in-house tools able to deliver actionable insights and support Directly-Follow Graphs (DFG) [1].
|
||
more effective decision-making. The key operations of these three techniques are described as fol-
|
||
The main contributions of this paper are: lows [1]:
|
||
|
||
1. A requirement-driven meta-modeling strategy that systemati- • Process Discovery (PD): extracts models from event logs by an-
|
||
cally integrates organizational objectives and stakeholder expec- alyzing event sequences, timestamps, and instances. These mod-
|
||
tations into the process mining pipeline. This integration aims to els are derived directly from data, without any predefined de-
|
||
ensure that discovered process models are not only accurate but scriptions. They reconstruct actual process behavior and reveal
|
||
also contextually meaningful and interpretable. deviations from prescribed designs.
|
||
2. An iterative methodology for the cost-effective development of • Conformance Checking (CC): is a core technique in process
|
||
customized in-house process mining tools. This methodology mining. It compares event logs against a process model to detect
|
||
empowers organizations to build specialized analytical assets, deviations, such as missing, additional, or incorrectly ordered
|
||
enhancing agility and enabling more precise data extraction and activities.
|
||
analysis. • Model enhancement: is the process of enhancing as business
|
||
3. Several process mining examples, based on a real business pro- process based on what is discovered in process discovery and
|
||
cess from the VOLVO Group, are provided to illustrate our conformance checking. It repair incorrect models and address
|
||
approach. The dataset and accompanying analysis notebook are performance bottlenecks.
|
||
available at the following public repository2
|
||
The discovery of business process models using existing process
|
||
The presented approach aims to improve the overall utility and mining tools typically produces large and complex artifacts. While these
|
||
effectiveness of process mining applications by emphasizing specificity models contain the data to answer a service manager’s operational
|
||
and iterative refinement. These improvements ultimately foster more questions, they often fail to make this information accessible in prac-
|
||
informed and impactful strategic decisions within organizations. tice. This fundamental disconnect reveals that standard tools are not
|
||
Finally, the proposed method deliberately involves developers inherently requirement-oriented.
|
||
within each iteration cycle. This design choice enables a transparent
|
||
cost–benefit evaluation: the development effort represents a measur- 2.2. Meta-modeling in model-driven engineering
|
||
able investment comparable to commercial tool licensing. As such,
|
||
MDE uses models to design and develop complex systems. MDE
|
||
provides specialized tools and languages to automate many develop-
|
||
2
|
||
Bouhidel, Selsabil Ines; Bouhamed, Mohammed Mounir; Diaz, Gregorio; ment steps, replacing traditional manual methods. This automation and
|
||
Belala, Nabil (2025), ’’A requirement driven process mining Dataset’’, Mendeley abstraction enable developers to work at a higher level, significantly
|
||
Data, V2, doi: 10.17632/s7rjw8nnvm.2. improving productivity, consistency, and maintainability [16].
|
||
|
||
2
|
||
S.I. Bouhidel et al. Computer Standards & Interfaces 97 (2026) 104108
|
||
|
||
|
||
|
||
|
||
Fig. 1. The relation between the types of PM [1].
|
||
|
||
|
||
|
||
|
||
Fig. 2. Representative Structure of an Event Log [1].
|
||
|
||
|
||
Models are central to MDE. They simplify a system by capturing needs, model comprehensibility, scalability, and decision-making sup-
|
||
essential aspects for analysis and prediction. Crucially, models serve as port. This framework facilitates a structured comparison that positions
|
||
the primary means of communication among stakeholders [14]. Models the proposed method against existing literature, moving beyond a
|
||
abstract systems by removing irrelevant details, managing complexity purely descriptive review. While a full numerical benchmark is beyond
|
||
through decomposition, and predicting system behavior. the scope of this study, this qualitative analysis serves to highlight the
|
||
Meta-models structure models, defining their concepts, relation- specific novelty of the proposed approach.
|
||
ships, and constraints. Every model must adhere to its meta-model. Process discovery and conformance checking extensively use Petri
|
||
While a model represents a system, its meta-model represents the nets. The ProM framework [12] demonstrates Petri nets’ effective-
|
||
language or framework used to build it. This hierarchy can extend to ness in capturing concurrency and synchronization. Van der Aalst
|
||
meta-meta-models, which define rules for meta-models. Meta-modeling et al. [5,24] have shown that Petri nets offer formal advantages for
|
||
ensures consistency and provides a formal basis for model construc- workflow verification. Petri nets serve as a design language for com-
|
||
tion [14]. plex workflows and provide powerful analysis techniques to verify
|
||
MDE leverages models as central artifacts, meta-models to provide workflow correctness. However, applying Petri nets to large-scale or
|
||
structure and formal basis, and precisely defined modeling languages dynamic event logs can generate overly complex models that are dif-
|
||
to enable automation. MDE supports an iterative, platform-independent ficult to interpret and manage. Event-centric approaches such as the
|
||
development process, enhancing productivity and simplifying complex Event Relationship Graph proposed by [22] also address this issue
|
||
system management. by automating digital-twin generation, although applicability beyond
|
||
specific manufacturing scenarios remains limited.
|
||
Meta-modeling could guide developers in creating solutions that can
|
||
Several recent methods partially mitigate this complexity issue. For
|
||
effectively extract required information on demand. All changes are
|
||
example, the enhanced eST-Miner [10]. The Alpha+++ algorithm [11]
|
||
added to the background section.
|
||
focus on avoiding implicit places, improving precision, and support-
|
||
ing the structured discovery of concurrent processes. The Alpha+++
|
||
3. Related works algorithm extends the original Alpha algorithm by addressing noise,
|
||
loops, and skips, and improving the discovery of control-flow struc-
|
||
Process mining significantly advances process discovery, confor- tures. Consequently, the resulting models are often less complex; how-
|
||
mance checking, and enhancement. Researchers have explored various ever, they may still overlook important aspects related to require-
|
||
approaches to identify process models from event logs. However, mod- ments. Another approach, [23] leverages statistical techniques, CUSUM
|
||
els are often large, complex, and difficult to interpret. They typically and EWMA charts, to perform distribution-free anomaly detection, yet
|
||
reflect a broad process view, which results in a lack of accuracy, their practical implementation primarily relies on controlled simulation
|
||
specificity, and clarity. environments.
|
||
This section systematically evaluates key studies to identify their Similarly, hierarchical approaches use abstraction to discover multi-
|
||
respective contributions and limitations, which are summarized in level models from activity trees, such as FlexHMiner [17]. These ap-
|
||
Table 1. The evaluation adopts a requirement-oriented perspective, proaches effectively manage subprocess interleaving and enhance scal-
|
||
applying several systematic criteria: the extracted information, the ability. Nevertheless, aligning these models with detailed stakeholder
|
||
tool used, is the approach consider new question based on business requirements remains challenging, despite improving interpretability.
|
||
|
||
3
|
||
S.I. Bouhidel et al. Computer Standards & Interfaces 97 (2026) 104108
|
||
|
||
|
||
Table 1
|
||
PM approaches.
|
||
Reference Modeling tool Extracted model information Tool used Considering Comprehensibility Scalability Decision-making
|
||
new questions support
|
||
Augusto et al. BPMN Control-flow patterns with Split Miner no Moderately Scalable for moderate Basic operational
|
||
[8] balanced fitness and precision comprehensible data volumes, but insights only
|
||
limited for large logs
|
||
Leno et al. [9] Declarative Correlated data conditions and Custom Framework no Lower, declarative Limited scalability Weak, rule-based
|
||
Models refined rules models are harder to depending on complexity decision support
|
||
interpret
|
||
Lu et al. [17] Activity Trees Hierarchical process modeling ProM no Moderate, hierarchy Scales with hierarchy Provides structural
|
||
for multi-level subprocesses adds complexity depth insights only
|
||
Augusto et al. BPMN Concurrency and inclusive Split Miner no Good, BPMN is Scalable for moderate Surface-level decision
|
||
[18] decision patterns readable data volumes, but support
|
||
limited for large logs
|
||
Tiftik et al. BPMN Control-flow, data, and ProM no Good Scalable with tool Decent support,
|
||
[19] resource perspectives comprehensibility via constraints cross-perspective
|
||
holistic view
|
||
Aalst [20] BPMN, Petri Process improvement and ProM no Moderate, learning Scalable due to flexible Moderate, compliance
|
||
Nets, Process compliance curve with multiple tools aids decisions
|
||
Trees formalisms
|
||
Groß et al. Petri Nets Implicit places and structural eST-Miner no Lower; Petri Nets are Scalable in static settings Weak decision
|
||
[10] accuracy aspects less intuitive only support
|
||
Kusters and Petri Nets Concurrency, loops, noise ProM no Lower, handles High scalability for noisy Some support via
|
||
van der Aalst filtering, and structured complexity real data noise filtering
|
||
[11] control-flow modeling for
|
||
real-life process discovery
|
||
Saraeian and Uncertain BPMS Event-based anomaly detector A BPMS extension no Low, uncertainty Moderate scalability, Moderate
|
||
Shirazi [21] (pre-processor, conformance hard to interpret tool-dependent anomaly-driven
|
||
checker, optimizer with IPSO, decisions
|
||
Firefly, AdaBoost)
|
||
Castiglione Event Automated generation of An event-centric miner no High for domain Highly scalable event Strong automated
|
||
[22] Relationship manufacturing digital-twin experts data processing decision paths
|
||
Graph models via 3EM discovery
|
||
Mukherjee CUSUM/EWMA Distribution-free anomaly Custom simulation no Moderate Scalable for process Good in anomaly
|
||
et al. [23] control charts detection via WRS and HFR experiments control scenarios contexts
|
||
statistics
|
||
|
||
|
||
|
||
Kalenkova et al. [6] showed that BPMN is recognized for its read- While existing techniques advance process discovery, they often
|
||
ability and alignment with business practices. BPMN supports creating produce models lacking contextual significance. Furthermore, aligning
|
||
conventional, understandable process models. In addition to its flat these models with stakeholder requirements and organizational goals
|
||
control-flow perspective, BPMN integrates subprocesses, data flows, demands additional mechanisms. Data-driven and behavior-driven sys-
|
||
and resources. This integration facilitates stakeholder communication tems, in particular, prioritize data patterns over explicit requirements
|
||
within a single diagram. These characteristics make BPMN attractive or constraints.
|
||
for process miners and business users. Recent advancements enhance The requirement-based meta-modeling approach addresses these
|
||
BPMN discovery by identifying true concurrency and inclusive choices, limitations and effectively tackles the complexity challenge. By ex-
|
||
resulting in accurate, flexible models, such as Split Miner 2.0 [18]. plicitly integrating stakeholder requirements, this approach ensures
|
||
However, BPMN models often struggle with adapting to evolving re- models remain actionable, intelligible, and well-aligned with real-world
|
||
quirements, tending to be rigid and potentially not fully capturing processes. This approach also reduces model size and yields represen-
|
||
dynamic business needs. tations that are more adaptable, precise, and easier to maintain.
|
||
Data-driven approaches constitute another category. For instance, The literature provides established criteria for quantitatively evalu-
|
||
the Alpha Miner algorithm analyzes event log patterns to reconstruct ating the complexity and quality of discovered process models. These
|
||
process models [24]. The Alpha Miner predicts the amount of data indicators quantify the trade-off between model simplicity and behav-
|
||
needed for mining based on observed substructures and algorithm ioral accuracy. For instance, structural metrics assess properties such
|
||
behavior. This prediction allows efficient data utilization and quantifies as the number of places, transitions, and arcs in a Petri net, alongside
|
||
confidence [7]. Additionally, Leno et al. [9] introduced methods to formal properties like soundness, to verify workflow correctness [11,
|
||
enhance declarative discovery by incorporating correlated data condi- 27]. Other structural approaches, such as cyclomatic complexity, quan-
|
||
tions. These methods utilize clustering, rule mining, and re-description tify the control-flow to identify potential modeling challenges and
|
||
mining to improve rule precision. Further, an event-based anomaly error risks [21]. In parallel, behavioral metrics rely on conformance
|
||
detection method [21]integrate a extension of BPMS and utilize ad- checking techniques to compare a model against an event log [24].
|
||
vanced optimization techniques (IPSO, Firefly) and ensemble learning These techniques compute fitness, which measures how well a model
|
||
(AdaBoost) but might add complexity to process mining systems. reproduces observed behavior, and precision, which measures the ex-
|
||
Behavior-driven approaches discover deviations from usual behav- tent to which it permits unobserved behavior. Recent work combines
|
||
iors [25]. For instance, the ILP Miner [26] uses Integer Linear Program- these structural and behavioral indicators to guide model simplifica-
|
||
ming to enhance precision. Similarly, Split Miner [8] balances fitness, tion while preserving interpretability and alignment with stakeholder
|
||
accuracy, and simplicity, producing behaviorally accurate, straightfor- requirements.
|
||
ward models while avoiding spaghetti-like structures. Despite the availability of these metrics, scalability remains a crit-
|
||
Multi-perspective process mining integrates control-flow, data, and ical challenge. Larger, more intricate process models inherently yield
|
||
resource perspectives into a unified BPMN model. This integration higher complexity scores, which hinder their practical usability without
|
||
enhances complex process representation, as exemplified by frame- effective abstraction or hierarchical decomposition techniques. This
|
||
works such as the one proposed in [19]. Additionally, the Process reality establishes a dual purpose for these metrics in process mining:
|
||
Mining Handbook [20] provides an overview of techniques including they not only serve as tools for evaluating final model quality but also
|
||
discovery, conformance checking, and enhancement. These techniques act as essential guides for the iterative improvement and simplification
|
||
are essential for understanding and improving operational processes. of process models.
|
||
|
||
4
|
||
S.I. Bouhidel et al. Computer Standards & Interfaces 97 (2026) 104108
|
||
|
||
|
||
ProM [12] and Disco [13] are widely used tools for implementing 4.1. Original data
|
||
process mining techniques. ProM is a versatile open-source platform
|
||
supporting various plugins. However, ProM requires improved handling The VINST event log dataset, as described by [29], contains 15
|
||
of large event logs and enhanced scalability [27]. Disco, presented by distinct attributes. Table 2 presents the first 10 event logs from this
|
||
Fluxicon, offers an intuitive interface and powerful visualization. De- dataset. Each incident is identified by a unique serial (SR) number.
|
||
spite these strengths, both tools often require customization to address Multiple workers or owners may address an incident within a support
|
||
specific challenges. team, and numerous log records track status and ownership changes
|
||
Custom tools attempt to address scalability but may still sacrifice until resolution [29].
|
||
usability, such as those introduced by Marlon Dumas et al. [28]. According to [29], the dataset records include details such as serial
|
||
In summary, while approaches such as Petri Nets, BPMN, data- number (identifying the service request), timestamp, case status, and
|
||
driven, and behavior-driven methods contribute to process mining, sub-status, business impact, product, support country, case owner,
|
||
they face challenges. These challenges include complexity, rigidity, support team, and organizational line (Table 2). The ‘‘owner’’ attribute
|
||
and issues related to contextual relevance and alignment with business identifies the task owner; two successive logs with the same SR but dif-
|
||
requirements. ferent owners indicate a work transfer. The full dataset comprises 7554
|
||
incidents and 65,553 events, averaging 8.7 events per incident [29].
|
||
|
||
4. Running example 4.2. Processed data
|
||
|
||
This section uses the VOLVO3 Incident maNagement SysTem We preprocessed the raw VINST data for analysis. First, we cal-
|
||
(VINST) as a running example to illustrate the process mining approach culated activity durations for each event (e.g., 7 days, 14:16:03) to
|
||
developed in this study. The VINST dataset, documented by [29], enable temporal analysis. Next, we included only completed activities
|
||
highlights the complexities inherent in real-world incident management to focus on full process instances. We then extracted group names
|
||
systems. It features a rich event structure and diverse incident types, (e.g., ‘‘V13’’) and support lines (1st, 2nd, 3rd) from the ‘‘group line’’
|
||
making it an ideal case for evaluating the proposed method. VOLVO column, providing key attributes for organizational analysis. Finally,
|
||
IT service, aka VOLVO IT, utilizes VINST [30] to manage incidents we removed unnecessary columns to streamline the dataset. These
|
||
affecting VOLVO product lines, including equipment breakdowns, qual- steps ensured the data was suitable for our subsequent process mining
|
||
ity control issues, supply chain disruptions, accidents, and regulatory analysis.
|
||
changes. These incidents significantly impact production efficiency and
|
||
operations. For instance, breakdowns halt production, quality issues 5. Proposed solution
|
||
require rework, and supply disruptions cause delays. The VINST dataset
|
||
includes event logs recorded from March 2010 to May 2012 [29]. This section presents a new requirement-driven method based on
|
||
VOLVO IT established an incident management system [29] to a model-driven engineering approach designed to address two key
|
||
address these issues. This system defines roles and responsibilities for challenges in process mining: selecting appropriate algorithms and
|
||
resolving incidents promptly and efficiently. As described by [29], the managing the variability of resulting models. First, we summarize the
|
||
process begins by determining whether the reported issue qualifies as proposal, and we then present each step of our approach.
|
||
an incident (see Fig. 3), which can be reported either manually or
|
||
automatically. If it is not considered an incident, it is handled through 5.1. Overview
|
||
other service desk routines. If confirmed as an incident, it is registered
|
||
and classified by the first-line support, comprising various help desks This subsection provides an overview of the proposed five-step iter-
|
||
(e.g., service desk, front desk, offline desk, desk-side support) as well as ative method for process mining (see Fig. 4). The method guides service
|
||
expert help desks. An attempt is then made to match the incident with managers and developers in mining and analyzing Business Processes
|
||
an existing solution. If a solution is identified, the incident is resolved (BPs) and their running instances. It also supports them in developing
|
||
and closed. If not, it is further investigated at the same level. If the first in-house process mining tools. Currently, no standard method exists for
|
||
line cannot resolve the incident, it is escalated to the second line of assessing and comparing process mining algorithms. Furthermore, ex-
|
||
support, which conducts its own investigation and resolution attempt. isting tools often produce large, highly variable models that complicate
|
||
The second-line support typically involves teams within Organization their use in statistical analysis for managerial decision-making.
|
||
Line C or A2 [29]. If resolution is still not achieved, the incident This approach supplements existing tools by establishing a company
|
||
is escalated to third-line support for deeper analysis. The third-line -specific library. This library helps provide tailored answers to specific
|
||
business questions.
|
||
support usually consists of product experts, who are often also part
|
||
The proposed method involves five iterative steps:
|
||
of Organization Line C or A2, and handle incidents unresolved by
|
||
the second-line support [29]. At each support level (1st, 2nd, or 3rd • The service manager asks a question regarding the BP.
|
||
line), if the incident cannot be resolved internally and requires external • The developer describes the targeted data as a meta-model.
|
||
expertise, it is forwarded to the supplier’s support. Supplier support • The developer extracts the data using data analysis tools.
|
||
investigates the issue and may return it for internal resolution once
|
||
• The service manager visualizes the results using a visualization
|
||
a solution is identified. A Support Team (ST) is assigned at each step library, with the developer’s help.
|
||
of the process to handle activities such as classification, investigation, • The service manager interprets the results to answer the question
|
||
matching, resolution, or escalation. and make decisions.
|
||
Once a resolution is found at any level, the case owner verifies the
|
||
outcome before closing the incident. This structured approach aims to The method is iterative: if the service manager is unsatisfied with
|
||
ensure efficient incident handling, minimize operational impact, and the results, they initiate a new iteration by asking a new question.
|
||
enhance client satisfaction [29]. Service managers initiate process mining when BP analysis is
|
||
needed. They first consider existing frameworks, such as ProM and
|
||
Disco, and any tools already developed in-house. If these tools satisfy
|
||
3
|
||
The VOLVO Group is a Swedish multinational manufacturing corporation their requirements, they use them. Otherwise, they follow the proposed
|
||
specialized in producing trucks, buses, and construction equipment. method to develop a new in-house tool, thus expanding their collection.
|
||
|
||
5
|
||
S.I. Bouhidel et al. Computer Standards & Interfaces 97 (2026) 104108
|
||
|
||
|
||
|
||
|
||
Fig. 3. Support Organization Structure.
|
||
Source: Adapted from [29].
|
||
|
||
|
||
|
||
|
||
Table 2
|
||
Table of the first 10 records from the event log.
|
||
Case ID Activity Resource Complete Variant Variant Concept: Impact Lifecycle: Org: Org: Org Org Product Resource
|
||
timestamp index name transition group role country involve country
|
||
Case 1 Accepted- Value 1 2006/01/11 Variant 77 77 Queued High Awaiting Org A2_2 se J11 2nd PROD191 INDIA
|
||
In Progress 23:49:42 Assignmenr line A2
|
||
Case 1 Accepted- Value 1 2012/03/15 Variant 77 77 Accepted High In Progress Org A2_2 se J11 2nd PROD191 INDIA
|
||
Assigned 19:53:52 line A2
|
||
Case 1 Accepted- Value 1 2012/03/15 Variant 77 77 Accepted High Assigned Org A2_2 se J11 2nd PROD191 INDIA
|
||
Assigned 19:56:17 line A2
|
||
Case 1 Accepted- Value 1 2012/03/15 Variant 77 77 Accepted High In Progress Org A2_2 se J11 2nd PROD191 INDIA
|
||
In Progress 20:09:05 line A2
|
||
Case 1 Completed- Value 1 2012/03/15 Variant 77 77 Accepted High Closed Org A2_2 se J11 2nd PROD191 INDIA
|
||
Closed 20:11:33 line A2
|
||
Case 2 Accepted- Value 2 2006/11/07 Variant 78 78 Accepted Medium IN Progress Org A2_2 cn M1 2nd PROD753 Sweden
|
||
In Progress 18:00:36 line A2
|
||
Case 2 Accepted- Value 2 2006/11/07 Variant 78 78 Accepted Medium In Progress Org A2_2 cn M1 2nd PROD753 Sweden
|
||
In Progress 21:05:44 line A2
|
||
Case 2 Accepted- Value 2 2009/12/02 Variant 78 78 Accepted Medium Wait Org A2_2 cn M1 2nd PROD753 Sweden
|
||
Wait 22:24:32 line A2
|
||
Case 2 Accepted- Value 2 2011/09/03 Variant 78 78 Accepted Medium In Progress Org A2_2 cn M1 2nd PROD753 Sweden
|
||
In Progress 14:09:09 line A2
|
||
Case 2 Accepted- Value 3 2012/01/20 Variant 78 78 Accepted Medium In Progress Org A2_2 cn M1 2nd PROD753 China
|
||
In Progress 18:23:24 line A2
|
||
|
||
|
||
|
||
|
||
This need arises because the limited availability of specialized process small, focused tools, which helps reduce development costs compared
|
||
mining tools often necessitates developing custom solutions. Therefore, to adding features to large, general frameworks like ProM and Disco,
|
||
the proposed method provides essential guidance for service managers which target a wide range of processes and questions.
|
||
and software developers throughout the process mining lifecycle. Developers use meta-modeling to specify the data needed for a
|
||
The method’s primary benefit is that it enables service managers to specific question. This helps them focus on extracting only the required
|
||
answer specific BP questions when no existing tool can help. It also data, avoiding the time and resources needed to gather unnecessary
|
||
facilitates building an internal library of tools for future analysis of information. It also helps the service manager focus on the relevant
|
||
the same or similar questions. This approach encourages developing data, reducing distractions from irrelevant details.
|
||
|
||
6
|
||
S.I. Bouhidel et al. Computer Standards & Interfaces 97 (2026) 104108
|
||
|
||
|
||
|
||
|
||
Fig. 4. Process mining steps.
|
||
|
||
|
||
5.2. Step 1: Define the question understand the analyzed data. The developer then presents these visu-
|
||
alizations to the service manager for analysis and interpretation in Step
|
||
In the first step, the service manager investigates the company’s 5.
|
||
BP to identify areas for improvement. They use natural language ques-
|
||
tioning techniques to gather information and prepare specific questions 5.6. Step 5: Interpret results and make decisions
|
||
about the process, facilitating clear communication with all stakehold-
|
||
ers. The service manager then analyzes this information to pinpoint In this final step, the service manager interprets the visualizations
|
||
specific issues. provided by the developer. The service manager then presents these
|
||
Inquiry questions typically include both quantitative and qualitative results to the client, highlighting key patterns and trends. Using these
|
||
types. Examples include: visuals, the service manager answers the client’s questions and explains
|
||
• What is the average, minimum, and maximum time to complete the findings clearly, enabling the client to make informed decisions.
|
||
cases? If the client is dissatisfied with the results, the service manager notes
|
||
• What is the average service time for each task? their feedback and generates a more detailed inquiry. The service man-
|
||
• How much time is spent between tasks in the process? ager forwards this inquiry to the developer for additional processing,
|
||
• How many people are involved in each case? restarting the method from Step 1. Notably, the developer can often
|
||
• What is the communication structure and interdependencies refine the data they are already using rather than requiring new data
|
||
among people? extraction, making the process quicker and more flexible.
|
||
• How many transfers occur from one role to another? Once the client is content with the results, the developer incorpo-
|
||
• Who are the most important people in the communication flow? rates the analysis and its resolution into the in-house tool.
|
||
• Who works on the same tasks?
|
||
6. Examples
|
||
5.3. Step 2: Specify the meta-model
|
||
This section presents real-world case studies to illustrate our pro-
|
||
As the second step, the developer creates a meta-model to describe
|
||
posed requirement-driven method, which is based on model-driven
|
||
the structure and key features of the target data. This involves selecting
|
||
engineering. These case studies demonstrate the method application
|
||
data sources, such as event logs, and defining the data structure. A
|
||
for addressing specific business questions and supporting tool devel-
|
||
meta-model simplifies complex data into a high-level overview, high-
|
||
opment. We chose this descriptive approach over a complete empirical
|
||
lighting its attributes and relationships. This simplification is crucial
|
||
benchmark for three reasons. First, our primary goal is to introduce and
|
||
for understanding the data structure and identifying gaps or inconsis-
|
||
demonstrate the method. Second, a full empirical benchmark would
|
||
tencies, which is essential for accurate data analysis and visualization
|
||
require datasets, tools, and resources beyond the scope of this study.
|
||
in the following steps.
|
||
Third, because our method is requirement-specific, quantitative com-
|
||
parisons with general-purpose tools would be misleading. We there-
|
||
5.4. Step 3: Extract the data
|
||
fore provide transparent and reproducible descriptive analyses and
|
||
After the developer describes the target data as a meta-model, they explicitly report their limitations.
|
||
extract the necessary data from the data source or event log. This
|
||
involves using data analysis tools to explore and manipulate the data. 6.1. Example 1: Products are escalated to the third line
|
||
The choice of tools depends on the data’s complexity and the required
|
||
analysis type, guided by the service manager’s questions about the Step 1: Define the question. The service manager aims to improve
|
||
business process. Our implementation uses Python programming and the process by minimizing incidents not intercepted at the initial and
|
||
NumPy to handle the data. This extracted data is then used to answer secondary lines. They hypothesize that certain products are less likely
|
||
the service manager’s questions, as discussed in later sections. to be intercepted at the first two lines compared to others. Therefore,
|
||
they ask how often a product is escalated to the third line.
|
||
5.5. Step 4: Visualize the results Step 2: Specify the meta-model. The developer specifies a meta-
|
||
model to structure the data required to address the question. The data
|
||
After extracting the data, the developer uses data visualization tools should reflect the incidents escalated to the third line. The objective is
|
||
to create clear visuals. These visuals help the service manager quickly to identify the products escalated to the third line and their frequency.
|
||
|
||
7
|
||
S.I. Bouhidel et al. Computer Standards & Interfaces 97 (2026) 104108
|
||
|
||
|
||
Fig. 5 illustrates the specified meta-model. The specified meta- (43.66%), PROD617 (22.03%), and PROD611 (32.56%). These prod-
|
||
model contains one class and a table for analyzing incidents escalated ucts also show the highest occurrence counts (142, 71, 59, and 43,
|
||
to the third line. Each entry in this class assesses an individual product respectively) and notable instances escalated to the third line (69, 31,
|
||
and includes the following details: 13, and 14, respectively). This potentially indicates complexities or
|
||
challenges in their initial processing.
|
||
• Product: A unique identifier, for example, PROD582. The data also includes products such as PROD609, PROD194,
|
||
• Third_line_escalated_instances: The number of instances escalated PROD568, PROD655, PROD370, PROD5, PROD171, PROD582,
|
||
in the third line. PROD662, and PROD80. These exhibit high rates (39.39%, 21.43%,
|
||
• Total_instances: The overall number of the product instances. 46.15%, 25%, 41.18%, 43.75%, 37.5%, 33.33%, 35.71%, and 50%,
|
||
• Third_line_escalated_rate (%): The incident rate for the product respectively). However, their total instances are low (between 10 and
|
||
escalated to the third line. 33), and instances escalated to the third line are even lower (between
|
||
2 and 13).
|
||
Finally, the data presents products such as PROD89, PROD610, and
|
||
PROD658. These products exhibit high rates of 50% each, but these
|
||
rates derive from only two instances. Furthermore, only one instance
|
||
was escalated to the third line.
|
||
Products with high rates but low total instances (e.g., fewer than
|
||
10) are considered less relevant for decision-making because the small
|
||
sample size makes the rate unreliable. For example, a product with
|
||
only two instances showing a 50% rate (one escalated to the third line)
|
||
does not reliably predict its occurrence rate if it had 10 instances in a
|
||
subsequent analysis.
|
||
Fig. 5. Meta Model for Question One.
|
||
Following this analysis, the service manager questioned the exclu-
|
||
sion of products with fewer than 10 instances. The reasoning is that the
|
||
Step 3: Extract the data. The developer creates Python code to
|
||
total number of instances for these products is insignificant compared
|
||
collect the data described in the meta-model shown in Fig. 5. The data
|
||
to others. This consequently impacts the reliability of decision-making
|
||
extracted for the meta-model, Appendix Table 8, illustrates the products
|
||
for these products. For example, a product with only two instances
|
||
in the third line for which the escalate rate to the third line is greater
|
||
showing a 50% rate does not reliably indicate its occurrence rate if it
|
||
than 10% of the total occurrences (‘‘total instances’’).
|
||
had 10 instances in a subsequent analysis using a new dataset. This is
|
||
Table 3 because it appeared only once on the third line in the original data.
|
||
Data extracted for Question One (Selected Products). The complete dataset is By adhering to the service manager’s recommendations and filtering
|
||
provided in Appendix Table 8. the data, the developer provided the updated visualization in Fig. 7 for
|
||
Product Third line Total Third line the service manager’s review. The visualization in Fig. 7 illustrates how
|
||
escalated instances instances escalated products are escalated to the third line after filtering. The 𝑋-axis lists
|
||
count rate (%) product names, and the 𝑌 -axis represents the escalate rate. The analysis
|
||
PROD607 69 142 48.59 indicates that the products with fewer than 10 instances are smaller
|
||
PROD604 31 71 43.66 than the initial set.
|
||
PROD617 13 59 22.03 The summary highlights products with high percentages and in-
|
||
PROD611 14 43 32.56
|
||
stance counts. This comprehensive data analysis offers a precise un-
|
||
PROD609 13 33 39.39
|
||
derstanding of production challenges. It enables the service manager
|
||
PROD194 6 28 21.43
|
||
PROD568 12 26 46.15
|
||
to make informed decisions and recommendations to their department.
|
||
PROD655 5 20 25.00 For instance, causal analysis of products with high escalate rates could
|
||
PROD370 7 17 41.18 pinpoint specific quality or process issues.
|
||
PROD5 7 16 43.75 After the service manager validates the results and confirms their
|
||
PROD171 6 16 37.50 correctness and practicality, the developer can archive the analysis
|
||
PROD582 5 15 33.33 in the in-house library. If processing difficulties persist, the service
|
||
PROD662 5 14 35.71 manager should consider optimizing the initial processing lines to
|
||
PROD80 5 10 50.00 manage these complexities effectively. In this case, the service manager
|
||
PROD89 1 2 50.00 should consider initiating inquiries and restarting the method from the
|
||
PROD610 1 2 50.00
|
||
beginning, as the second example illustrates.
|
||
PROD658 1 2 50.00
|
||
|
||
6.2. Example 2: Team dynamics
|
||
Step 4: Visualize the results. The developer used the extracted
|
||
data from Appendix Table 8 so that the service manager could visualize Step 1: Define the question. The service manager wants to know
|
||
the results. The visualization, Appendix Fig. 21, illustrates essential whether the organizational group has a role in escalating products to
|
||
trends and patterns related to the meta-model’s first question. The 𝑥- the third line. To address this, they ask: Do the skills or practices of
|
||
axis lists the product names, while the 𝑦-axis measures the escalation certain organization group lead to more frequent escalations to the
|
||
rate. This representation highlights potential correlations or signifi- third line?
|
||
cant anomalies in the data. This visualization is crucial for improving Step 2: Specify the meta-model. The developer specifies a meta-
|
||
performance. model to structure the data required to address the question. Specifi-
|
||
Step 5: Interpret results and make decisions. The service man- cally, the data should reflect:
|
||
ager interprets the results to answer the question (Appendix Fig. 21)
|
||
and makes decisions. • The number of instances where organizational groups transfer
|
||
Based on the analysis of results in Appendix Table 8, which is products to the third line;
|
||
summarized in Table 3 and Fig. 6, the analysis identifies high escalation • The total number of instances handled by each organizational
|
||
rates for some products. These include PROD607 (48.59%), PROD604 group;
|
||
|
||
8
|
||
S.I. Bouhidel et al. Computer Standards & Interfaces 97 (2026) 104108
|
||
|
||
|
||
|
||
|
||
Fig. 6. Visualization of data Extracted for Question One (Selected Products). The complete Visualization is provided in Appendix Fig. 21
|
||
|
||
|
||
|
||
|
||
Fig. 7. Visualization of data Extracted with Filtering for Question One.
|
||
|
||
|
||
|
||
• The percentage of cases in which products were escalated to the • Organization_group: the organizational group responsible for es-
|
||
third line for each group. calating the product to the third line (e.g., V5 and V13).
|
||
• Total_instances: the total number of instances handled by the
|
||
This analysis helps identify organizational groups that transfer prod- group.
|
||
ucts to the third line and the names of these transferred products. The • Third_line_Organization_group_escalated_instances_cont: the num-
|
||
specified meta-model, illustrated in Fig. 8, consists of one class and ber of times the group escalated a product to the third line;
|
||
one table. These elements analyze the organization groups that escalate • Rate (%): the percentage of escalated cases relative to the group’s
|
||
products to the third line and their escalation rates relative to the total total workload.
|
||
instances. The meta-model includes the following attributes: • Product: the identifier of the escalated product (e.g., PROD765).
|
||
|
||
|
||
9
|
||
S.I. Bouhidel et al. Computer Standards & Interfaces 97 (2026) 104108
|
||
|
||
|
||
Table 4
|
||
Data extracted for meta model: Question Two.
|
||
Organization group Total Third line Rate (%) Product
|
||
Instances Organization group escalated
|
||
instances cont
|
||
G207 4 1 25.0 PROD765
|
||
V13 29 4 13.79 PROD582
|
||
N6 12 1 8.33 PROD370
|
||
G27 25 2 8.0 PROD611, PROD607
|
||
G276 32 1 3.12 PROD422
|
||
G51 241 1 0.41 PROD818
|
||
G96 1105 1 0.09 PROD611
|
||
Organizations with 0% escalate Rate 11721 0 0.0 None
|
||
|
||
|
||
|
||
Table 5
|
||
Combined results of products and organization groups.
|
||
Product Organization Instances escalated to the 3rd Line
|
||
PROD582 V13 4
|
||
PROD607 G27 1
|
||
PROD765 G207 1
|
||
PROD818 G51 1
|
||
PROD611 G96 1
|
||
PROD611 G27 1
|
||
PROD422 G276 1
|
||
PROD370 N6 1
|
||
64 Products Unknown 284
|
||
Fig. 8. Meta Model for Question two.
|
||
|
||
|
||
|
||
Step 3: Extract the data. The developer creates Python code to This discrepancy prompts the service manager to consider two possible
|
||
retrieve data outlined in the meta-model depicted in Fig. 8 and extracts explanations: either the escalations are product-specific (i.e., due to
|
||
relevant results (Table 4), which list each organizational group, total complexity), or the organizational source data is incomplete.
|
||
instances managed by the group, number of instances escalated to the The service manager attempts to obtain responses by generating a
|
||
third-line, its third-line escalate rate, and the associated product names. novel visualization based on the data from Examples 1 and 2.
|
||
Step 4: Visualize the results. The developer used the extracted The first hypothesis — that product complexity drives escalation —
|
||
data from Table 4 so that the service manager could visualize the results cannot be confirmed, as each organization appears to have escalated
|
||
(Fig. 9). The visualization shows the results for Question 2 regarding different products. The only shared case is PROD611, which was esca-
|
||
the organization groups. The 𝑋-axis shows the organization groups’ lated by both G96 and G27, with each group contributing one instance.
|
||
names, and the 𝑌 -axis shows the escalation rate. This visualization However, as shown in Appendix Table 8, PROD611 has a total of 14
|
||
highlights the role of these organization groups in escalating products escalations, meaning these two groups account for only 28% of its
|
||
to the third line, which can help improve the escalation process. cases. Therefore, the organizational data alone does not explain the full
|
||
Step 5: Interpret results and make decisions. The service man- pattern.
|
||
ager interprets the results (Fig. 9) to answer the question and make
|
||
Further analysis of Fig. 5 and Appendix Table 8 reveals that only 11
|
||
decisions.
|
||
third-line escalations can be linked to the seven named organizational
|
||
According to the analysis of these results (Table 4 and Fig. 9), the
|
||
groups. In contrast, the remaining 284 escalated instances, or 96.3%,
|
||
service manager observes that a relatively small number of organiza-
|
||
lack a known originating organization (see Fig. 10). As a result, no
|
||
tional groups (averaging only seven) escalate products to the third line.
|
||
In contrast, the remaining groups are classified as not escalating the reliable conclusions can be drawn about whether product complexity
|
||
product (see Table 5). or team inefficiency is the driving factor.
|
||
A closer look reveals that organizational groups with a 0% es- Consequently, the service manager must ask the developer to pro-
|
||
calation rate to the third line exhibit 11,721 instances. Group G96 pose a solution to improve the event log. The current system’s event
|
||
succeeded in escalating the product only once (PROD611), despite log lacks sufficient data for proper analysis due to missing information.
|
||
having 1105 recorded instances. Furthermore, six other organizational Addressing this issue could involve either implementing a new system
|
||
groups also have a significant number of instances but a low es- to capture more complete escalation data in the future or enhancing
|
||
calation rate. Specifically, groups G51, G276, N6, and G207 esca- the existing system to improve the completeness and accuracy of the
|
||
lated the product once each (PROD818, PROD422, PROD370, and event logs.
|
||
PROD765, respectively) despite their high total instance counts. Addi-
|
||
tionally, organizational group G27 successfully escalated two products
|
||
6.3. Example 3: Products with the longest resolution times
|
||
(PROD611 and PROD607), and organizational group V13 escalated
|
||
product PROD582 four times.
|
||
This leads the service manager to hypothesize that these teams may Step 1: Define the question. The service manager asks: Which
|
||
be capable of resolving most issues internally without escalation. While products have the longest resolution times?
|
||
not conclusive, the evidence suggests that some groups may perform Step 2: Specify the meta-model. The developer specifies a meta-
|
||
more effectively in early-stage resolution. model to structure the data required to address the question. The data
|
||
However, this result seems inconsistent with the findings from the reflect the average resolution times for all products. This analysis helps
|
||
Example 1, which indicated a high number of third-line escalations. determine which products take the most time to resolve.
|
||
|
||
10
|
||
S.I. Bouhidel et al. Computer Standards & Interfaces 97 (2026) 104108
|
||
|
||
|
||
|
||
|
||
Fig. 9. Visualization of data Extracted for Question Two.
|
||
|
||
|
||
|
||
|
||
Fig. 10. A doughnut chart showing the distribution of escalated instances across different products.
|
||
|
||
|
||
The specified meta-model, Fig. 11, consists of a single class and
|
||
a corresponding table. These are used to analyze the average res-
|
||
olution durations and highlight the slowest-resolving products. The
|
||
meta-model includes the following attributes:
|
||
|
||
• Product: is a unique identifier for each product.
|
||
• total_resolution_time: the cumulative time spent resolving all in-
|
||
cidents related to the product, including days, hours, and minutes
|
||
(e.g., ‘‘7 days 00:00:11’’ or ‘‘59 days 02:48:23’’).
|
||
• incident_count: the total number of resolved incidents per prod-
|
||
uct.
|
||
• avg_resolution_time: the average time required to resolve a sin- Fig. 11. Meta Model for Question three.
|
||
gle incident.
|
||
|
||
11
|
||
S.I. Bouhidel et al. Computer Standards & Interfaces 97 (2026) 104108
|
||
|
||
|
||
|
||
|
||
Fig. 12. Box plot for average resolution time for all products. The distribution is negatively skewed, with most products resolved near the lower quartile (Q1:
|
||
2 days, 12 h) and a median (Q2: 7 days, 8 h). Products exceeding the upper quartile (Q3: 8 days, 4 h) form a distinct outlier group, highlighting cases requiring
|
||
management attention to improve resolution efficiency.
|
||
|
||
|
||
|
||
|
||
Fig. 13. Box plot: longest average resolution time for products > Q3. The distribution is positively skewed, with Q1 (approximately 10 days) and the median
|
||
(Q2: approximately 12 days) indicating prolonged resolution, even for the fastest cases. Outliers above Q3 (18 days, 10 h) indicate products that face substantial
|
||
process bottlenecks or inefficiencies requiring attention.
|
||
|
||
|
||
Step 3: Extract the data. The developer creates Python code to while fewer products exhibit longer resolution times. The Q1 value (2
|
||
retrieve the data specified in the meta-model shown in Fig. 11. The days 12:18:21) and median Q2 value (7 days 7:32:52) suggest that res-
|
||
developer then extracts the data (Appendix Table 9). olution times for many products are typically around 5 days. However,
|
||
Given the large volume of data, the developer first takes an overall products exceeding the Q3 quartile form a clear outlier group. These
|
||
view using a box plot. This visualization helps subdivide the data into typically require more than 8 days, 3 h, 47 min, and 30 s for resolution.
|
||
well-defined classes: Q1 (25%), Q2 (50%), and Q3 (75%). This longer resolution time aligns with the service manager’s needs. The
|
||
The first box plot, Fig. 12, visualizes a negatively skewed distribu- upper quartile is particularly important because it identifies a subset of
|
||
tion, where most resolution times cluster near the lower end of Q1, products that require attention to enhance resolution efficiency.
|
||
|
||
12
|
||
S.I. Bouhidel et al. Computer Standards & Interfaces 97 (2026) 104108
|
||
|
||
|
||
|
||
|
||
Fig. 14. Visualization of data extracted for Question Three.
|
||
|
||
|
||
Table 6
|
||
Analysis of incident impact levels and their resolution times.
|
||
Impact Total incidents Total resolution time Average resolution time
|
||
High 531 2396 days, 17:41:31 4 days, 12:19:37
|
||
Low 5786 17348 days, 16:22:24 2 days, 23:57:40
|
||
Major 6 23 days, 11:35:52 3 days, 21:55:58
|
||
Medium 7544 25365 days, 04:04:18 3 days, 08:41:42
|
||
|
||
|
||
To focus the analysis, the developer filters the dataset to include times for the different products. The shortest average resolution time
|
||
only products with resolution times above Q3. Despite narrowing the shown is 18 days 12:41:37.
|
||
scope, the filtered group still contains many products with long dura- In the first series of products (between PROD783 and PROD570),
|
||
tions. As shown in Fig. 13, the developer creates a second box plot for the average resolution time increases by approximately one day for
|
||
this subset. each subsequent product. In contrast, the average resolution time in
|
||
The second box plot (Fig. 13) focuses exclusively on products with the second series (between PROD515 and PROD162) ranges from one
|
||
resolution times exceeding the Q3 threshold identified earlier (see to two days.
|
||
Fig. 12). This refined view reveals a positively skewed distribution, For other products, the analysis observed more notable variations.
|
||
with most values concentrated towards the higher end of Q3. The Q1 The resolution time for PROD829 is three days longer than its predeces-
|
||
value (approximately 10 days) suggests that even the fastest-resolving sor. The difference between PROD388 and PROD645 is eight days, and
|
||
products in this group require significant time. The median Q2 (around between PROD645 and PROD21 is seven days. Similarly, the difference
|
||
12 days) indicates that half of the products in this group require more between PROD21 and PROD127 is four days. A substantial increase
|
||
than one week for resolution. The Q3 value (18 days, 10 h, and 42 min) of 48 days in resolution time was observed between PROD127 and
|
||
PROD681, followed by a six-day difference between PROD681 and
|
||
marks the upper range of what could be considered typical. Above
|
||
PROD79.
|
||
that threshold lie several extreme outliers. These outliers are especially
|
||
In conclusion, products with resolution times exceeding 46 days are
|
||
important to examine, as they may indicate process bottlenecks or
|
||
classified as having extremely long resolution periods. These products
|
||
product-specific inefficiencies.
|
||
include PROD829, PROD388, PROD645, PROD21, PROD127, PROD
|
||
The data (Appendix Table 9) list products with the longest aver-
|
||
681, and PROD79. For future analysis, the service manager should
|
||
age resolution times. For each product, the table provides the total
|
||
engage the development team to document this information in an
|
||
resolution time, number of incidents, and the computed average.
|
||
internal knowledge library to ensure accessibility.
|
||
The developer uses the data from Appendix Table 9 to create a This analysis validates the service manager’s initial question by
|
||
visualization 14 that ranks the products based on their average res- highlighting potential complications that require performance adjust-
|
||
olution time. This allows the service manager to quickly identify the ments.
|
||
slowest-resolving products within the long-duration subset. Comparing the data from Example 1 and Example 3 reveals that
|
||
Step 5:Interpret results and make decisions. The service man- seven products—PROD645, PROD537, PROD766, PROD617, PROD75,
|
||
ager interprets the results (Fig. 14) to answer the question and make PROD658, and PROD247—appear in both the ‘‘longest average res-
|
||
decisions. olution time’’ and ‘‘products escalated to the third line’’ categories.
|
||
Based on the analysis of the results (Appendix Table 9 and Fig. 14), These products exhibit both high average resolution times and frequent
|
||
the service manager conducted a comparative analysis of the resolution instances escalated to the third line, suggesting a need to improve their
|
||
|
||
13
|
||
S.I. Bouhidel et al. Computer Standards & Interfaces 97 (2026) 104108
|
||
|
||
|
||
incident management processes. This finding enables the service man- 2. Low: 2 days, 23 h, 57 min, 40 s (259,060 s);
|
||
ager to pose additional questions and analyze resources to implement 3. Medium: 3 days, 8 h, 41 min, 42 s (290,502 s);
|
||
performance enhancements. 4. High: 4 days, 12 h, 19 min, 37 s (389,977 s).
|
||
|
||
6.4. Example 4: Impact levels of incidents and their resolution time Thus, these data demonstrate a clear positive correlation between inci-
|
||
dent impact and resolution time, with higher-impact incidents requiring
|
||
Step 1: Define the question. The service manager wants to know substantially longer to resolve.
|
||
whether incidents with higher impact levels are resolved more quickly. Fig. 16 illustrates a positive trend between incident impact and
|
||
To address this, they ask: Is there a correlation between incident impact resolution time. A Weighted Least Squares (WLS) regression analysis
|
||
level and resolution time? confirms this descriptive relationship, with the model explaining a
|
||
Step 2: Specify the meta-model. The developer specifies a meta- substantial portion of the variance in resolution time (𝑅2 = 0.807,
|
||
model for structuring the data needed to answer the question. The data adjusted 𝑅2 = 0.711; see Table 7). Despite this strong model fit,
|
||
reflect incident resolution times categorized by impact level and the however, the overall relationship is not statistically significant (F-
|
||
average resolution time for each impact level. statistic = 8.387, 𝑝 = 0.101). Similarly, the coefficient for the impact
|
||
The specified meta-model, illustrated in Fig. 15, consists of one class level, while indicating an increase in resolution time of approximately
|
||
and one table that analyzes the resolution times for incidents grouped 11.85 h (42,680 s) per impact level, does not reach the significance
|
||
by impact level. The meta-model includes the following attributes: threshold of 𝛼 = 0.05.
|
||
The lack of statistical significance is likely attributable to the low
|
||
• Impact Level: a categorical variable representing the incident’s statistical power of the analysis, a direct consequence of the lim-
|
||
severity (e.g., High, Medium, Low, Major); ited degrees of freedom available from only four impact categories.
|
||
• incident_count: the total number of incidents for each impact Consequently, while the data suggest a positive correlation, they are
|
||
level; insufficient to formally conclude that a relationship between incident
|
||
• total_resolution_time: the cumulative time to resolve all inci- impact and resolution time exists. Validating this potential trend and
|
||
dents per impact level, in days, hours, and minutes (e.g., ‘‘5 days achieving sufficient statistical power would require a larger dataset
|
||
12:19:30’’); with more observations. This limitation underscores the preliminary
|
||
• avg_resolution_time: the average time to resolve a single inci- nature of the current finding.
|
||
dent for each impact level.
|
||
7. Empirical evaluation
|
||
|
||
An exploratory survey, titled Survey on Requirement-Driven Process
|
||
Mining Approaches, was conducted to empirically evaluate the pro-
|
||
posed requirement-driven process mining approach. Thirty participants
|
||
completed the seven-question survey.
|
||
|
||
7.1. Participant demographics
|
||
|
||
The participants reported diverse levels of expertise in data analy-
|
||
sis and process mining. For data analysis, 50% identified as experts,
|
||
40% reported basic knowledge, and 10% were unfamiliar with the
|
||
Fig. 15. Meta-Model for Question four. subject. Regarding process mining, 16.7% of participants were experts,
|
||
63.3% had basic knowledge, and 20% were unfamiliar. This diverse
|
||
Step 3: Extract the data. The developer creates Python code to distribution of expertise ensures a balanced evaluation of the proposed
|
||
retrieve the data outlined in the meta-model 15 and extracts the values approach from multiple viewpoints.
|
||
shown in Table 6.
|
||
Table 6 summarizes, for each impact level, the total number of 7.2. Key findings
|
||
incidents, the combined resolution time, and the average time per
|
||
incident. The survey yielded four key findings regarding the perception and
|
||
Step 4: Visualize the results. The developer used Weighted Regres- potential application of the proposed approach:
|
||
sion Analysis on the extracted data from Table 6 so that the service
|
||
manager could visualize the results in Fig. 16. The developer also • Comparative Effectiveness: A significant majority of partici-
|
||
provided the summary table of this analysis, Table 7, for the service pants (93.3%; 28 out of 30) perceived the proposed requirement-
|
||
manager to interpret and draw conclusions. driven approach as delivering superior results compared to tra-
|
||
The visualization, Fig. 16, illustrates the relationship between im- ditional process mining tools. The remaining two participants
|
||
pact level (X-axis) and average resolution time in seconds (Y-axis). Each (6.7%) were unsure (see Fig. 17).
|
||
point represents a category of impact level. Bubble size reflects data • Integration with Existing Tools: When asked about combining
|
||
magnitude for each point. The red regression line indicates a trend and the proposed method with existing tools, 56.7% of participants
|
||
highlights the correlation between higher impact levels and increased (17) stated they would definitely do so, and 36.7% (11) responded
|
||
resolution times. with ‘‘maybe, in some cases’’. Only two participants (6.7%) pre-
|
||
Step 5: Interpret results and make decisions. The service man- ferred to use a single tool exclusively. This result indicates that
|
||
ager analyzed the statistical results presented in Fig. 16, Table 7, and the proposed approach is viewed not as a replacement for existing
|
||
Table 6 to determine whether a correlation exists between incident tools, but as a valuable complement (see Fig. 18).
|
||
impact levels and their resolution times. • Cognitive Load Management: When dealing with models that
|
||
As shown in the data presented in Table 6, the average incident create a high cognitive load, 63.3% of participants (19) preferred
|
||
resolution times, ordered by impact level, are as follows: the proposed approach, while 36.7% (11) favored a combination
|
||
of methods. This highlights its utility in simplifying complex
|
||
1. Major: 3 days, 21 h, 55 min, 58 s (338,158 s); process analysis (see Fig. 19).
|
||
|
||
14
|
||
S.I. Bouhidel et al. Computer Standards & Interfaces 97 (2026) 104108
|
||
|
||
|
||
|
||
|
||
Fig. 16. Analysis of Impact Levels of Incidents and Their Resolution Times.
|
||
|
||
|
||
Table 7
|
||
WLS regression results.
|
||
Dep. Variable: Average_Resolution_Time_Seconds R-squared: 0.807
|
||
Model: WLS Adj. R-squared: 0.711
|
||
Method: Least Squares F-statistic: 8.387
|
||
Date: Mon, 20 Jan 2025 Prob (F-statistic): 0.101
|
||
Time: 11:47:28 Log-Likelihood: −46.604
|
||
No. Observations: 4 AIC: 97.21
|
||
Df Residuals: 2 BIC: 95.98
|
||
Df Model: 1
|
||
Covariance Type: nonrobust
|
||
coef std err t P> |𝐭| [0.025 0.975]
|
||
const 1.694e+05 3.95e+04 4.290 0.050 −502.738 3.39e+05
|
||
Impact_Numeric 4.268e+04 1.47e+04 2.896 0.101 −2.07e+04 1.06e+05
|
||
Omnibus: nan Durbin-Watson: 0.797
|
||
Prob(Omnibus): nan Jarque–Bera (JB): 0.174
|
||
Skew: −0.108 Prob(JB): 0.917
|
||
Kurtosis: 2.002 Cond. No. 14.5
|
||
|
||
|
||
|
||
|
||
Fig. 17. Survey responses on the comparative effectiveness of the proposed Fig. 18. Participant willingness to combine the proposed requirement-driven
|
||
approach versus traditional tools (N=30). approach with existing process mining tools (N=30).
|
||
|
||
|
||
|
||
|
||
15
|
||
S.I. Bouhidel et al. Computer Standards & Interfaces 97 (2026) 104108
|
||
|
||
|
||
MDE mechanisms, such as the systematic mapping of requirements to
|
||
executable results, to address documented shortcomings of traditional
|
||
process mining. These shortcomings include cognitive overload from
|
||
overly complex models and the misalignment of findings with business
|
||
requirements. This method is not proposed as a replacement for estab-
|
||
lished process mining tools like ProM and Disco. Instead, it functions
|
||
as a complementary methodology for contexts where traditional tools
|
||
produce results that are too general or cognitively demanding for
|
||
managerial objectives. To supplement the descriptive evaluation, a
|
||
preliminary exploratory survey was conducted comparing the proposed
|
||
method with traditional process-mining tools. Participants consistently
|
||
reported improved clarity and decision-making support when using the
|
||
requirement-driven approach, particularly in contexts involving high
|
||
Fig. 19. Participant preference for an approach when faced with high cogni-
|
||
cognitive load. While exploratory in scope, these results provide an
|
||
tive load from complex models (N=30). empirical basis for future large-scale validation.
|
||
Traditional process mining methodologies typically favor exhaus-
|
||
tive modeling, generating comprehensive models that include large
|
||
amounts of irrelevant data. Although these representations may seem
|
||
beneficial from a data completeness perspective, recent studies high-
|
||
light significant downsides. Such models often cause information over-
|
||
load, increasing cognitive demand and negatively impacting manage-
|
||
rial productivity and decision-making [31,32]. This finding aligns with
|
||
Cognitive Load Theory (CLT), which emphasizes the limited processing
|
||
capacity of users and suggests that analytical models should inten-
|
||
tionally limit and prioritize outputs to enhance comprehension [31].
|
||
Within this framework, the proposed method offers a structured al-
|
||
ternative that selectively simplifies process models to prioritize the
|
||
interpretability and relevance of these models over mere data ex-
|
||
haustiveness. Moreover, once requirement-driven queries have been
|
||
formalized and validated, they can be stored and reused as modular
|
||
Fig. 20. Participant responses on using the proposed approach to refine analytical components. This mechanism allows service managers to
|
||
traditional models that lack necessary information (N=30). retrieve and adapt prior analyses without direct developer intervention,
|
||
thereby reducing dependency and improving response times. Future
|
||
integration with low-code or semi-automated platforms could further
|
||
• Refining Incomplete Models: A vast majority of participants extend this self-service capability.
|
||
(90%; 27 out of 30) affirmed they would use the proposed ap- By systematically limiting outputs to elements explicitly requested
|
||
proach to refine models generated by traditional tools that lack by decision-makers, this MDE approach proactively manages cognitive
|
||
required information (see Fig. 20). load and generates artifacts with improved clarity, simplicity, and
|
||
precision. The method uses explicit modeling techniques to create
|
||
7.3. Qualitative insights outputs tightly coupled to user requirements, thereby significantly
|
||
reducing the cognitive complexity typical of traditional frameworks.
|
||
Open-ended survey responses highlighted several perceived This result is consistent with recent recommendations in computer-
|
||
strengths of the proposed approach, including: supported decision-making research advocating for methods that pri-
|
||
oritize relevance and specificity over quantity and completeness [33,
|
||
• Enhanced focus on specific business requirements. 34]. Moreover, this targeted scope provides a valuable complement to
|
||
• Reduced complexity in the resulting process models. automated tools by ensuring that insights remain directly aligned with
|
||
• More targeted and interpretable analysis. stakeholder-defined needs while avoiding analytical noise.
|
||
Nevertheless, the proposed method has several operational and
|
||
Participants also suggested potential improvements, such as greater au- technical constraints. The primary limitation is the need for continuous
|
||
tomation and the need for validation across broader and more diverse technical involvement, as each new managerial request demands an
|
||
datasets. explicit redefinition or adjustment of models, transformations, and
|
||
executable artifacts. This dependency on software engineering support
|
||
7.4. Limitations introduces significant operational overhead, which can affect respon-
|
||
siveness and resource allocation. In contrast, traditional tools (such as
|
||
While this survey provides preliminary validation of the proposed ProM or Disco) offer users greater exploratory autonomy, allowing for
|
||
approach’s practical relevance, its findings are exploratory. The pri- independent—though cognitively demanding—interaction with large
|
||
mary limitation is the modest sample size (n=30), which restricts the datasets. To investigate this trade-off, an empirical evaluation involv-
|
||
generalizability of the results. Future work will focus on a larger-scale ing thirty participants was conducted. The results confirmed that the
|
||
validation study, incorporating quantitative performance metrics to requirement-driven approach significantly reduced cognitive effort and
|
||
build upon these initial qualitative findings. decision-making complexity compared to traditional tools, validating
|
||
its effectiveness in managing the cognitive overload documented in
|
||
8. Discussion information systems research [34,35].
|
||
A key implication of this research is the challenge of balancing
|
||
This research introduces a requirement-driven method based on targeted precision with user autonomy. Future research could explore
|
||
MDE that provides managers with process analysis outcomes tailored to integrating advanced techniques to automate or semi-automate the
|
||
their specific information needs. The proposed approach leverages core evolution of requirement-driven MDE systems. Techniques such as
|
||
|
||
16
|
||
S.I. Bouhidel et al. Computer Standards & Interfaces 97 (2026) 104108
|
||
|
||
|
||
intelligent model inference, adaptive machine learning, and dynamic Integrating the proposed approach within Agile cycles combines
|
||
model adaptation could reduce the need for manual adjustments, lessen the adaptability of iterative development with the rigor of structured
|
||
technical dependency, and enable sustainable cognitive load manage- requirement analysis. This integration fosters consistency, reduces ad-
|
||
ment, while preserving the decision-making advantages of a targeted hoc decision-making, and enhances clarity across development and
|
||
approach. Additionally, future studies could incorporate controlled managerial levels. The approach thus provides not only a method-
|
||
benchmarking to systematically assess the comparative performance of ological contribution but also a practical framework for deploying
|
||
requirement-driven and traditional process mining tools across differ- requirement-driven engineering in process mining.
|
||
ent organizational contexts. Ultimately, this research advances process mining from a descrip-
|
||
In summary, this research demonstrates the practical feasibility tive, analytical exercise to a prescriptive, strategic tool directly respon-
|
||
and analytical advantages of integrating requirement-driven MDE tech- sive to business needs. By embedding organizational requirements into
|
||
niques into process analysis. The study also highlights key directions the core of model discovery, this work provides a foundation for more
|
||
for technical improvement, emphasizing automation and adaptability. effective and context-aware, data-driven decision-making.
|
||
Addressing these areas in future research will enhance the method’s
|
||
practical utility, operational scalability, and broader applicability in CRediT authorship contribution statement
|
||
real-world managerial contexts.
|
||
Selsabil Ines Bouhidel: Writing – original draft, Investigation, Con-
|
||
9. Conclusion ceptualization. Mohammed Mounir Bouhamed: Writing – review &
|
||
editing, Writing – original draft, Project administration, Investigation,
|
||
Current process mining methods are often limited by model com- Conceptualization. Gregorio Diaz: Writing – review & editing, Vali-
|
||
plexity, low adaptability, and poor alignment with business objec- dation, Supervision, Investigation, Funding acquisition. Nabil Belala:
|
||
tives. These limitations hinder the generation of actionable insights, Writing – review & editing, Supervision, Conceptualization.
|
||
particularly in dynamic operational environments.
|
||
This study introduces a requirement-driven, meta-modeling ap- Declaration of Generative AI and AI-assisted technologies in the
|
||
proach to address these limitations. The proposed approach directly writing process
|
||
incorporates user-defined requirements into the model discovery pro-
|
||
cess, linking process models to organizational goals to improve their During the preparation of this work, the authors used ChatGPT
|
||
interpretability and adaptability. This linkage produces more precise, (OpenAI) and Gemini (Google) to improve the language and readability
|
||
actionable, and context-aware business process representations. The of the manuscript. After using these tools, the authors reviewed and
|
||
study also developed a lightweight, scalable Python-based analytical edited the content as needed and take full responsibility for the content
|
||
tool. In contrast to generalist platforms, the developed tool offers of the publication.
|
||
solutions tailored to service managers, thereby enhancing usability and
|
||
decision-making.
|
||
Declaration of competing interest
|
||
This work demonstrates the value of integrating technological in-
|
||
novation with practical application by aligning process mining more
|
||
The authors declare the following financial interests/personal rela-
|
||
closely with organizational goals. Future research should focus on three
|
||
key areas: (1) automating meta-model adaptation using techniques such tionships which may be considered as potential competing interests:
|
||
as adaptive machine learning to reduce user dependency on technical Gregorio Diaz reports financial support and administrative support
|
||
experts; (2) systematically evaluating the performance and applicability were provided by University of Castilla-La Mancha. Gregorio Diaz
|
||
of the approach across diverse industries and with varying data quality; reports financial support was provided by Spain Ministry of Science and
|
||
and (3) enhancing the scalability of the analytical tool for extremely Innovation. Gregorio Diaz reports was provided by European Regional
|
||
large event logs. To validate these advancements, subsequent work will Development Fund. If there are other authors, they declare that they
|
||
involve systematically benchmarking the approach against multiple have no known competing financial interests or personal relationships
|
||
datasets, conducting controlled experiments to isolate the effects of that could have appeared to influence the work reported in this paper.
|
||
specific features, and performing user studies to assess the correctness,
|
||
robustness, and optimality of the generated solutions. Acknowledgments
|
||
Beyond these computational contributions, this research provides
|
||
practical guidance for implementing the requirement-driven approach This research was funded by the Ministerio de Ciencia, Innovación
|
||
in organizational contexts. The approach can be systematically embed- y Universidades, Agencia Estatal de Investigación, MICIU/AEI/10.1303
|
||
ded within enterprise and software development workflows, particu- 9/501100011033 grant number PID2021-122215NB-C32, European
|
||
larly Agile frameworks, to enhance its operational value. To facilitate Regional Development Found EU grant numbers PID2021-122215NB-
|
||
this integration, the following guidelines map the requirement-driven C32 and 2022-GRIN-34113 and University of Castilla-La Mancha grant
|
||
approach onto established Agile ceremonies: number 2022-GRIN-34113.
|
||
It is also supported by Direction Générale de la Recherche Scien-
|
||
• Backlog Refinement: The service manager evaluates existing tifique et du Développement Technologique in Algeria under the PRFU
|
||
tools against requirements. If gaps exist, the approach systemati- project C00L07UN250220230008.
|
||
cally derives candidate solutions.
|
||
• Sprint Planning: The approach’s outcomes (e.g., structured re-
|
||
Appendix A. Extended tables
|
||
quirements and solution paths) inform sprint goals, ensuring
|
||
alignment with validated needs.
|
||
See Tables 8 and 9.
|
||
• Sprint Execution: Teams implement features based on the de-
|
||
rived requirements and solution paths, adapting to feedback.
|
||
• Sprint Review and Retrospective: Structured requirements pro- Appendix B. Extended figures
|
||
vide objective criteria for assessing delivered increments against
|
||
initial needs, facilitating the capture of reusable knowledge for See Fig. 21.
|
||
future sprints.
|
||
|
||
17
|
||
S.I. Bouhidel et al. Computer Standards & Interfaces 97 (2026) 104108
|
||
|
||
|
||
Table 8
|
||
Data Extracted for Question One.
|
||
Product Third line Total Third line Product Third line Total Third line
|
||
escalated instances instances escalated escalated instances instances escalated
|
||
count rate (%) count rate (%)
|
||
PROD582 5 15 33.33 PROD247 2 4 50.00
|
||
PROD645 1 6 16.67 PROD353 1 5 20.00
|
||
PROD617 13 59 22.03 PROD693 1 2 50.00
|
||
PROD67 3 6 50.00 PROD87 1 6 16.67
|
||
PROD803 1 4 25.00 PROD405 1 4 25.00
|
||
PROD609 13 33 39.39 PROD598 2 6 33.33
|
||
PROD607 69 142 48.59 PROD658 1 2 50.00
|
||
PROD765 1 6 16.67 PROD622 1 7 14.29
|
||
PROD493 1 6 16.67 PROD155 1 5 20.00
|
||
PROD537 3 6 50.00 PROD74 2 4 50.00
|
||
PROD611 14 43 32.56 PROD189 1 2 50.00
|
||
PROD182 1 8 12.50 PROD589 1 6 16.67
|
||
PROD604 31 71 43.66 PROD692 2 4 50.00
|
||
PROD606 3 5 60.00 PROD614 1 2 50.00
|
||
PROD655 5 20 25.00 PROD613 1 2 50.00
|
||
PROD546 4 32 12.50 PROD419 1 8 12.50
|
||
PROD75 1 2 50.00 PROD594 1 7 14.29
|
||
PROD695 4 8 50.00 PROD771 1 7 14.29
|
||
PROD509 4 29 13.79 PROD72 1 4 25.00
|
||
PROD766 1 2 50.00 PROD5 7 16 43.75
|
||
PROD422 1 4 25.00 PROD568 12 26 46.15
|
||
PROD662 5 14 35.71 PROD761 1 2 50.00
|
||
PROD73 4 8 50.00 PROD602 1 2 50.00
|
||
PROD630 1 2 50.00 PROD71 1 2 50.00
|
||
PROD70 2 5 40.00 PROD80 5 10 50.00
|
||
PROD3 1 9 11.11 PROD559 1 8 12.50
|
||
PROD370 7 17 41.18 PROD352 2 6 33.33
|
||
PROD797 1 6 16.67 PROD102 2 4 50.00
|
||
PROD171 6 16 37.50 PROD569 1 4 25.00
|
||
PROD603 2 12 16.67 PROD610 1 2 50.00
|
||
PROD756 3 17 17.65 PROD708 1 2 50.00
|
||
PROD194 6 28 21.43 PROD57 1 2 50.00
|
||
PROD222 1 6 16.67 PROD89 1 2 50.00
|
||
PROD578 1 2 50.00 PROD301 1 2 50.00
|
||
PROD750 3 6 50.00 PROD690 1 2 50.00
|
||
|
||
|
||
|
||
|
||
Fig. 21. Visualization of data Extracted for Question One.
|
||
|
||
|
||
|
||
|
||
18
|
||
S.I. Bouhidel et al. Computer Standards & Interfaces 97 (2026) 104108
|
||
|
||
|
||
Table 9
|
||
Average resolution time per product (Q75).
|
||
Product Total resolution time Incident count Average resolution time
|
||
PROD783 37 days 01:23:13 2 18 days 12:41:36.500000
|
||
PROD247 37 days 23:49:05 2 18 days 23:54:32.500000
|
||
PROD786 95 days 09:40:38 5 19 days 01:56:07.600000
|
||
PROD284 38 days 20:48:21 2 19 days 10:24:10.500000
|
||
PROD658 19 days 12:22:47 1 19 days 12:22:47
|
||
PROD672 19 days 14:32:03 1 19 days 14:32:03
|
||
PROD75 19 days 14:56:36 1 19 days 14:56:36
|
||
PROD751 19 days 16:14:55 1 19 days 16:14:55
|
||
PROD199 41 days 03:38:57 2 20 days 13:49:28.500000
|
||
PROD192 42 days 08:17:45 2 21 days 04:08:52.500000
|
||
PROD617 684 days 12:20:52 30 22 days 19:36:41.733333333
|
||
PROD311 69 days 13:30:26 3 23 days 04:30:08.666666666
|
||
PROD130 47 days 13:01:44 2 23 days 18:30:52
|
||
PROD337 677 days 20:51:51 28 24 days 05:01:51.107142857
|
||
PROD777 24 days 10:10:37 1 24 days 10:10:37
|
||
PROD65 50 days 08:31:23 2 25 days 04:15:41.500000
|
||
PROD766 25 days 07:53:03 1 25 days 07:53:03
|
||
PROD114 178 days 04:36:45 7 25 days 10:56:40.714285714
|
||
PROD276 76 days 22:19:21 3 25 days 15:26:27
|
||
PROD534 52 days 07:07:38 2 26 days 03:33:49
|
||
PROD62 26 days 13:36:14 1 26 days 13:36:14
|
||
PROD537 84 days 15:45:00 3 28 days 05:15:00
|
||
PROD332 29 days 04:42:13 1 29 days 04:42:13
|
||
PROD99 58 days 23:31:30 2 29 days 11:45:45
|
||
PROD116 88 days 23:56:23 3 29 days 15:58:47.666666666
|
||
PROD570 30 days 13:17:41 1 30 days 13:17:41
|
||
PROD515 32 days 08:15:10 1 32 days 08:15:10
|
||
PROD784 34 days 11:44:38 1 34 days 11:44:38
|
||
PROD290 34 days 15:31:04 1 34 days 15:31:04
|
||
PROD193 38 days 11:32:43 1 38 days 11:32:43
|
||
PROD782 39 days 10:13:20 1 39 days 10:13:20
|
||
PROD486 315 days 11:44:50 8 39 days 10:28:06.250000
|
||
PROD324 41 days 00:45:06 1 41 days 00:45:06
|
||
PROD519 41 days 05:15:30 1 41 days 05:15:30
|
||
PROD449 41 days 14:29:19 1 41 days 14:29:19
|
||
PROD798 45 days 06:47:55 1 45 days 06:47:55
|
||
PROD162 46 days 13:55:45 1 46 days 13:55:45
|
||
PROD829 49 days 12:00:19 1 49 days 12:00:19
|
||
PROD388 358 days 07:14:31 7 51 days 04:27:47.285714285
|
||
PROD645 177 days 08:25:09 3 59 days 02:48:23
|
||
PROD21 68 days 11:51:21 1 68 days 11:51:21
|
||
PROD127 72 days 03:56:28 1 72 days 03:56:28
|
||
PROD681 120 days 14:45:15 1 120 days 14:45:15
|
||
PROD79 126 days 20:13:57 1 126 days 20:13:57
|
||
|
||
|
||
Data availability [4] Grand View Research, Business process outsourcing market size, share & trends
|
||
analysis report by service type (customer services, finance & accounting), by
|
||
outsourcing type, by deployment, by end use, by region, and segment fore-
|
||
Readers may find all the data obtained to reproduce the results casts, 2025–2030, 2025, https://www.grandviewresearch.com/industry-analysis/
|
||
presented in this paper and the corresponding source code in the business-process-outsourcing-bpo-market. (Accessed 9 December 2025).
|
||
following repository: Bouhidel, Selsabil Ines; Bouhamed, Mohammed [5] Wil Aalst, The application of Petri nets to workflow management, J. Circuits
|
||
Syst. Comput. 8 (1998) 21–66, http://dx.doi.org/10.1142/S0218126698000043.
|
||
Mounir; Diaz, Gregorio; Belala, Nabil (2025), ‘‘A requirement driven
|
||
[6] Anna A. Kalenkova, Wil M.P. van der Aalst, Irina A. Lomazova, Vladimir A.
|
||
process mining dataset, Mendeley Data, V2, doi: 10.17632/s7rjw8nnvm. Rubin, Process mining using BPMN: relating event logs and process models, in:
|
||
2. Proceedings of the ACM/IEEE 19th International Conference on Model Driven
|
||
Engineering Languages and Systems, 2016, pp. 123–123.
|
||
[7] Philip Weber, Behzad Bordbar, Peter Tino, A framework for the analysis of
|
||
process mining algorithms, Syst. Man Cybern.: Syst. IEEE Trans. 43 (2013)
|
||
References
|
||
303–317, http://dx.doi.org/10.1109/TSMCA.2012.2195169.
|
||
[8] Adriano Augusto, R. Conforti, M. Dumas, M. Rosa, Artem Polyvyanyy, Split
|
||
[1] Wil M.P. van der Aalst, Process Mining: Data Science in Action, Springer, miner: automated discovery of accurate and simple business process models
|
||
Heidelberg, ISBN: 978-3-662-49850-7, 2016, http://dx.doi.org/10.1007/978-3- from event logs, Knowl. Inf. Syst. 59 (2019) 251–284, http://dx.doi.org/10.1007/
|
||
662-49851-4. s10115-018-1214-x.
|
||
[2] Mohammed Mounir Bouhamed, Allaoua Chaoui, Radouane Nouara, Grego- [9] Volodymyr Leno, Marlon Dumas, Fabrizio Maria Maggi, Marcello La Rosa,
|
||
rio Díaz, Abderraouf Dembri, Reducing the number of migrated instances Artem Polyvyanyy, Automated discovery of declarative process models with
|
||
during business process change: A graph rewriting approach, J. King Saud correlated data conditions, Inf. Syst. (ISSN: 0306-4379) 89 (2020) 101482, http:
|
||
Univ.-Comput. Inf. Sci. 34 (9) (2022) 7720–7734. //dx.doi.org/10.1016/j.is.2019.101482, URL: https://www.sciencedirect.com/
|
||
[3] Mordor Intelligence, Business process management market — growth, science/article/pii/S0306437919305344.
|
||
trends, COVID-19 impact, and forecasts (2024–2029), 2024, https://www. [10] Felix Groß, Lisa Mannel, Wil Aalst, Enhancing the applicability of the eST-
|
||
mordorintelligence.com/industry-reports/business-process-management-market. miner: Efficient precision-guided implicit place avoidance, 2023, pp. 121–128,
|
||
(Accessed 28 May 2025). http://dx.doi.org/10.1109/ICPM60904.2023.10271973.
|
||
|
||
|
||
19
|
||
S.I. Bouhidel et al. Computer Standards & Interfaces 97 (2026) 104108
|
||
|
||
|
||
[11] A. Kusters, Wil M.P. van der Aalst, Revisiting the alpha algorithm to enable [24] W. van der Aalst, T. Weijters, L. Maruster, Workflow mining: discovering process
|
||
real-life process discovery applications - extended report, 2023, http://dx.doi. models from event logs, IEEE Trans. Knowl. Data Eng. 16 (9) (2004) 1128–1142,
|
||
org/10.48550/arXiv.2305.17767, arXiv, abs/2305.17767. http://dx.doi.org/10.1109/TKDE.2004.47.
|
||
[12] Anon, Tool, 2020, URL: https://promtools.org/prom-documentation/. (Accessed [25] Massimiliano de Leoni, Wil Aalst, Marcus Dees, A general process mining
|
||
2020). framework for correlating, predicting and clustering dynamic behavior based on
|
||
[13] Anon, Tool, 2020, URL: https://fluxicon.com/disco/. (Accessed 2020). event logs, Inf. Syst. 56 (2015) http://dx.doi.org/10.1016/j.is.2015.07.003.
|
||
[14] Jean Bézivin, Olivier Gerbé, Towards a precise definition of the OMG/MDA [26] Tpb Wiel, Process mining using integer linear programming, 2010, URL: https:
|
||
framework, ISBN: 0-7695-1426-X, 2001, pp. 273–280, http://dx.doi.org/10. //api.semanticscholar.org/CorpusID:16736603.
|
||
1109/ASE.2001.989813. [27] A. Rozinat, W.M.P. van der Aalst, Conformance checking of processes
|
||
[15] Marco Brambilla, Jordi Cabot, Manuel Wimmer, Model-Driven Software based on monitoring real behavior, Inf. Syst. (ISSN: 0306-4379) 33 (1)
|
||
Engineering in Practice, vol. 1, 2012, http://dx.doi.org/10.2200/ (2008) 64–95, http://dx.doi.org/10.1016/j.is.2007.07.001, URL: https://www.
|
||
S00441ED1V01Y201208SWE001. sciencedirect.com/science/article/pii/S030643790700049X.
|
||
[16] Skander Turki, Ingénierie système guidée par les modèles : Application du [28] Marlon Dumas, Luciano García-Bañuelos, Process Mining Reloaded: Event
|
||
standard IEEE 15288, de l’architecture MDA et du langage SysML à la conception Structures as a Unified Representation of Process Models and Event Logs,
|
||
des systèmes mécatroniques, 2008. ISBN: 978-3-319-19487-5, 2015, pp. 33–48, http://dx.doi.org/10.1007/978-3-
|
||
[17] Xixi Lu, A. Gal, H. Reijers, Discovering hierarchical processes using flexible activ- 319-19488-2_2.
|
||
ity trees for event abstraction, in: 2020 2nd International Conference on Process [29] Volvo IT, VINST data set, 2012, Document discussing the VINST dataset and its
|
||
Mining, ICPM, 2020, pp. 145–152, http://dx.doi.org/10.1109/ICPM49681.2020. related processes such as incident and problem management.
|
||
00030. [30] Volvo Group, Volvo IT contact information, 2025, https://www.volvogroup.com/
|
||
[18] Adriano Augusto, Marlon Dumas, Marcello La Rosa, Automated discovery of en/contact-us/volvo-it.html. (Accessed 2024).
|
||
process models with true concurrency and inclusive choices, ISBN: 978-3- [31] Brianda Sígolo, Helen Casarin, Contributions of cognitive load theory to un-
|
||
030-72692-8, 2021, pp. 43–56, http://dx.doi.org/10.1007/978-3-030-72693-5_ derstanding information overload: a literature review, RDBCI Rev. Digit. Bibl.
|
||
4. E Ciência Informação 22 (2024) p. e024027, http://dx.doi.org/10.20396/rdbci.
|
||
[19] Merve Tiftik, Tugba Gurgen Erdogan, Ayça Kolukısa, A framework for multi- v22i00.8677359/en.
|
||
perspective process mining into a BPMN process model, Math. Biosci. Eng.: MBE [32] R.G. Letsholo, Marius Pretorius, Investigating managerial practices for data
|
||
19 (2022) 11800–11820, http://dx.doi.org/10.3934/mbe.2022550. and information overload in decision making, J. Contemp. Manag. 13 (2016)
|
||
[20] Wil Aalst, Process Mining: A 360 Degree Overview, ISBN: 978-3-031-08847-6, 767–792.
|
||
2022, pp. 3–34, http://dx.doi.org/10.1007/978-3-031-08848-3_1. [33] Ashley Braganza, Laurence Brooks, Daniel Nepelski, Maged Ali, Russ Moro,
|
||
[21] Shideh Saraeian, Babak Shirazi, Process mining-based anomaly detection of ad- Resource management in big data initiatives: Processes and dynamic capabilities,
|
||
ditive manufacturing process activities using a game theory modeling approach, J. Bus. Res. 70 (2016) http://dx.doi.org/10.1016/j.jbusres.2016.08.006.
|
||
Comput. Ind. Eng. 146 (2020) 106584, http://dx.doi.org/10.1016/j.cie.2020. [34] Anam Nusrat, Yong He, Adeel Luqman, Ankit Mehrotra, Amit Shankar, Un-
|
||
106584. raveling the psychological and behavioral consequences of using enterprise
|
||
[22] Claudio Castiglione, Automated generation of digital models for manufacturing social media (ESM) in mitigating the cyberslacking, Technol. Forecast. Soc.
|
||
systems: The event-centric process mining approach, Comput. Ind. Eng. (ISSN: Change (ISSN: 0040-1625) 196 (2023) 122868, http://dx.doi.org/10.1016/j.
|
||
0360-8352) 197 (2024) 110596, http://dx.doi.org/10.1016/j.cie.2024.110596, techfore.2023.122868, URL: https://www.sciencedirect.com/science/article/pii/
|
||
URL: https://www.sciencedirect.com/science/article/pii/S0360835224007174. S004016252300553X.
|
||
[23] Amitava Mukherjee, Chong Zhi Lin, Michael Boon Chong, Comparisons of [35] Martin Eppler, Jeanne Mengis, The concept of information overload: A re-
|
||
some distribution-free CUSUM and EWMA schemes and their applications in view of literature from organization science, accounting, marketing, MIS, and
|
||
monitoring impurity in mining process flotation, Comput. Ind. Eng. (2019) related disciplines, Inf. Soc. 20 (2004) 325–344, http://dx.doi.org/10.1080/
|
||
http://dx.doi.org/10.1016/j.cie.2019.106059. 01972240490507974.
|
||
|
||
|
||
|
||
|
||
20
|
||
|