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