Business Intelligence and Business Process Management in the Era of Generative AI: A Review of Big Data Analytics, Process Mining, and Decision Support Systems

Abstract

Business intelligence (BI) and business process management (BPM) have traditionally addressed related managerial problems from partly separate perspectives, while big data analytics, process mining, generative AI, and decision support systems are increasing the pressure toward integration. This review examines how these domains relate within a shared business-processing and decision-making context. Methodologically, the paper adopts a narrative review approach based on peer-reviewed literature published from 2015 onward, drawing on Google Scholar, Scopus, and Web of Science, and synthesizes the literature thematically across conceptual foundations, data and computational infrastructures, process intelligence, generative AI, application domains, and implementation tensions. The review finds that the literature does not support the claim that these areas have already converged into a stable, unified field. Instead, it shows a gradual movement toward a layered architecture in which BI and business analytics support organizational insight, BPM and process mining provide process intelligence, big data analytics supplies the evidentiary and computational base, generative AI functions as an interaction and augmentation layer, and decision support systems translate these elements into managerial action. The paper concludes that this emerging integration is meaningful but still uneven, with its practical value depending on interoperability, evaluation realism, governance, and the preservation of human oversight in AI-supported business processes.

1. Introduction

Business intelligence (BI) and business process management (BPM) have long addressed related managerial problems but they have usually done so from partly different starting points. BI research has tended to emphasize data infrastructures, reporting, analytics use, and the organizational conditions under which information is converted into better decisions. BPM, by contrast, has focused more directly on the modeling, execution, monitoring, and redesign of processes. This division has been useful for building specialized research streams, yet it also leaves an incomplete account of how organizations actually move from data to process change and from process change to managerial action. Recent literature still reflects this partial separation, even though the practical problems faced by firms increasingly cut across both domains [1,2,3].

That separation has become harder to sustain in digital operating environments shaped by large-scale event data, cross-functional transaction records, and increasingly continuous performance signals. In this context, big data analytics is not simply a matter of scale. It changes what organizations are able to observe, model, and intervene in across operational processes. At the same time, the evidence is less straightforward than the rhetoric often suggests. Recent review work shows that many big data analytics investments still struggle to deliver expected value, partly because technical capability, system use, and organizational learning are often examined as disconnected streams rather than as parts of a coherent decision architecture. Parallel developments in BPM point in a similar direction: machine learning and process mining are extending process management from descriptive monitoring toward prediction, recommendation, anomaly detection, and resource allocation. The result is not a fully unified field but a much stronger structural pressure toward integration than the earlier BI or BPM literature usually assumed [3,4,5].

Generative AI (or GenAI) intensifies this shift because it affects not only automation but also the way managers and analysts interact with process knowledge and analytical output. Recent BPM scholarship presents genAI as a potential layer for process knowledge acquisition, synthesis, and interaction, while emerging work in business analytics and decision-making suggests that GenAI may alter how analytical results are queried, summarized, explained, and communicated to decision makers. Even so, the literature remains uneven. Claims of transformation are growing faster than evidence on reliability, governance, and decision quality in real organizational settings. Much of the current work is still organized around specific tools or isolated use cases, which makes it difficult to understand how genAI fits into a broader architecture linking data, processes, organizational intelligence, and managerial decision support [6,7,8].

This review addresses this gap by examining BI, BPM, big data analytics, process mining, GenAI, and DSS within a single business-processing and decision-support perspective. The unresolved problem in the literature is not the absence of studies on these domains individually, but the lack of a clear integrative account of how they relate when organizations attempt to connect data infrastructures, process evidence, AI-enabled interaction, and managerial action. Rather than assuming that these streams have already converged into one stable field, the paper treats their relationship as an evolving and uneven integration problem. Its objective is therefore to synthesize the relevant literature, clarify the conceptual role of each domain, and propose a layered framework that explains how organizational insight, process intelligence, GenAI-based augmentation, and decision support can be connected. The contribution of the review lies in this integrative architecture: it distinguishes the functions of each layer, identifies the tensions that constrain their practical use, and provides a basis for interpreting application domains where business analytics, process management, and AI-supported decision-making increasingly intersect.

The paper makes three specific contributions:

• First, it reframes the relationship between BI, BPM, big data analytics, process mining, GenAI, and DSS as a layered business-processing architecture rather than as a loose combination of adjacent technologies.
• Second, it clarifies the distinct role of each layer: BI and business analytics provide organizational insight, BPM and process mining provide process intelligence, big data analytics supplies the evidentiary and computational base, GenAI supports interaction and knowledge augmentation, and DSS translates these elements into managerial action.
• Third, it identifies the main implementation tensions that limit this integration in practice, including interoperability, data quality, evaluation realism, governance, accountability, and human oversight.

In doing so, the review offers a conceptual framework that can guide future empirical research and help organizations interpret how these technologies may be combined without overstating their current maturity.

2. Methods

This paper adopts a narrative and conceptual review design rather than a PRISMA-style systematic review, bibliometric study, or meta-analysis. This choice reflects the nature of the research problem. The relationship among business intelligence (BI), business process management (BPM), big data analytics, process mining, genAI, and decision support systems (DSS) is not yet organized as a single mature evidence base with comparable empirical designs, shared metrics, or stable units of analysis. The relevant literature is instead distributed across information systems, management, computer science, operations, analytics, and organizational decision-making. Under these conditions, a conceptual review is appropriate because the objective is not to aggregate statistically comparable findings, but to organize a heterogeneous body of knowledge, clarify relationships among adjacent streams, and develop an integrative interpretation of an emerging research area. Cooper’s taxonomy of knowledge syntheses is useful in this respect, since it recognizes that literature reviews may differ in focus, goal, coverage, organization, perspective, and intended audience, rather than following one single methodological form [9].

The review was guided by three research questions.

• RQ1 asks how BI, BPM, big data analytics, process mining, GenAI, and DSS relate to one another within contemporary business-processing environments.
• RQ2 asks what conceptual roles these domains play when they are examined as parts of an integrated decision-support architecture rather than as separate technology streams.
• RQ3 asks what implementation tensions limit the practical use of such integration in organizational settings.

These questions are intentionally conceptual and synthetic. They do not seek to estimate effect sizes, rank techniques, or produce an exhaustive inventory of all publications in each field. Instead, they guide the review toward the identification of conceptual links, areas of convergence, unresolved tensions, and practical implications for organizations that combine analytical, process-oriented, and AI-supported capabilities.

The search strategy was designed to balance breadth with relevance. The review drew on Google Scholar, Scopus, and Web of Science in order to capture peer-reviewed work across information systems, business and management, analytics, computer science, and operations-related outlets. The search window covered publications from 2015 onward, reflecting the period in which process mining, big data analytics, AI-enabled business processing, and more recently genAI began to form a more connected discussion in the literature. Earlier sources were used selectively when they provided methodological or theoretical foundations for review design or conceptual synthesis. Eligible sources included peer-reviewed journal articles, conference papers, and scholarly book chapters published in English. Editorials, dissertations, preprints, vendor white papers, promotional materials, and non-scholarly reports were excluded because the paper aims to synthesize academic knowledge rather than market commentary or practitioner claims.

Search terms were developed around the core concepts of the review and combined in different ways across databases. These included business intelligence, business analytics, business process management, process mining, process intelligence, big data analytics, decision support systems, artificial intelligence, machine learning, genAI, large language models, workflow automation, and digital business processes. The search was not treated as a mechanical keyword-counting exercise. Initial screening was based on titles, abstracts, and keywords, while full-text reading was used to determine whether a source made a meaningful contribution to at least one of the paper’s central domains and, more importantly, whether it helped explain relationships among these domains in business-processing contexts. A source was considered to make a meaningful contribution when it clarified a conceptual relationship among the reviewed domains, provided empirical or technical evidence about their use in business-process settings, identified implementation or governance constraints, or supported the development of the layered framework proposed in the review.

The review procedure followed four analytical steps. First, the literature was identified across the databases and search terms described above. Second, sources were screened for conceptual and contextual relevance, with emphasis on work that addressed BI, BPM, analytics, process mining, GenAI, DSS, or their intersections. Third, the selected literature was grouped into thematic clusters: conceptual foundations of BI, BPM, and DSS; big data analytics as a data and computational layer; process mining and process intelligence; GenAI in business-processing environments; integrative decision-support architectures; application domains; and implementation tensions. Fourth, the thematic clusters were compared across streams in order to identify how each domain contributes to an integrated business-processing architecture and where the literature remains fragmented or empirically underdeveloped.

The inputs to the review were therefore not limited to one narrowly defined empirical corpus. They included conceptual papers, review articles, empirical studies, technical studies, and application-oriented research that helped explain how analytical, process-oriented, and AI-supported systems are being connected in organizational settings. The outputs of the review are correspondingly conceptual rather than statistical. They include a thematic synthesis of the literature, a layered integrative framework linking BI, BPM, big data analytics, process mining, GenAI, and DSS, and an application-oriented discussion of how this framework can be interpreted across organizational domains. The final synthesis was thematic rather than bibliometric. Attention was given not only to reported opportunities but also to conceptual tensions, implementation limits, governance concerns, and areas where technological claims remain stronger than empirical evidence. This procedure preserves methodological transparency while remaining proportionate to the paper’s purpose: to develop an integrative and critically informed review without presenting the study as a formal evidence-aggregation exercise.

3. Conceptual and Theoretical Foundations

3.1. Business Intelligence and Business Analytics

Business intelligence (BI) is best understood not simply as a set of dashboards, reports, or data warehouses but as an organizational capability for converting dispersed data into usable managerial insight. In that sense, BI sits at the intersection of information infrastructure, analytical routines, and decision-oriented interpretation. This matters because the term is often used too loosely in both practice and research. Some studies reduce BI to technological architecture, while others treat it as almost synonymous with business analytics. The distinction is useful, however, because BI traditionally emphasizes the collection, integration, visualization, and dissemination of information for decision support, whereas business analytics extends more explicitly into statistical modeling, prediction, optimization, and pattern discovery. The two domains overlap substantially, but they are not identical, and treating them as interchangeable can blur important differences in how organizations generate, interpret, and act on evidence [1,2].

Viewed more carefully, BI and business analytics are less a pair of competing labels than a layered capability set. BI provides the informational visibility required for managerial awareness, while business analytics deepens that visibility through more advanced analytical reasoning. Yet the literature also shows that neither creates value automatically. Firms do not become more intelligent merely because they possess more data, more sophisticated software, or more elaborate reporting systems. The organizational problem is interpretive as much as technical. Insight depends on whether data are translated into decision-relevant forms, whether managers trust and use them, and whether analytical outputs are connected to actual business processes rather than remaining isolated in reporting environments. That is why more recent work increasingly shifts from a narrow technology view toward questions of usage, affordances, analytical culture, and decision-making context [10,11].

This broader view also clarifies why business analytics should not be presented as a purely technical progression beyond BI. Its contribution lies in expanding the organization’s capacity to explore patterns, anticipate outcomes, and compare alternative courses of action. At the same time, the empirical literature remains more cautious than much of the managerial rhetoric. Reported performance gains are often mediated by complementary capabilities such as absorptive capacity, organizational learning, process alignment, and a culture that supports data use rather than treating analytics as an external expert function [12,13].

For the purposes of this review, BI and business analytics are therefore treated as the organizational insight layer of digital business processing. Their central role is not to replace judgment or to operate independently of process knowledge but to structure how evidence becomes visible, interpretable, and actionable inside organizations. This positioning is important because it prevents BI from being reduced to retrospective reporting and prevents analytics from being overstated as a self-sufficient decision mechanism. In practice, both derive much of their value from how well they connect with process management, process data, and decision support structures across the firm [14].

3.2. Business Process Management

Business process management (BPM) is commonly understood as the discipline concerned with how organizational processes are modeled, analyzed, redesigned, implemented, and monitored over time [15,16]. Its focus is broader than workflow automation alone. While automation is one important component, BPM is better seen as a managerial and socio-technical approach to organizing work through processes, with attention to efficiency, coordination, control, flexibility, and continuous improvement. This broader interpretation matters because a narrow automation-centered view tends to reduce BPM to software execution, whereas the discipline itself has evolved around a wider set of concerns, including process design, process performance, interoperability, governance, and, more recently, data-intensive forms of process analysis [17].

A useful feature of BPM is that it treats processes as units of organizational analysis rather than as isolated tasks or departmental routines. This allows firms to examine how activities connect across functions, where delays or redundancies emerge, how handoffs affect quality, and where redesign may generate value. In practice, this gives BPM both a diagnostic and an intervention-oriented role. It not only documents how work is currently performed; it also supports structured change through redesign, standardization, execution support, and performance monitoring. That is one reason BPM has remained relevant under digital transformation rather than being displaced by it. If anything, digital transformation has made BPM more necessary, because organizations increasingly need ways to connect technological change with end-to-end process consequences instead of treating innovation as a series of disconnected system deployments [18].

At the same time, BPM should not be portrayed as a stable or closed discipline. Recent work shows that its boundaries are expanding as digital technologies create new redesign possibilities and new sources of process evidence. Business processes are no longer improved only through expert modeling and periodic review; they are increasingly examined through event data, analytical signals, simulation, and process-aware digital infrastructures. This does not invalidate the classical BPM lifecycle, but it does shift the discipline toward more adaptive, data-informed, and technology-mediated forms of process management. In that sense, BPM provides the process layer of the present review: it is the domain in which organizational activities are represented, evaluated, improved, automated where appropriate, and connected to broader systems of intelligence and decision support [17,19].

This process-centered view also explains why BPM cannot be separated from decision support. Once processes are modeled, monitored, or redesigned, organizations still need mechanisms that translate process knowledge into choices, interventions, and accountable managerial action.

3.3. Decision Support Systems

Decision support systems (DSS) occupy the decision-facing end of the analytical chain. Rather than generating data or modeling processes themselves, they organize, present, and operationalize analytical outputs in forms that can inform managerial choice. In that sense, DSS should not be reduced to a software category inherited from earlier information systems literature. More recent work shows that the field continues to evolve around the broader problem of enhanced decision making in organizational settings, including questions of functionality, evaluation, interfaces, implementation, and impact [20]. A useful way to position DSS in the present review, then, is as the layer through which information, models, and process insights are translated into alternatives, recommendations, warnings, or action-relevant scenarios for decision makers.

Sturm et al. [21] make this point indirectly but clearly in their study of machine-learning advice in managerial decision-making. Their findings show that analytical advice does not improve outcomes simply by being technically available; its influence depends on whether decision makers actually use it, and that use is shaped by information quality, transparency, and trust in those who produce the analytical output. This is precisely where DSS becomes important. A decision support system is not only a carrier of recommendations. It is also a mediating structure that affects whether analytical content is understandable, credible, timely, and usable enough to enter managerial judgment in the first place. Seen from that angle, DSS links analytics to action, but it also exposes the fragile point at which sophisticated models may fail to affect real decisions.

Recent literature also suggests that stronger technical sophistication does not automatically produce better decision support. Sáenz-Royo and Chiclana [22], for example, argue that increasing the informativeness and complexity of a DSS may raise costs without proportionate gains in efficiency. That point is worth emphasizing because decision support is often discussed as if better algorithms naturally imply better managerial outcomes. In practice, organizations face trade-offs among informational richness, interpretability, responsiveness, and implementation burden. Terrien et al. [23] reach a related conclusion from a different angle by arguing for human-centered DSS design that keeps supervisors at the core of decision processes and evaluates systems not only by technical performance but also by usability, acceptability, and effectiveness. Even recent review work on explainable AI-based DSS points in the same direction, namely that contemporary decision support increasingly depends on whether systems can make their reasoning sufficiently interpretable for human users rather than merely more accurate in abstract computational terms [24].

For this review, DSS is therefore treated as the managerial action layer of digital business processing. BI and business analytics may generate organizational insight, BPM and process mining may reveal and optimize process behavior, and big data infrastructures may supply the evidentiary base, but those outputs still need to be converted into decision-relevant forms. DSS is where that conversion becomes visible. It is the layer in which evidence is framed for choice, uncertainty is made navigable, and organizational actors decide whether analytical recommendations will actually shape action.

3.4. Why Integration Matters

The need to integrate BI, BPM, and DSS follows from a simple but often underexamined problem: organizations do not create value from data, process models, or recommendations in isolation. They create value when these elements are connected in ways that support coordinated action. Yet much of the literature still examines them as partially separate capabilities, even though business operations increasingly depend on their interaction rather than on their standalone sophistication [25,26].

When BI is weakly connected to BPM, it often remains primarily descriptive. Trieu [25] makes this problem visible in a different way by showing that BI research has paid considerable attention to the conditions for obtaining value from BI systems but much less attention to the actual organizational processes through which that value is realized. In practice, this means that firms may build reporting capacity, performance dashboards, and analytical visibility without creating an equally strong understanding of how those insights should translate into process redesign or operational intervention. A related point appears in more recent work on managerial analytics use. Orjatsalo et al. [27] show that top managers strongly rely on business analytics for monitoring current performance and taking corrective action, but they also complement it with other forms of knowledge when decisions become more complex and forward-looking. That is not a weakness of analytics in itself. It shows, rather, that insight detached from process context can inform awareness without fully grounding organizational change. BI is therefore necessary but on its own it can stop at visibility.

The reverse limitation also matters. BPM without strong analytics can remain procedural, overly model-centric, and insufficiently responsive to the variability of contemporary digital operations. Mendling et al. [18] argue that BPM needs a broader agenda in a world shaped by digital innovation, precisely because process thinking cannot rely only on static design logics or periodic improvement cycles anymore. Weinzierl et al. [5] reinforce this shift by showing how machine learning is now entering multiple BPM lifecycle phases, from prediction and recommendation to anomaly detection and resource-related tasks. In parallel, Cappiello et al. [28] demonstrate that even process performance indicators depend on the quality and measurability of event-log data, which means that process management is only as informative as the evidentiary base supporting it. Without analytics, BPM may still provide structure and control, but it risks becoming procedural in the narrow sense: able to describe and formalize work, yet less capable of detecting emerging variation, forecasting outcomes, or supporting timely intervention.

The same logic extends to decision support systems. DSS may present alternatives, rankings, predictions, or recommendations, but these outputs are less convincing when they are not grounded in both reliable analytical evidence and process understanding. Sturm et al. [21] show that decision makers do not simply absorb machine-generated advice; they evaluate whether it is sufficiently trustworthy and useful to enter judgment. Kostopoulos et al. [24] reach a similar conclusion from the perspective of explainable AI-based DSS, where interpretability becomes central to whether analytical reasoning can meaningfully support action. A DSS built without BI and BPM may still look technically sophisticated, but it is more likely to be weakly grounded: rich in outputs, yet thinner in organizational relevance, process sensitivity, and decision credibility.

For that reason, integration matters not because every organization must adopt one grand unified architecture but because decision quality depends increasingly on the alignment of these layers. BI contributes visibility, BPM contributes process logic, analytics contributes evidentiary depth, and DSS translates these into managerial action. When these remain disconnected, organizations often end up with one-sided capability: reporting without redesign, process formality without analytical depth, or recommendations without sufficient operational grounding.

The next question is therefore not simply whether BI, BPM, and DSS should be integrated, but what kind of data and computational base makes such integration possible. This shifts the discussion from conceptual alignment to the evidentiary layer on which contemporary business-processing systems increasingly depend.

4. Big Data Analytics as the Enabling Data and Computational Layer

Big data analytics functions in this review as the enabling data and computational layer that makes contemporary business processes observable and analytically tractable at a scale that older information architectures handled only partially. Its importance does not lie in volume alone but in the growing availability of heterogeneous digital traces, including event logs, transactional records, interaction data, and streaming signals, which can be combined to support richer forms of monitoring, prediction, and process-level analysis. Recent literature increasingly suggests that the business value of big data depends less on data accumulation as such and more on how data are mobilized for use, interpreted in context, and linked to organizational action [4]. In process-oriented environments, this is especially significant because analytical capacity now depends on infrastructures that can capture, integrate, and process evidence from multiple operational layers rather than from isolated systems or periodic reports [29]. Under these conditions, big data analytics is not peripheral to BI, BPM, or decision support. It provides the underlying evidentiary and computational basis on which those capabilities increasingly depend.

4.1. Data Sources in Digital Business Processes

The data sources that sustain digital business processes are broader than the traditional image of structured enterprise databases. In process-oriented settings, the most immediate and analytically valuable sources are event logs extracted from operational information systems, where activities are recorded with some combination of case identifiers, timestamps, resources, and status information. De Weerdt and Wynn [30] stress that process event data form the basic evidentiary layer for process mining because they capture execution trails rather than isolated snapshots. Badakhshan et al. [29] extend that view by showing that process mining creates value precisely because it turns these digital traces into end-to-end visibility about how business processes actually unfold. This makes transactional records from ERP, CRM, SCM, HRM, and service systems especially important, not because they are automatically “big data” but because they provide process-linked observations at a scale and granularity that can support monitoring, diagnosis, and intervention.

At the same time, digital business processes increasingly generate data outside conventional back-end systems. Abb and Rehse [31] show that user interaction logs capture low-level interface actions such as clicks, typing, field selections, and navigation behavior, which makes them relevant for task mining, robotic process automation, and process-related usability analysis. These logs add a layer of behavioral detail that classic enterprise records often miss. A different but related expansion appears in customer-facing environments. Lundin and Kindström [32] argue that digitalized customer journeys involve a growing range of touchpoints and process extensions, which means that customer interactions themselves become process-relevant data rather than merely marketing observations. As a result, process evidence now includes not only internal transactions but also front-end interactions that reveal how users move through service, sales, and support environments.

Another stream comes from sensor-based and streaming environments. Brzychczy et al. [33] show that IoT and sensor data can widen the analytical scope of process mining, especially in settings where physical operations and digital control systems are increasingly intertwined. That possibility is important, but it also comes with a methodological complication: raw sensor data are not processed events by default. They usually need abstraction, contextualization, and transformation before they can support process-level analysis. A similar point appears in the streaming process literature, where Soffer et al. [34] note that event streams open the door to continuous and near-real-time process analysis but they also challenge the assumptions behind batch-oriented logs and stable historical datasets. In practical terms, this means that contemporary business processes may be observed through a mix of finite logs, interaction traces, and ongoing streams rather than through one clean and uniform source.

A further extension, still emerging but relevant for future business-process analysis, concerns multimodal process data. Traditional process mining relies mainly on structured event logs from information systems, but not all organizational work leaves clean digital traces. Manual, physical, service, and knowledge-intensive activities may be only partially captured in ERP, CRM, or workflow systems. Gavric et al. [35] show how raw and unstructured evidence from video, audio, and sensor data can be transformed into structured event-log representations while preserving a human-in-the-loop role in interpretation and validation. Chen et al. [36] similarly demonstrate that video data can support process model extraction and conformance checking when conventional logs are unavailable, incomplete, or noisy. This direction broadens the meaning of “big data” in business-process settings: process evidence may increasingly come not only from system-generated events, but also from multimodal traces that require interpretation, alignment, privacy protection, and careful validation before they can support process intelligence.

What matters for the present review is not simply that more data sources exist but that digital business processes are now recorded across multiple layers of organizational activity. That broader evidentiary base is what gives big data analytics its relevance here. Still, these sources are not automatically ready for business intelligence, process mining, or decision support. De Weerdt and Wynn [30] point out that data extraction and correlation remain central challenges because source systems are rarely designed with a process perspective in mind. Abb and Rehse [31] reach a comparable conclusion from the side of UI logs, where differences in conceptualization and implementation can obstruct integration across tools and settings. So, the significance of big data in digital business processes lies less in volume alone and more in the growing availability of heterogeneous, process-relevant traces that must be made analytically coherent before they can support managerial insight.

Figure 1 summarizes the main categories of data sources that feed process data analysis in digital business environments.

4.2. Big Data Characteristics and Computational Implications

The characteristics that make data “big” in business-process settings are not reducible to size alone. Volume still matters, especially when organizations accumulate large numbers of event records, transactions, user actions, and machine-generated observations across multiple systems. Yet velocity and variety are often just as consequential. Continuous process execution generates data that arrive quickly, change frequently, and emerge in different formats, from structured enterprise records to semi-structured logs and streaming signals. As Iqbal et al. [37] note in their survey of big data analytics, these characteristics reshape analytical requirements because conventional architectures are poorly suited to environments marked by scale, heterogeneity, and rapid data generation. In business terms, this means that digital processes increasingly depend on infrastructures able not only to store data but also to ingest, relate, and analyze it under tighter temporal constraints.

Velocity has particularly important implications for process-oriented analytics. Lalaoui et al. [38] argue that real-time big data environments require architectures designed around low-latency ingestion, continuous processing, and high availability rather than around periodic batch execution alone. That distinction matters in digital business processes, where delayed analysis can limit the practical value of otherwise rich data. A process may be fully recorded, yet still poorly managed if evidence becomes actionable only after the relevant operational window has passed. This is why contemporary data environments increasingly rely on distributed pipelines, streaming frameworks, and scalable storage systems. The computational issue is therefore not only how much data an organization possesses but how quickly relevant parts of that data can be transformed into usable process insight.

Variety creates a different challenge. Dong and Yang [39] show that the business value of big data analytics depends on the interaction of multiple technical and organizational components, not on data abundance in isolation. In process environments, that interaction becomes difficult when records come from systems designed for different purposes and levels of granularity. Transactional data, clickstreams, interaction logs, IoT signals, and external inputs may all be relevant, but they rarely arrive in analytically aligned form. Integration, correlation, and contextualization therefore become computationally central tasks. This is one reason why big data analytics in business processing is inseparable from data engineering choices and data quality management [40]. Analytical models and dashboards often receive most of the attention, but their usefulness depends heavily on the less visible work of data preparation, synchronization, and architecture design.

Recent work on Big Data Analytics Systems adds a system-development perspective to this point. Montoya-Murillo et al. [41] show that BDAS implementation cannot be reduced to analytical techniques or platform selection alone, since organizations also need development life-cycle structures that define roles, phases, activities, and work products. This is especially relevant for business-process environments, where analytical outputs must be embedded into operational systems rather than treated as detached reporting artifacts. A related empirical complication is that more data does not necessarily mean better decisions. Ghasemaghaei and Calic [42] show that big data can improve firm decision quality but only indirectly, through data quality and data diagnosticity. In fact, some dimensions of data quality benefit from big data processing, while intrinsic quality may suffer when scale and heterogeneity increase. Li et al. [43] reach a complementary conclusion by showing that big data analytics usage improves decision-making quality through the development of stronger data analytics capabilities rather than through mere adoption. These findings suggest that the computational implications of big data are not limited to storage or processing capacity. They also concern the ability to preserve relevance, interpretability, and reliability as data environments become larger, faster, and more fragmented [44]. For this review, that is the critical point: big data matters because it expands the evidentiary base of digital business processes, but its value depends on whether computational infrastructures and organizational capabilities can make that evidence analytically usable.

4.3. Analytical Capabilities for Business-Process Environments

What big data analytics adds to business-process environments is not a single analytical function but a widening set of capabilities that allow organizations to observe, interpret, and intervene in process execution with more precision than traditional reporting systems typically allow. At the most basic level, these capabilities remain descriptive: they help organizations reconstruct process flows, identify bottlenecks, compare variants, and monitor operational performance. Yet, contemporary process environments increasingly require more than retrospective visibility. Process analytics now extends into predictive, prescriptive, and explainability-oriented tasks, which means that the analytical layer is becoming progressively more intertwined with operational decision-making rather than remaining an after-the-fact evaluation tool [45,46].

One major capability is predictive monitoring. Instead of limiting analysis to completed traces, process analytics can estimate likely future states of running cases, including remaining time, probable outcomes, next events, or risk of deviation. This has moved process-oriented analytics closer to real operational support, especially in settings where delays, failures, or undesirable outcomes need to be anticipated before the case is completed. The literature on predictive process monitoring has developed substantially in this direction, but it also shows that prediction quality depends heavily on feature engineering, benchmark design, and the comparability of evaluation settings rather than on model choice alone [45,47]. In other words, analytical capability here is not just a matter of forecasting power. It also involves methodological discipline in how processed data are transformed into decision-relevant signals.

Analytical capabilities become even more significant when they support intervention. Recent work on process-aware decision support systems shows that process and business data can be combined to generate case-level recommendations and explainable predictions for live workflow decisions [48]. A related development appears in resource allocation and runtime optimization, where process analytics is used not only to detect what is happening but to support decisions about how work should be assigned, sequenced, or adjusted under operational constraints [49]. This is an important shift because it moves business-process analytics from passive observation toward action-oriented support. At the same time, the literature remains clear that these capabilities are not universally mature. Resource allocation research, for instance, still shows uneven terminology, limited benchmarking, and a tendency to favor narrower problem formulations over more adaptive, evidence-oriented approaches [49].

A further capability lies in anomaly detection and explanation. In practice, organizations do not only need to know that a process instance is unusual; they also need some basis for deciding whether the deviation is harmful, benign, or worthy of intervention. That is why process analytics is increasingly tied to explanatory functions rather than only to detection accuracy. Work on anomaly detection has already shown the value of combining detection with root-cause support and severity estimation [50], while explainable predictive frameworks point in the same direction by making model outputs more interpretable for business users [51]. Taken together, these developments suggest that the analytical capabilities relevant to digital business processes are now broader than classical process mining alone. They include descriptive reconstruction, multidimensional performance analysis, prediction, recommendation, anomaly diagnosis, and explanation. The practical challenge is no longer whether such capabilities exist but how reliably they can be embedded into real process environments without losing interpretability, comparability, or operational relevance. Figure 2 illustrates the main analytical capabilities through which big data analytics supports monitoring, interpretation, and intervention in business-process environments.

These analytical capabilities explain why big data analytics is treated here as an enabling layer rather than as a separate managerial function. Its value becomes clearer when large-scale and heterogeneous process evidence is converted into process intelligence, which is the focus of the next section.

5. Process Mining and Process Intelligence in Modern BPM

Process mining is the point at which BPM becomes directly connected to digital trace evidence. Instead of relying mainly on interviews, workshops, or idealized process models, it uses event data recorded in information systems to reconstruct how processes actually unfold, where deviations occur, and how performance varies across cases and variants [3,52]. This makes the section especially important for the present review. It is here that BPM, analytics, and operational evidence stop being parallel themes and begin to interact in a concrete way.

At the same time, the literature has moved beyond treating process mining as a narrow technical instrument. Recent work increasingly frames it as part of a broader process intelligence capability that supports process transparency, performance diagnosis, compliance assessment, and business improvement, but only when organizations have the data readiness, governance arrangements, and analytical maturity to use it effectively [29,53]. In other words, process mining is not valuable merely because it discovers process flows. Its value lies in how those discoveries are interpreted, connected to process management, and translated into action.

5.1. Process Mining Foundations and Core Tasks

The foundations of process mining are typically organized around three core tasks: process discovery, conformance checking, and process enhancement. That tripartite structure remains central because it captures the main ways in which event data can be transformed into process knowledge. Discovery aims to derive a process model from recorded event data, that is, to infer the observed flow of activities without starting from an existing formal model [52]. Conformance checking, by contrast, compares recorded behavior with a reference model in order to identify deviations, violations, and mismatches between expected and actual execution [54]. Enhancement goes one step further by enriching or improving process models using event data, often through performance information, bottleneck analysis, or recommendations for process improvement [55]. Together, these tasks explain why process mining sits so naturally between BPM and analytics: it uses computational analysis, but it remains anchored in process understanding.

That conceptual structure is clear, but its practical basis is more demanding than the three labels may suggest. Process mining depends on process event data rather than on generic tabular data, and that difference matters. Event logs need case identifiers, activity labels, timestamps, and enough contextual consistency to reconstruct execution paths in a meaningful way. As De Weerdt and Wynn [30] note, the peculiarities of event data make dedicated analysis techniques necessary; conventional data science assumptions do not always transfer neatly to process-oriented evidence. This is one reason why process mining projects often struggle less with algorithmic choice than with event-log engineering, extraction quality, and data preparation. The process view can only be as reliable as the trace data that sustain it.

Recent reviews also suggest that process mining should not be reduced to control-flow discovery alone. In business settings, organizations want to understand not only activity sequences but also timing, resource behavior, compliance issues, rework, handover patterns, and value implications across the process lifecycle [3]. The field has therefore expanded toward richer forms of process intelligence in which process discovery and conformance analysis are combined with performance monitoring, organizational analysis, and increasingly action-oriented diagnosis. This broader orientation is reflected in the 2022 Process Mining Handbook, which treats event data, discovery, conformance checking, enhancement, monitoring, and adoption challenges as connected parts of one analytical ecosystem rather than as isolated techniques [52,56].

Still, the literature remains careful about the limits of these core tasks. Discovery can generate models that are either too complex to interpret or too simplified to be useful. Conformance checking is analytically powerful, but its results depend heavily on the quality of the reference model and the chosen notion of deviation. Enhancement is perhaps the most managerially attractive task, yet it is also the one most exposed to overclaiming, because identifying improvement opportunities is easier than translating them into sustained organizational change. Marcus et al. [57] make a related point from an organizational angle: technological progress in process mining has advanced more quickly than managerial understanding of how it should be embedded in enterprise settings. For this reason, the foundations of process mining are important not only because they define the field’s core tasks but also because they show where process intelligence begins and where its practical constraints remain.

5.2. Conformance Checking, Discovery, and Enhancement

Although discovery, conformance checking, and enhancement are often presented together as the three core tasks of process mining, they do not contribute equally to managerial understanding. Discovery is usually the entry point because it reconstructs process behavior from event data and reveals variants, loops, fragmentation, and structural complexity that may remain invisible in formal process documentation. Yet discovery is also where one of the field’s oldest tensions appears most clearly: a discovered model may fit the log well while remaining too complex for practical interpretation, or it may be simplified enough to be readable but too abstract to capture relevant behavior. Augusto et al. [58] showed this trade-off very clearly in their benchmark of automated discovery methods, where accuracy and simplicity did not move together uniformly across techniques. A related line of work has tried to improve this situation through stage-based or modular discovery, precisely because flat models often become difficult to interpret when real-life logs are large or behaviorally noisy [59]. Discovery, then, is indispensable, but it is not self-sufficient.

Conformance checking addresses a different problem. Instead of asking what process model can be inferred from the data, it asks how observed behavior relates to an expected or prescribed model. That makes it especially valuable in compliance-sensitive and control-oriented settings, where the key issue is not only understanding how the process runs but also where and how execution departs from intended behavior. Carmona [54] emphasizes that conformance checking effectively links observed and modeled behavior through artifacts such as rule checking, token replay, and alignments, allowing deviations to be diagnosed at a richer conceptual level than raw log inspection would permit. More recent work has also begun to extend conformance logic into settings where data cannot be centralized easily, including federated environments, which shows that the problem is evolving together with organizational data architectures rather than remaining limited to classical single-log analysis [60]. In practical terms, this makes conformance checking one of the strongest bridges between BPM and governance because it brings process expectations, actual execution, and diagnostic evidence into the same analytical space.

Enhancement is often the most attractive task from a managerial perspective because it promises movement from insight to improvement. In principle, enhancement enriches process models with performance, time, cost, or organizational information, making it easier to identify where intervention might be useful. In practice, however, moving from discovered or diagnosed issues to actual improvement is less automatic than the term sometimes implies. Kubrak et al. [61] found that analysts assessing improvement opportunities rely not only on process mining outputs but also on feasibility judgments, stakeholder input, and complementary tools for visualization and analysis. Stein Dani et al. [62] push this argument further by showing that many organizations still struggle to progress from process mining insights to concrete process improvement actions. So, while enhancement is conceptually the step that completes the cycle from observation to action, it is also the point where technical analysis meets organizational constraint most directly. For that reason, these three tasks should not be viewed as a simple linear sequence. Discovery reveals structure, conformance checking evaluates alignment, and enhancement opens the possibility of intervention, but their practical value depends on how they are combined within a broader process intelligence and decision-support setting.

5.3. Predictive Process Monitoring

Predictive process monitoring extends process mining from retrospective analysis toward forward-looking assessment of ongoing cases. Instead of examining completed traces, it focuses on partially executed process instances and estimates their likely future evolution. Typical prediction targets include remaining time, risk of delay, likelihood of non-compliance, or expected outcome quality. This shift is important because it changes the temporal position of analytics within BPM: insight is no longer produced after process completion but during execution, when intervention is still possible [63,64].

Most approaches to predictive monitoring rely on transforming event logs into features that can be processed by machine learning models. Early work used relatively simple encodings of activity sequences, while more recent studies incorporate temporal patterns, resource attributes, and contextual variables to improve predictive accuracy. Deep learning architectures, especially recurrent neural networks and attention-based models, have been widely adopted because they can capture sequential dependencies in event data without requiring extensive manual feature engineering [65,66]. At the same time, classical models remain relevant, particularly when interpretability, stability, or computational efficiency are important considerations.

However, predictive performance alone does not determine usefulness in process environments. One recurring issue is how predictions are integrated into operational decision points. A model that accurately predicts delays or failures may still have limited impact if it does not align with actionable thresholds, response policies, or organizational constraints. Teinemaa et al. [47] note that many predictive monitoring studies emphasize accuracy metrics but give less attention to how predictions translate into interventions. This creates a gap between analytical capability and practical value, especially in settings where decisions involve trade-offs between cost, service quality, and risk.

Another challenge concerns data dependency and generalizability. Predictive models trained on historical logs may perform well within a specific process context but degrade when processes evolve, when new variants emerge, or when external conditions change. This is particularly relevant in digital business environments where processes are continuously adapted through automation, platform changes, or policy updates. As a result, predictive monitoring systems often require ongoing retraining, validation, and recalibration to remain reliable [63]. Without these mechanisms, there is a risk that predictions become outdated while still appearing statistically confident.

A further complication is interpretability. As predictive models become more complex, especially with deep learning approaches, understanding why a certain prediction is produced becomes more difficult. This matters in BPM contexts because managers often need to justify interventions, not just execute them. Recent work has therefore explored explanation techniques that highlight influential events, attributes, or temporal patterns within a trace, but these methods are still evolving and are not always consistent across model types [65]. Predictive process monitoring thus sits at an interesting intersection: it offers clear analytical potential, yet its effectiveness depends heavily on how predictions are interpreted, maintained, and embedded within decision-making routines.

5.4. Process Intelligence Beyond Classical Mining

The notion of process intelligence has gradually expanded beyond the traditional boundaries of process mining. While classical mining focuses on reconstructing and analyzing control-flow behavior from event logs, more recent work positions process intelligence as a broader analytical capability that integrates process data with organizational, contextual, and decision-related information. This shift reflects a recognition that process performance cannot be fully understood through activity sequences alone. Resource interactions, data attributes, external signals, and platform dynamics all shape how processes unfold and how outcomes are produced [67,68].

One direction of this expansion involves the integration of process mining with other analytical paradigms, particularly machine learning and business analytics. Instead of treating event logs as isolated artifacts, researchers increasingly combine them with predictive models, clustering techniques, and pattern recognition methods to uncover deeper regularities in process behavior. This has led to hybrid approaches where process models are enriched with probabilistic or data-driven components, enabling more flexible representations of variability and uncertainty [69,70]. At the same time, these integrations raise methodological questions about model consistency, interpretability, and the balance between data-driven and process-driven representations.

Another important development concerns the move toward multi-perspective analysis. Classical process mining has been strongly centered on control-flow, but real business processes involve additional dimensions such as time, cost, resources, and organizational structure. Process intelligence frameworks increasingly incorporate these perspectives, allowing analysts to examine how different aspects of a process interact and contribute to performance outcomes. For instance, combining organizational mining with performance analysis can reveal not only where delays occur but also how handovers, workload distribution, or coordination patterns influence those delays [52,68]. This broader view aligns more closely with managerial concerns, where process issues are rarely purely structural.

A further extension can be seen in the incorporation of external and real-time data sources. Digital platforms, IoT systems, and customer interaction channels generate continuous streams of information that can complement internal event logs. When these data are integrated into process analysis, they enable a more dynamic understanding of process environments, where external conditions and user behavior can be linked to internal process performance. However, this also introduces additional complexity in terms of data alignment, synchronization, and governance. As noted in recent studies, integrating heterogeneous data sources into process intelligence systems often requires substantial data engineering effort and careful consideration of data quality and consistency [67,69].

Finally, process intelligence is increasingly connected to decision-oriented and interactive systems. Rather than producing static analytical outputs, modern approaches aim to support continuous monitoring, explanation, and intervention within operational workflows. This includes the use of visual analytics, interactive dashboards, and more recently, genAI-based interfaces that can translate process insights into natural language explanations or recommendations. While these developments make process intelligence more accessible to non-technical users, they also raise concerns about reliability, transparency, and over-automation. In particular, there is a risk that complex analytical outputs are simplified in ways that obscure underlying uncertainty or assumptions [67,70]. For this reason, extending process mining into broader process intelligence should not be seen as a purely additive step but as a transformation that requires careful integration between analytical depth and managerial usability.

5.5. Links Between Process Mining, BI Dashboards, and Operational Decision Support

The connection between process mining and business intelligence dashboards becomes important when organizations move from analytical inspection to operational use. Process mining can reveal process variants, bottlenecks, delays, compliance issues, and resource frictions, but these insights do not automatically become managerially usable simply because they are analytically valid. BI dashboards play a different role. They organize, visualize, and communicate information in forms that can support monitoring, interpretation, and action. Recent work on dashboard-based decision-making shows that format, currency, and completeness of information affect decision quality indirectly by reducing perceived task complexity and improving information satisfaction [71]. That finding matters here because process mining outputs often require exactly this kind of translation layer if they are to support operational choices rather than remain confined to specialist analysis.

At the same time, BI dashboards and process mining should not be treated as substitutes. They answer different questions. Dashboards are typically strong at presenting KPIs, trends, alerts, and performance summaries, whereas process mining is stronger at reconstructing how work actually flowed and why specific performance patterns emerged. This is why the integration of the two can be analytically powerful. A dashboard may show that cycle time has worsened or throughput has fallen, but process mining can help uncover whether the cause lies in rework, waiting time, variant proliferation, workload imbalance, or compliance deviation. In that sense, process mining deepens BI by adding process-sensitive explanation to business monitoring, while dashboards broaden process mining by making its outputs more accessible to decision makers who do not work directly with mining tools [72,73].

A similar argument appears in recent work on visual and interactive process analysis. Knowledge-assisted visual process mining has been proposed precisely because automated analysis alone is often insufficient for real organizational interpretation; analysts need interactive visual forms that allow them to combine computational output with domain knowledge and contextual understanding [73]. Work on visual resource analytics points in the same direction by showing that process insights become more useful when they are presented through interactive representations that support tasks such as identifying bottlenecks, workload imbalances, and capacity issues [74]. These developments suggest that the dashboard layer is not a cosmetic add-on. It is part of the analytical interface through which process evidence becomes operationally legible.

The link to decision support becomes stronger when dashboards and process mining move beyond description. Explainable predictive process analytics, for example, has already been implemented in commercial process-mining environments to provide business users with both predictions and intelligible explanations, which helps connect analytical output to intervention decisions rather than passive monitoring [51]. More recent prescriptive work goes further by attempting to convert process diagnostics into actionable recommendations through explicit decision rules and interpretable logic, rather than stopping at bottleneck identification alone [75]. Still, the literature does not suggest that more visualization or more automation automatically leads to better decisions. Dashboard effectiveness depends on configuration, interpretation, and managerial capability, while decision-support mechanisms must remain transparent enough for users to judge their relevance and reliability [71,72]. For that reason, the strongest link between process mining, BI dashboards, and operational decision support lies not in any single tool but in a layered arrangement: process mining produces process-specific evidence, dashboards render that evidence navigable, and decision-support logic helps translate it into operational action.

Process mining and process intelligence show how digital traces can make organizational work more visible, diagnosable, and actionable. The next development is different in kind: genAI does not simply add another analytical technique, but changes how managers and process stakeholders interact with process knowledge, explanations, and decision-support outputs.

6. Generative AI in the BI–BPM Landscape

In the previous sections, we showed how big data analytics and process mining widened the evidentiary base of business processing. GenAI changes a different part of the architecture. Its importance lies less in replacing event-log analysis or predictive models and more in creating a new interaction layer through which managers, analysts, and process stakeholders can query data, synthesize heterogeneous content, draft process artifacts, and receive explanations in natural language. Recent BPM work has framed this shift as a movement toward process-aware foundation models, while business-analytics and decision-support research has treated GenAI more cautiously as an augmentative layer whose value depends on how it is grounded, validated, and governed rather than on novelty alone [6,7,8].

For that reason, GenAI should not be folded into earlier AI/ML discussions as if it were simply a stronger predictive technique. In business-processing settings, generative systems operate on prompts, documents, descriptions, model artifacts, and retrieval pipelines, and they often produce summaries, conversational responses, candidate process models, or explanatory text rather than only scores or classifications. That broadens access to process knowledge, especially for non-specialists, but it also creates new risks: hallucinated outputs, unstable quality across models, and persuasive answers that may exceed the underlying evidence. Recent BPM studies have therefore moved toward process-aware designs and benchmark-based evaluation instead of treating conversational fluency as proof of business usefulness [76,77,78]. Figure 3 illustrates the shift from task-specific AI/ML toward genAI as an interaction and knowledge layer in business process environments.

6.1. From Traditional AI/ML to Generative AI in Business Processing

Traditional AI/ML entered business processing mainly through bounded analytical tasks. Weinzierl et al. [5], in their systematic review of machine learning in BPM, identify recurring uses such as prediction for decision support, discovery-related assistance, and resource allocation. That pattern is revealing. The earlier wave of intelligent business processing was built largely around narrow-task performance: classify an outcome, estimate a delay, detect an anomaly, rank alternatives, or optimize allocation under defined constraints. Even where deep learning was introduced, the dominant logic remained targeted inference on process data rather than open-ended interaction with organizational knowledge.

That earlier tradition remains valuable, but its limits became clearer as business processes grew more document-intensive, cross-functional, and explanation-sensitive. Task-specific models work well when the target variable is explicit, and the evaluation protocol is stable. They are less helpful when analysts need to interrogate textual process descriptions, connect enterprise content to formal process models, or translate technical outputs into language that managers can actually use. Grohs et al. [79] make this contrast directly: earlier NLP-based BPM solutions were usually built for individual tasks, whereas LLMs raise the prospect of a more general-purpose instrument that can span multiple text-related BPM problems. The important point is not that generality has already been achieved but that the field has started to redefine what counts as process support.

Recent BPM studies suggest that GenAI changes the field less by replacing predictive models than by expanding the kinds of process work that can be computationally supported. Grohs et al. [79] show that LLMs can assist with mining imperative and declarative process models from text and with assessing the suitability of process tasks for robotic process automation. Bernardi et al. [76] move further toward process-aware decision support by combining retrieval-augmented generation, fine-tuning, and process-aware chunking so that users can converse with a business-process-aware model. Franzoi et al. [80] similarly argue that LLM-enabled systems can generate process knowledge from diverse enterprise content and make that knowledge usable across different input and output formats. Taken together, these studies indicate a shift toward synthesis, documentation, conversational access, and knowledge mediation, not only toward sharper prediction.

Still, the move from conventional AI/ML to GenAI should not be narrated as a simple upgrade from “older” to “better” intelligence. Kampik et al. [6] describe large process models as a vision, not as a settled architecture, which is a useful corrective to the more promotional parts of the current debate. Benchmark-oriented evidence is even more sobering. Rebmann et al. [77] find that LLMs struggle with demanding semantics-aware process mining tasks when used out of the box or with minimal in-context learning, improving substantially only after fine-tuning. Kourani et al. [78] likewise report marked performance variation across models in business process modeling, and Berti et al. [81] note that while many models can handle some process mining tasks reasonably well, smaller open-source models remain inadequate and evaluation bias is still unresolved. A careful reading of the literature therefore points to complementarity rather than substitution: conventional ML remains central for tightly specified predictive and optimization tasks, whereas GenAI is emerging as an interaction and knowledge layer whose usefulness depends on retrieval design, grounding, and human oversight.

Table 1. Traditional AI/ML and generative AI in business processing.

Dimension	Traditional AI/ML in Business Processing	Generative AI in Business Processing	Source
Predominant data orientation	Mostly structured or process-encoded data, especially event and operational records used for bounded prediction and optimization	Structured plus unstructured material, including text, process descriptions, enterprise documents, prompts, and retrieved knowledge	[5,79,80]
Dominant task logic	Classification, prediction, anomaly detection, resource allocation, narrow-task decision support	Summarization, process knowledge extraction, conversational querying, draft model generation, explanation	[5,76,79]
Typical output form	Scores, labels, rankings, alerts, recommended allocations	Natural-language answers, generated process artifacts, explanatory text, synthesized knowledge	[76,78]
Main strength	Stable performance on clearly specified tasks with known targets and evaluation criteria	Broader accessibility, support for non-specialists, cross-document synthesis, easier interaction with process knowledge	[5,7,80]
Main weakness	Limited support for unstructured process knowledge and natural-language interaction	Hallucination risk, unstable quality across models, strong dependence on prompting, fine-tuning, and grounding	[8,77,78]

summarizes the main differences between traditional AI/ML and genAI in business-processing contexts, with emphasis on their data orientation, task logic, output forms, and practical limitations.

6.2. Generative AI for Querying, Summarizing, and Explaining Business Data

A major practical shift in the BI–BPM landscape is that business data no longer need to be accessed only through fixed dashboards, predefined reports, or specialist-written SQL. Recent work on Text2SQL systems shows that generative models can translate natural-language questions into executable database queries, which lowers access barriers for non-technical users and can shorten the path from question to evidence. Liu and Chu [82] frame this explicitly as a business-intelligence use case, while Ojuri et al. [83] show that LLM-based and agent-assisted query generation can improve real-time analytics workflows. At the same time, the literature is already clear that convenience is not the same as reliability. Bian et al. [84] show that domain-specific querying still suffers from weak schema grounding, insufficient business knowledge, and hallucinated SQL, which is why verification and domain adaptation are not optional add-ons but part of the core design.

The same pattern appears in enterprise question answering and document-level retrieval. In principle, GenAI allows users to query manuals, internal policies, service records, technical documents, and operational knowledge bases through a single conversational interface instead of moving across fragmented repositories. Chen et al. [85] report that a retrieval-augmented system can support interactive industrial knowledge management across internal documents, while Liu et al. [86] show that knowledge-enhanced question answering improves substantially when domain retrieval and classification are combined rather than leaving the model to answer from parametric memory alone. Yet these studies also point to a harder truth: once business querying moves from databases to enterprise documentation, the problem is no longer just language understanding. It becomes a problem of retrieval quality, chunk selection, security, and provenance. Byun et al. [87] make that especially visible in enterprise RAG settings, where answer completeness and data protection have to be balanced rather than assumed to coexist automatically.

Summarization looks easier on the surface, but the literature suggests that it is one of the areas where overconfidence can be most misleading. In business contexts, the attraction is obvious: long reports, dense tables, annual statements, and cross-document evidence can be condensed into short textual narratives. Balsiger et al. [88], however, show that even when LLMs appear competent at extracting and interpreting data from annual financial reports, performance still varies meaningfully across models and error sources remain non-trivial. This matters because a concise summary can hide the exact place where an interpretation drift began. Oral et al. [89], from a decision-support perspective, make a related point more broadly: information presentation is only useful when it supports actual choice rather than merely producing readable output. So, GenAI-based summarization should be treated less as a substitute for analysis and more as a front-end compression layer that still requires traceability to the underlying data.

The explanatory side is more promising but also more delicate than current enthusiasm sometimes suggests. What GenAI adds here is not only automatic description but interactive explanation: users can ask why a pattern appears in a chart, what a model output implies, or how a result should be interpreted under different assumptions. Seo et al. [90] show that LLM-based systems can support interpretation of data visualizations through conversational interaction, and Twitchell et al. [91] similarly find that LLMs can help domain experts interpret complex model outputs when paired with visualization. Even so, both lines of work also expose the limit of the current generation of systems: explanation is helpful when it mediates between technical output and domain judgment, but it becomes risky when fluent narrative is mistaken for faithful reasoning. That is why explanatory GenAI should remain coupled with visualization, source access, and human checking, especially in process-critical or managerially consequential settings.

Table 2. Generative AI interaction modes for querying, summarizing, and explaining business data.

Interaction Mode	Typical Business Use	Main Benefit	Main Limitation	Source
Natural-language querying of structured data	Asking business questions without writing SQL	Reduces technical barriers and speeds access to structured evidence	Vulnerable to schema mismatch, domain hallucination, and logically wrong SQL	[82,83,84]
Grounded question answering over enterprise documents	Querying policies, manuals, service records, and internal knowledge bases	Makes scattered enterprise knowledge more accessible through one interface	Strongly dependent on retrieval quality, chunking, provenance, and security controls	[85,86,87]
Summarization and interpretation of reports and tables	Condensing annual reports, tabular evidence, and long operational documents	Saves time and broadens access to dense materials	Can omit conditions, distort emphasis, and weaken auditability if not linked back to source evidence	[88,89]
Explanation of visualizations and model outputs	Explaining charts, indicators, predictions, and scenario outputs to non-specialists	Improves accessibility and interpretive support for decision makers	Fluent explanations may still misrepresent uncertainty or causal meaning	[89,90,91]

condenses the main ways GenAI is being used to query, summarize, and explain business data, along with the corresponding gains and the weaknesses that the recent literature keeps pointing back to.

6.3. Generative AI for Process Design, Documentation, and Workflow Assistance

GenAI becomes more consequential in BPM when it moves beyond answering questions and starts shaping process artifacts themselves. That includes drafting BPMN models from textual descriptions, helping analysts externalize tacit process knowledge, generating documentation, and supporting workers during modeling or execution. Yet the recent literature does not support the stronger claim that process design can now be delegated to a chatbot in any robust sense. Vidgof et al. [92] framed LLMs as promising for BPM because they can lower entry barriers across multiple process tasks, but newer work suggests that the gains are more convincing in early drafting and interaction than in semantic precision, constraint handling, or formal correctness [93].

The strongest evidence so far concerns process model creation from natural-language descriptions. Nivon and Salaün [94] and Hörner et al. [95] both work on turning textual process requirements or descriptions into BPMN models, which matters because much operational knowledge still exists in prose rather than in formal notations. Even so, both lines of work make the same underlying point: syntactic generation is easier than faithful modeling. A model may look plausible while still misrepresenting control flow, actor responsibilities, or exception handling. Ziche and Apruzzese’s [93] enterprise case study is useful here because it shifts the discussion from laboratory feasibility to actual modeling practice; their findings suggest that LLM-based support can reduce friction and help professionals move faster, but not that it removes the need for experienced modelers. Klievtsova et al. [96] push this even further by explicitly asking whether the chatbot is taking over process modeling; the framing itself is revealing, because the answer emerging from the literature is closer to “not yet, and perhaps not in the fully autonomous way some claims imply”.

Documentation is a different but equally important area. Zhu et al. [97] show that LLMs can be used to generate business process documentation rather than only process diagrams, which is useful because organizations often struggle not with having no process knowledge but with having it scattered across inconsistent documents, emails, internal notes, and partial models. Schinckus et al. [98] treat this more directly as a process knowledge acquisition problem and propose an LLM-supported approach to elicit and structure process knowledge. Schulte et al. [99], by contrast, focus on coherence checking across multi-level process documentation, which is arguably where the literature becomes more mature and more realistic. Fluency alone is not the benchmark. What matters is whether documentation remains consistent across abstraction levels, whether the generated text preserves process logic, and whether contradictions are surfaced rather than hidden behind polished prose. In that sense, GenAI is useful not just for writing process documents faster but for exposing documentation gaps that conventional process repositories often leave unresolved.

Workflow assistance is where the promise becomes attractive, and the risks become sharper. Klievtsova et al. [96] argue for conversationally actionable process model creation rather than single-prompt generation, which is an important distinction because process work is iterative, negotiated, and context-dependent. Pardo Gutierrez et al. [100] reach a compatible conclusion from a human-centered angle with HyperMod, a direct-manipulation interface for LLM-based process modeling. Their design choice matters: users often need controllability and incremental correction, not merely a one-shot output from a model. Bernardi et al. [76] similarly move toward process-aware conversational support for human workers, while Chapela-Campa and Dumas [101] place these developments within the broader shift toward augmented process execution. Taken together, these studies suggest that the near-term value of GenAI in business processing is not autonomous process authorship but mixed-initiative assistance: helping people draft, revise, clarify, and navigate process knowledge while keeping formal validation and organizational accountability in human hands.

6.4. Human–AI Collaboration in Managerial and Operational Decision Contexts

Human–AI collaboration becomes consequential when the issue is no longer only whether a system can generate a recommendation but how judgment, discretion, and responsibility are distributed around that recommendation. Hillebrand et al. [102] are especially useful here because they connect two conversations that are often treated separately: human–AI collaboration in executive decision-making and algorithmic management in control-oriented settings. Read together with Kolbjørnsrud [103], the implication is that collaboration should be understood as an organizational design problem rather than as a generic “human in the loop” arrangement. Adding AI to a workflow does not by itself improve managerial decisions; what matters is who frames the problem, who can contest the output, and who remains accountable for action.

The empirical literature is also more restrained than the dominant managerial rhetoric. Fügener et al. [104] show that hybrid performance improves when AI delegates cases to humans, but not when humans simply hand tasks over to AI. That is a subtle but important finding, because it suggests that productive collaboration depends on how control rights are structured, not merely on whether both actors are present. Choudhary et al. [105] extend the argument by theorizing human–AI ensembles for decision settings in which neither side has a decisive predictive advantage. Many managerial choices look exactly like this: they involve incomplete data, tacit criteria, and unstable environments. In such cases, the realistic objective is rarely full substitution. It is more often a disciplined aggregation of different error patterns and different forms of judgment.

Even so, more AI involvement does not automatically produce better reliance. Westphal et al. [106] find that giving users decision control improves trust, understanding, and compliance, whereas explanations may actually worsen outcomes if they increase cognitive load rather than genuine comprehension. Shang et al. [107] add a further layer by showing that collaboration quality depends jointly on human agency and GenAI agency: on the human side, domain knowledge, desire for control, and the ability to domesticate the tool matter; on the AI side, communication ability and usable memory structures become central. The managerial implication is uncomfortable but necessary: weak human–AI collaboration is not always a pure model problem, yet it is not just a user-training problem either. It often reflects poor alignment among task complexity, interface design, and the actual competencies distributed across the human and machine sides of the arrangement.

Team-level evidence points in the same direction. Zercher et al. [108] report that teams with centralized AI knowledge can make more accurate decisions because they reduce decision-making asymmetries. That result is important, but it should not be romanticized. If only a small subset of a team knows how to interrogate, verify, or strategically use the AI, decision quality may improve while transparency and shared understanding decline. Przegalinska et al. [109] similarly show that collaborative AI does not benefit all task types in the same way; the gains depend on the fit between human capabilities, AI support, and task demands. For managerial work, then, the relevant question is not whether teams use AI at all but whether they have structures that allow AI-mediated knowledge to be challenged, contextualized, and redistributed rather than silently concentrated.

Operational settings make the complementarity even clearer. In airline disruption management, Geske et al. [110] position AI as support for collaborative decision-making across multiple actors rather than as a substitute for that coordination process. Liu et al. [111], in customized bus scheduling, likewise develop a two-stage human–machine collaborative optimization approach because operationally acceptable solutions require more than mathematical efficiency. Field evidence from gig work reaches a similar conclusion from a different angle: Knight et al. [112] show that algorithm-enabled decision support improves performance most clearly among more experienced workers, under a heavier workload, and in more complex tasks. Put together, these studies suggest that human–AI collaboration is strongest when AI absorbs scale, combinatorial complexity, and information overload, while humans retain responsibility for exception handling, contextual trade-offs, and the legitimacy of the final action. That is a narrower claim than autonomy, but it is also much closer to what the evidence currently supports.

6.5. Limits of Generative AI in Process-Critical Environments

The limits of GenAI become sharper once it is inserted into process-critical environments, meaning workflows in which outputs can affect compliance, safety, legal exposure, clinical action, or other decisions that must be traceable and defensible. In those settings, the main problem is not simply that models sometimes make mistakes. It is that fluent generation can obscure uncertainty, compress caveats, and present weakly grounded content in a form that appears operationally ready. Recent work across legal, medical, and process-analysis contexts points in the same direction: plausibility is a poor substitute for source fidelity, semantic precision, and accountable reasoning [77,113,114].

Hallucination remains the clearest technical expression of that problem. Huang et al. [115] synthesize it as a persistent, multi-causal limitation rather than a marginal defect, spanning training data, inference behavior, context use, and evaluation practice. Domain studies make the concern more concrete. Dahl et al. [113] show that legal hallucinations are not rare edge cases but a structural risk in a domain where fabricated authority can mislead even when the prose appears polished. The BPM literature is more restrained but no less revealing: Rebmann et al. [77] find that LLMs struggle on semantics-aware process-mining tasks when used out of the box or with only minimal prompting, which matters because process-critical environments often depend on exact activity meaning, rule interpretation, and sequence logic rather than on approximate textual resemblance. In such cases, an answer that is almost right may still be operationally wrong.

A second limit concerns evaluation. Performance claims are often built on benchmarks that do not fully capture the informational demands of real organizational work. Wornow et al. [116] argue that many foundation-model studies in electronic health records are evaluated on tasks that say little about their usefulness to actual health systems, while Blagec et al. [117] reach a similar conclusion by showing that benchmark datasets can fail to reflect what medical professionals need in practice. That critique travels well beyond healthcare. Process-critical business environments also require robustness to local terminology, exception handling, shifting routines, and audit requirements that generic benchmark success does not necessarily measure. A recent clinical deployment study by Agweyu et al. [118] is instructive here: the system showed relatively low hallucination rates in an electronic-medical-record-embedded setting with physician review, but that result supports a narrow conclusion, not a general one. Safer performance appears possible when the task is bounded, the context is structured, and oversight is built into the workflow; it does not justify unconstrained deployment of generic models into high-stakes processes.

Privacy, security, and governance introduce a further constraint that is especially relevant for enterprise process design. Kibriya et al. [119] distinguish privacy risks arising during both training and inference, including re-identification exposure and leakage of sensitive information, while Das et al. [120] broaden the picture to application-level security and privacy vulnerabilities across domains. Choudhary and Kar [121] take the argument into organizational decision-making more directly by showing that GenAI adoption changes how firms perceive and manage security-rule-violation risks. This matters because process-critical environments not only consume information; they also generate, transform, and redistribute sensitive operational data. Once prompts, retrieved documents, logs, and model outputs become part of business workflows, the question is no longer whether GenAI is useful in the abstract but whether the surrounding process architecture can contain disclosure, manipulation, and compliance failures.

For those reasons, the most defensible position is not rejection, but constraint. In process-critical settings, GenAI is better treated as a bounded assistant for drafting, retrieval, triage, and explanation under source grounding and human review, rather than as an autonomous authority. The stronger the consequences of error, the less acceptable it becomes to rely on generated output that cannot be audited, contested or tied back to verifiable evidence. Current research supports that a narrower, more disciplined role far more convincingly than it supports the language of full decision automation.

Table 3. Main limitations of Generative AI in process-critical environments.

Limitation Category	Why It Matters in Process-Critical Settings	Typical Consequence for Organizations	Source
Hallucination and factual instability	Generated content may be fluent but not faithful to the underlying evidence or rules	Incorrect recommendations, fabricated justifications, false confidence	[113,115]
Semantic imprecision in domain-specific tasks	Near-correct outputs may still fail where sequence logic, rule interpretation, or formal meaning must be exact	Process errors, compliance failures, flawed operational actions	[77]
Weak real-world evaluation	Benchmark success may not reflect local workflows, exception handling, or audit requirements	Overestimation of readiness for deployment	[116,118]
Privacy and security exposure	Sensitive data can be leaked, inferred, or mishandled during training, prompting, retrieval, or output generation	Disclosure risk, regulatory exposure, compromised governance	[119,121]
Limited accountability and auditability	Outputs may be difficult to trace back to verifiable sources or defensible reasoning paths	Reduced contestability, weaker oversight, harder post hoc review	[113,116,118]

summarizes the main limitation categories that constrain the use of GenAI in process-critical environments and clarifies why these problems are not merely technical defects but operational and governance concerns.

As the table indicates, the main barriers to GenAI in process-critical environments are not confined to model accuracy alone; they also concern traceability, evaluation realism, privacy protection, and the organizational ability to contest or verify generated outputs.

These limits are important because they prevent GenAI from being treated as an independent replacement for established BI, BPM, or DSS capabilities. They also prepare the ground for the integrative framework developed next, where GenAI is positioned as one layer within a broader architecture rather than as the organizing logic of the entire system.

7. An Integrative Conceptual Framework for BI, BPM, Big Data, Generative AI and DSS

The main conceptual outcome of this review is an integrative framework that explains how BI, BPM, big data analytics, process mining, GenAI, and DSS can be connected within a shared business-processing architecture. The preceding sections showed that these domains are often discussed in parallel, but in organizational practice they increasingly operate as interdependent layers. BI and business analytics make information visible, BPM and process mining make work traceable, big data analytics expands the evidentiary and computational base, GenAI changes how users interact with process knowledge and analytical outputs, and DSS translates these elements into decision-oriented action. The contribution of the framework is therefore not to merge these domains into one undifferentiated field, but to clarify their distinct roles and the dependencies that connect them [26,122].

The framework is intentionally layered because not all capabilities operate at the same level of managerial work. Some create visibility, some structure process knowledge, some supply computational scale, some support interaction and explanation, and some shape action at the point of choice. This distinction is analytically useful because it avoids two common simplifications: first, the assumption that more analytics automatically produces better decisions, and second, the assumption that newer AI interfaces dissolve older organizational problems of data quality, governance, and capability alignment. Recent reviews of BI&A success and analytics-business alignment suggest a more cautious reading. Value is typically uneven, contingent, and mediated by how well organizations connect technological capability to managerial use, process context, and operational priorities [26,123].

Figure 4 presents this framework as the central synthesis of the review. It shows how data and computation, organizational insight, process intelligence, GenAI-based augmentation, and decision support are linked through feedback loops that allow managerial decisions, process outcomes, and new evidence to reshape one another over time.

7.1. The Organizational Insight Layer: BI and Business Analytics

The first layer of the framework is the Organizational Insight layer, represented by BI and business analytics. Its role is not simply to display data, but to transform dispersed operational, transactional, and contextual inputs into forms that can support managerial interpretation. Phillips-Wren et al. [2] are helpful here because they explicitly reconnect BI, analytics, and DSS rather than treating them as separate eras of information systems. Andoh-Baidoo et al. [124] reach a compatible conclusion from a different angle by showing that BI&A research centers on how organizations harness data assets for value creation. In the present framework, then, BI and business analytics are positioned as the point where raw organizational signals begin to acquire managerial meaning. Before processes can be redesigned or decisions can be supported, relevant states, patterns, and emerging issues have to become visible in a form that organizational actors can actually interpret [2,124].

This layer should also be understood as socio-technical rather than purely informational. Kurpiela and Teuteberg [10] show that business analytics creates value through a set of affordances that span task, technology, actor, and structure dimensions, which is a useful reminder that organizational insight is not produced by software alone. Bayrak [125] makes a related point in more architectural terms by arguing that analytics platforms in distributed organizations need to support not only data access and analysis, but also knowledge dissemination and collaborative decision-making. For the framework proposed here, that means the organizational insight layer includes both infrastructure and interpretive arrangement: data pipelines, reporting environments, analytical models, and also the routines through which insights circulate across managerial levels. Without that broader view, BI is too easily reduced to dashboards and analytics to isolated models, when in practice both work as part of a wider organizational sense-making mechanism [10,122,125].

A more critical point follows from this. The organizational insight layer is necessary, but it is not inherently democratic, nor does it automatically deepen decision quality. Szukits and Móricz [11] show that top management support and perceived data quality strengthen analytical culture, but they also find that the resulting centralization of data use is not itself associated with data-driven decision-making. Ul Ain et al. [123] similarly note that the potential of BI&A systems remains under-realized in many organizations despite technological progress. Taken together, these studies suggest that insight can become bottlenecked at the top, over-concentrated in specialist units, or decoupled from the process settings where action is supposed to occur. In this framework, the organizational insight layer is therefore defined not as a reporting function but as a distributed interpretive capability: it is successful only when the evidence it produces is sufficiently trustworthy, timely, and intelligible to travel beyond analytics specialists and actually inform subsequent process and decision layers [11,123].

7.2. The Process Intelligence Layer: BPM and Process Mining

The second layer of the framework is the Process Intelligence layer, where BPM becomes empirically grounded in execution data rather than relying only on modeled intent, workshops, or managerial assumptions. Its core function is different from that of the organizational insight layer. BI and business analytics make organizational states visible at an aggregate or decision-oriented level, whereas process intelligence reconstructs how work actually unfolds across cases, activities, handoffs, delays, and deviations. Badakhshan et al. [29] describe process mining as a business process intelligence technology precisely because it enables end-to-end process visualization, sense-making, data-driven decision-making, and intervention. In the present framework, then, BPM provides the managerial logic of process design and improvement, while process mining and related methods provide the evidence through which that logic can be tested against operational reality.

That role is becoming broader, not narrower. A useful corrective comes from van der Aalst et al. [126], who argue that process mining can no longer remain confined to workflow-like representations of single-case lifecycles if it is to reflect the complexity of contemporary operations. In other words, the process intelligence layer is not limited to discovering control-flow models from event logs. It increasingly includes multi-object process views, contextual interpretation, resilience analysis, predictive monitoring, and explanation. Franzoi et al. [127] show why this expansion matters: process mining results often remain difficult to interpret when contextual conditions are left implicit. Kraus et al. [128] push the same logic toward resilience by treating process intelligence as a way to assess how processes respond to disruption, not only how they perform under normal conditions. This is an important shift because it moves the layer from descriptive transparency toward operational understanding under changing conditions.

A second issue is usability. Process intelligence is valuable only when the outputs can be understood and acted upon by analysts, managers, and process owners rather than by technical specialists alone. Rizzi et al. [129] are especially relevant here because their user evaluation of explainable predictive process monitoring shows that explanations can support decision tasks, but not in a uniformly simple way; differences in expertise still shape comprehension and use. That finding matters for the framework because it prevents the process intelligence layer from being treated as a purely analytical back end. If process predictions, conformance signals, or bottleneck diagnoses are not interpretable enough to enter organizational reasoning, they remain technically interesting but managerially thin. The layer therefore includes not only mining and prediction, but also the representational and explanatory mechanisms that make process evidence usable.

The literature is equally clear that process intelligence does not mature automatically once event logs exist. Brock et al. [53] show that organizations often face an intention–action gap in process mining and propose a maturity model precisely because readiness depends on more than tool acquisition. Marcus et al. [57] reach a similar conclusion from an organizational angle by mapping different process-mining setups and governance arrangements. Their work is useful for this section because it reminds us that process intelligence is not a self-contained software capability. It has to be embedded through ownership structures, centers of excellence, governance choices, and links to operational decision routines. Without that embedding, the layer can produce isolated diagnostic insight without sustained process change.

7.3. The Data and Computation Layer: Big Data Analytics

The third layer of the framework is the Data and Computation layer, represented by big data analytics. Its role is foundational but not identical to insight generation. This layer captures, stores, integrates, and processes heterogeneous data streams that originate across digital business environments, including transaction systems, process logs, customer interactions, and distributed operational platforms. In the framework proposed here, it should be understood as the enabling base that makes the upper layers possible, not as a substitute for them. Langer’s review [130] of data and analytics maturity models is useful on this point because it shows that organizations need a combination of technical and social capabilities before data can be mobilized effectively. Bayrak [125] reaches a similar conclusion from a platform-design perspective, arguing that distributed organizations require deliberate architectural choices if analytics systems are to support coherent managerial work rather than fragmented local reporting.

A more critical implication follows from the business-value literature. The data and computation layer does not create value simply by accumulating more records or increasing computational scale. Elia et al. [131] show that the strategic value of big data analytics is mediated through value-creation mechanisms such as transparency, access, discovery, and proactive adaptation, which means that the technical layer matters because of what it enables downstream, not because scale is inherently useful. Li et al. [43] similarly find that analytics usage improves decision-making quality through the development of stronger data-analytics capabilities. In other words, the framework should not treat this layer as a passive repository. It is better seen as a capacity for data orchestration and computational readiness that conditions whether business processes can later be monitored, modeled, and acted upon in timely ways.

The literature is equally clear that this layer is constrained by data quality and governance rather than strengthened by volume alone. Ghasemaghaei and Calic [42] show that big data can improve decision quality through data diagnosticity, but they also report that some dimensions of data quality deteriorate as scale and heterogeneity increase, especially intrinsic quality. Shamim et al. [132] reinforce this point by showing that big data management capability is central to decision-making quality. That matters for the present framework because it prevents a common conceptual error: the assumption that the data and computation layer is neutral infrastructure. It is not neutral. If integration rules are weak, metadata are inconsistent, or data stewardship is absent, the upper layers inherit fragility rather than analytic strength. Under those conditions, process intelligence becomes noisier, BI becomes more selective than comprehensive, and decision support becomes harder to trust [42,132].

For all the reasons above, the data and computation layer occupies an intermediate position in the framework. It is lower than the organizational insight and process intelligence layers because it does not itself interpret business meaning, yet it is more than technical plumbing because it determines what kinds of interpretation are even feasible. Chen et al. [133] show that big data analytics capability contributes to strategic decision speed and quality when aligned with business needs, which fits the broader point: computational scale matters only when it is organized for decision-relevant use. In the present framework, then, big data analytics functions as the layer that expands evidentiary scope and processing capacity while also imposing architectural and governance demands that shape everything above it. That is precisely why it deserves a distinct place in the model instead of being collapsed into business analytics in general [130,133].

7.4. The Augmentation Layer: Generative AI

The fourth layer of the framework is the Augmentation layer, represented by genAI. It is positioned differently from the preceding layers because its main contribution is not to generate the primary evidentiary base, nor to model process execution directly, nor to finalize decisions. Its distinctive role is to mediate between those layers by translating data, models, process knowledge, and analytical outputs into forms that people can query, combine, reinterpret, and act upon more easily. Feuerriegel et al. [134] are useful here because they frame GenAI as part of socio-technical systems rather than as a standalone tool category, while Riemer et al. [135] warn against two opposite simplifications: treating it as just another IT artefact or, conversely, anthropomorphizing it as if it were a colleague. In the present framework, that tension is exactly why GenAI is best understood as an augmentation layer. It changes how organizational actors interact with knowledge and analytical artefacts, but it does not dissolve the need for the underlying data, process, and decision structures on which those interactions depend.

What this layer adds is a new form of cross-layer accessibility. Holmström and Carroll [136] distinguish among innovation strategies that vary by automation and augmentation, which is especially helpful here because it shows that GenAI should not be reduced to automation alone. Wessel et al. [137] push the point further by identifying intelligent automation, democratization, hyper-personalization, and collaborative innovation as key mechanisms through which GenAI transforms digital platforms. Abstracted from the platform setting, the broader implication is clear: GenAI expands participation in analytical and process-related work by lowering interpretive barriers, personalizing interactions with information, and enabling more iterative collaboration between human actors and digital systems. For this framework, then, the augmentation layer is where technical outputs become conversational, where process and business knowledge become easier to recombine, and where non-specialists can engage more directly with analytical material that previously required expert mediation.

At the same time, augmentation is not equivalent to admissibility. Mayer et al. [138] show that once GenAI becomes a boundary resource, governance has to adapt because the technology is multi-purpose, opaque, and difficult to standardize in the way older interfaces or APIs were. Saup et al. [139] reach a closely related conclusion in strategic decision-making: GenAI becomes organizationally relevant only when outputs pass admission gates around quality, provenance, explainability, and accountability. That is an important corrective for this layer. GenAI can summarize, draft, personalize, and propose, but those functions strengthen the framework only when organizations decide how generated outputs are validated and when they are allowed to influence formal deliberation. Without such conditions, the augmentation layer risks becoming performative rather than substantive: rich in fluent interaction but weakly anchored in trustworthy organizational use.

A further reason to keep this layer analytically separate is that its value is sharply task-contingent. Dell’Acqua et al. [140] show in knowledge-intensive consulting work that GenAI improves performance for tasks that fall within the technology’s current capability frontier, yet harms performance outside that frontier. Te’eni et al. [141] make the managerial consequence more explicit by arguing that organizations need context-specific learning processes and sandbox experimentation before large-scale rollout, precisely because GenAI introduces multiple uncertainties that cannot be resolved through generic enthusiasm or abstract benchmarking. For the framework proposed here, this means that augmentation should be treated as adaptive and conditional. It can amplify the reach of BI, BPM, big data analytics, and DSS, but only when organizations learn where it genuinely complements human and analytic capability and where it instead distorts, oversimplifies, or overextends it.

So, in the architecture of this review, GenAI is not the new core that replaces the other layers. It is the layer that reconfigures access, interaction, explanation, and recombination across them. That role is strategically important, arguably more important than a narrow focus on isolated chatbot use cases, but it remains derivative in one crucial sense: augmentation is only as strong as the evidentiary, process, and governance foundations it augments.

7.5. The Decision Layer: DSS and Managerial Action

The fifth, and last, layer of the framework is the Decision layer, where analytical outputs, process signals, and generated explanations are converted into alternatives, priorities, interventions, and accountable managerial choices. Its role is therefore not reducible to interface presentation. A decision support system becomes meaningful only when it helps organizational actors move from observation to action under conditions of uncertainty, time pressure, and incomplete knowledge. Chua and Niederman [142] are especially relevant here because they argue that decision support research has leaned too heavily toward technical artefacts while underestimating the socio-technical nature of real organizational problem solving. Handler et al. [143] reach a compatible conclusion from a different angle: once LLMs enter decision support, the field has to rethink not only information collection, but also how alternatives are generated and how final choices are made. In the present framework, then, the decision layer is the point at which the preceding layers are operationalized rather than merely connected.

This layer also makes visible a distinction that is often blurred in discussions of analytics maturity: not every well-designed analytical system is a good decision system. Hjelle et al. [71] show that dashboard effectiveness depends on information format, currency, and completeness, because these features reduce perceived task complexity and improve decision quality indirectly. Terrien et al. [23], in a scheduling context, make the same broader point in more operational terms by insisting on usability, acceptability, and effectiveness while keeping supervisors at the center of the decision process. These findings matter for the framework because they show that the decision layer does not simply “receive” outputs from BI, BPM, or GenAI. It filters them through representational quality and actionability. A dashboard, recommendation engine, or conversational assistant that presents information elegantly but does not support timely intervention is still analytically useful, but it remains weak as a decision layer.

The second function of this layer is evaluative. Decision support is not only about presenting options, but also about helping users judge why one option should be considered more credible, more suitable, or more defensible than another. Coussement et al. [144] argue that explainable AI matters for decision making because it reveals the rationale, strengths, and weaknesses of decision strategies rather than only their predictions. Reis et al. [145] push this logic further by showing that explanation itself may require decision support: organizations may need a context-aware DSS to determine which XAI methods are actually useful for particular stakeholders and business problems. This is an important refinement for the framework. The decision layer is not simply where choices are made; it is also where choices are justified, contested, and adapted to stakeholder needs. Without that evaluative role, managerial action risks becoming either over-automated or weakly grounded.

The literature on managerial analytics use adds one final caution. Orjatsalo et al. [27] find that top managers rely strongly on business analytics for monitoring ongoing performance and taking corrective actions, but they also complement analytics with other knowledge sources when decisions become more strategic and resource-shaping. Storey et al. [146] similarly argue that human-AI systems in decision sciences require socio-technical design, not only technical sophistication. Taken together, these studies suggest that the decision layer should not be treated as the automatic endpoint of a data pipeline. It is the organizational site where evidence, explanation, human judgment, timing, and accountability are assembled into action. For that reason, the present framework positions DSS not as a peripheral add-on, but as the action-conversion layer that determines whether insight actually becomes intervention.

7.6. Feedback Loops Across Layers

What keeps the proposed framework from becoming a static stack of technologies is the presence of feedback loops across layers. The literature on business analytics increasingly suggests that value is created at the process level through repeated cycles of use, interpretation, and adjustment rather than through one-off analytical outputs. Kunz et al. [122] are especially relevant here because they argue that machine-learning-based business analytics shifts value creation toward improved decision-making and feedback mechanisms, while Wang et al. [147] show that even strong analytics capability does not translate into an advantage unless it is assimilated organizationally. In other words, outputs from the upper layers do not simply conclude the process; they re-enter the organization as learning signals that reshape data practices, analytical routines, and subsequent actions.

The same logic applies to BPM and process improvement. Graafmans et al. [148] position process mining within a DMAIC-style improvement cycle, which makes the feedback structure explicit: processes are defined and measured, deviations are analyzed, improvements are implemented, and results are then monitored again. More recent work reinforces this iterative view. Fischer et al. [149] propose portfolio management for process-mining-enabled improvement projects precisely because organizations need an evolutionary roadmap rather than isolated value cases, and Fehrer et al. [150] similarly frame process improvement and innovation systems as mechanisms for generating improved process designs under dynamic conditions. Kurz et al. [151] add an important practical qualification: experimentation and reinforcement-learning-supported process improvement can accelerate adaptation, but only under expert control and with an integrated execution environment. So, feedback loops in this framework are not decorative arrows. They represent the concrete way in which decisions alter processes, altered processes generate new trace data, and those traces then feed the next round of analysis and redesign.

A second kind of feedback loop is evaluative rather than operational. Elgendy et al. [152] argue that data-driven decision systems require ex post evaluation, adaptive feedback, and learning loops if they are to support more than immediate action. That point matters for the present framework because managerial decisions should not only trigger interventions; they should also be assessed after the fact for quality, consequences, and fit. Pradhan et al. [153] make a related point from the process-mining side by showing that early analytical validity depends on knowledge exchange among business experts, IS specialists, and analysts. Their findings imply that feedback is not only generated by performance outcomes. It also emerges through cross-functional reinterpretation of what the data mean, which data are missing, and which process assumptions were flawed in the first place. In that sense, the framework contains both learning-by-outcome loops and learning-by-interpretation loops.

All these loops explain why the five layers should be read as mutually adjusting rather than linearly sequential. The data and computation layer enables capture and processing; the organizational insight and process intelligence layers turn traces into interpretable patterns; the augmentation layer broadens access and recombination; the decision layer converts insight into action; and the consequences of that action return as new data, revised process knowledge, updated evaluation criteria, and sometimes redesigned governance arrangements. The framework is therefore recursive by design. Its strength lies not in claiming seamless integration, but in showing how organizational learning, process improvement, and decision support depend on repeated movement across layers rather than on the isolated maturity of any one of them.

The framework is therefore not intended only as a conceptual classification of technologies. Its practical value lies in showing how the layers can be interpreted in concrete business settings, where organizational insight, process intelligence, augmentation, and decision support have to work together around specific managerial problems.

8. Application Domains and Business Use Cases

The framework becomes more useful once it is read as an applied architecture rather than as a conceptual map alone. In practice, organizations do not implement BI, BPM, big data analytics, GenAI, and DSS as isolated modules. They combine them around recurring business problems such as cycle-time reduction, resource allocation, service responsiveness, compliance improvement, or cross-functional coordination. For that reason, this section does not try to catalogue every possible sectoral use case. It focuses instead on business domains in which the interaction among the layers becomes particularly visible and managerially meaningful. Operational process optimization is the natural starting point because it is the setting where data capture, process evidence, simulation, intervention logic, and decision routines most clearly converge [154,155,156].

A second reason to begin here is that optimization is often discussed too loosely. In the literature, the stronger studies do not define optimization as a generic efficiency gain or a vague improvement narrative. They tie it to observable process outcomes such as waiting times, throughput, cost, resource use, and case outcomes, and they typically treat redesign as an iterative exercise rather than a single analytical step. That makes operational process optimization a good test bed for the framework proposed in Section 7, because success depends on how well the layers reinforce one another rather than on the isolated performance of any one tool [157,158,159].

Table 4. Practical utilization of the integrative framework across business use cases.

Application Domain	Managerial Problem Addressed	Framework Layers Most Involved	Practical Use of the Framework	Decision-Support Implication	Main Implementation Concern
Operational process optimization	Reducing delays, rework, bottlenecks, and process variability	Big data analytics; BPM; process mining; DSS	Event logs and operational records are analyzed to identify process variants, performance gaps, and points where intervention may be needed.	Managers can move from retrospective performance reporting toward more evidence-based prioritization of process redesign actions.	Process data may be incomplete, fragmented, or difficult to interpret without contextual knowledge from process owners.
Customer-facing service processes	Improving responsiveness, service quality, and consistency across customer touchpoints	BI and business analytics; BPM; GenAI; DSS	Customer interactions, service records, and process traces are combined to understand where service failures, delays, or coordination problems occur.	Decision makers can connect customer experience indicators with internal process causes rather than treating them as isolated performance metrics.	The use of customer data requires careful governance, privacy protection, and avoidance of overly automated service decisions.
Supply chain and logistics coordination	Managing disruptions, resource constraints, delivery delays, and interorganizational dependencies	Big data analytics; process intelligence; DSS	Transactional, logistics, and event-stream data are used to monitor process execution across suppliers, warehouses, transport activities, and service commitments.	The framework can support earlier detection of operational risks and more informed decisions about rerouting, prioritization, or resource reallocation.	Data interoperability across organizations remains difficult, especially when partners use different systems, standards, and reporting practices.
Finance, compliance, and risk-sensitive processes	Strengthening traceability, control, auditability, and exception management	BI and business analytics; process mining; DSS; governance mechanisms	Process mining and analytical monitoring can reveal deviations from expected procedures, unusual patterns, or control weaknesses in financially sensitive workflows.	Decision support becomes more defensible when recommendations are linked to traceable evidence, process rules, and documented exceptions.	False confidence in automated recommendations can create compliance risks if human review, audit trails, and accountability mechanisms are weak.
Knowledge-intensive administrative workflows	Reducing documentation burden and improving access to dispersed organizational knowledge	GenAI; BI and business analytics; BPM; DSS	GenAI can support querying, summarizing, drafting, and explaining process-related knowledge when grounded in verified organizational documents and process repositories.	Managers and employees can access process knowledge more easily, especially when expertise is distributed across departments or documents.	Generated outputs must remain source-linked and reviewable, since fluent summaries may omit uncertainty, conditions, or exceptions.
Human–AI supported managerial decision-making	Combining analytical outputs with managerial judgment under uncertainty	BI and business analytics; GenAI; DSS; human oversight	Analytical models, process evidence, and GenAI-based explanations can be organized into decision-support interfaces that help managers compare alternatives.	The framework clarifies that AI should augment decision-making rather than replace managerial responsibility in complex organizational settings.	Trust, explainability, and control rights must be designed carefully so that users can question, override, or validate AI-supported recommendations.

Note: The table translates the layered framework proposed in Section 7 into representative business uses. The domains are illustrative rather than exhaustive, since the framework is intended as a conceptual architecture for interpreting different organizational contexts rather than as a fixed implementation model.

shows the practical utilizations of the integrative framework that can be found across business use cases.

8.1. Operational Process Optimization

Operational process optimization is the clearest application domain for the framework because it turns abstract capabilities into measurable process effects. Here, the data and computation layer captures execution traces, timestamps, resource actions, and contextual variables; the process intelligence layer reconstructs delays, bottlenecks, and variants; and the decision layer supports interventions around prioritization, assignment, or redesign. Ali et al. [158] make this visible through their work on waiting times, where the key issue is not merely identifying delay but distinguishing its causes and consequences with enough precision to support action. Middelhuis et al. [154] address a related issue from the allocation side by showing that learning-based resource assignment can reduce cycle time in business processes when compared with standard benchmarks. Taken together, these studies suggest that operational optimization is strongest when process performance is decomposed into actionable mechanisms rather than treated as one aggregate KPI.

Simulation adds a second layer of practical value because managers rarely want a diagnosis alone; they want to know what may happen if staffing, routing, approvals, or timing rules are changed. López-Pintado et al. [156] show that simulation quality improves when resources are modeled as differentiated rather than as interchangeable members of a pool, which is important because many operational bottlenecks depend on skill, availability, and multitasking patterns rather than on headcount alone. Camargo et al. [160] move further by combining process mining with deep learning to learn simulation models directly from event logs, allowing organizations to test process changes on a data-derived basis rather than on manually parameterized assumptions. A practical case from corporate travel-request management reaches a similar conclusion: Celik and Dogan [161] use process mining and simulation together to show that response-time reductions at specific approval roles can generate measurable cost improvements. What emerges across these studies is a more disciplined view of optimization. It is not simply a matter of “finding the bottleneck”; it is a matter of linking observed process structure to plausible intervention scenarios and then testing those scenarios before implementation.

More recent work also pushes optimization closer to runtime intervention. Eshuis and Genga [157] argue that event logs can support not only diagnosis but causal rule mining for identifying intervention strategies on running cases, which marks an important shift from retrospective improvement to action during execution. That shift matters for the framework because it shows how the upper layers interact: process intelligence identifies the conditions associated with desired or undesired outcomes, and decision support converts those conditions into operational responses. Still, the literature is not naïve about this transition. The closer optimization moves toward live intervention, the more sensitive it becomes to context quality, rule validity, and the ability to distinguish correlation from action-worthy causation. In other words, operational optimization becomes more valuable, but also more fragile, as it becomes more interventionist.

The case evidence is especially persuasive when it spans different operational contexts. Lee et al. [162], in a fully automated manufacturing setting, show how process mining can be used to analyze flow, time, resources, and quality together in order to address both global bottlenecks and local workload issues. In healthcare, Rabbi et al. [163] and Nakhostin et al. [164] show that process mining can expose hidden inefficiencies in clinical workflows and support targeted improvement efforts, but also that domain constraints, specialist knowledge, and patient-risk considerations prevent any simplistic notion of optimization. This is a useful warning for the present paper. Operational process optimization is where the framework is easiest to observe in practice, but it is also where context dependence becomes impossible to ignore. The layers do not create value automatically. They create value when organizations can align process evidence, computational models, operational constraints, and managerial judgment around a clearly defined improvement problem.

8.2. Customer-Facing and Service Processes

Customer-facing and service processes make the framework especially revealing because process performance and customer experience are intertwined rather than sequential. In these settings, firms are not only managing internal flow efficiency; they are orchestrating journeys that span search, evaluation, purchase, support, recovery, and sometimes repeated re-engagement across physical and digital channels. Sheth et al. [165] show that customer support should not be treated as a narrow post-purchase function, but as a journey-wide capability tied to information provision, decision facilitation, relationship building, and value expansion. A similar logic appears in omnichannel retailing and B2B settings, where journey design and touchpoint management are increasingly understood as strategic rather than merely operational tasks. The practical implication is that customer-facing processes cannot be optimized convincingly by looking at isolated touchpoints alone; what matters is how those touchpoints connect into a coherent and navigable service experience [166,167,168].

This is also where the limitations of traditional journey mapping become more obvious. Halvorsrud et al. [169] showed early on that customer journey analysis can improve service quality, but they also made clear that journeys are often longer, more irregular, and more deviation-prone than managers assume. More recent process-mining work reinforces that point. Topaloglu et al. [170] argue that online customer journeys are difficult to interpret when treated as if they were cleanly structured processes, and Halvorsrud et al. [171] explicitly describe the combination of customer-journey analysis and process mining as promising but methodologically challenging. For the framework proposed in this paper, that matters because the customer-facing domain depends heavily on the interaction between the data and computation layer and the process intelligence layer: without fine-grained event capture and suitable abstractions, firms risk producing visually rich but analytically thin representations of customer behavior.

The applied literature also shows why service processes increasingly require richer data fusion than classical CRM reporting can provide. Akhavan and Hassannayebi [172] combine process analytics with machine learning to predict customer dissatisfaction in online insurance journeys, while Cheng et al. [173] show that call-center process prediction improves when enterprise-system traces are fused with dialogue text rather than treated as separate information streams. Ledro et al. [174] add an important organizational qualification: successful AI integration in CRM depends on customer-data centralization, retraining routines, user involvement, and ethics by design. Therefore, these studies suggest that customer-facing optimization is not only about better models. It depends on whether firms can connect behavioral traces, service interactions, and decision routines into one service-management architecture that remains both analytically strong and operationally governable.

The augmentation layer becomes visible here as well, but in a more socially exposed form than in back-office processes. Tan et al. [175] show that in online service recovery, customers may struggle to distinguish AI-generated managerial responses from human-written ones, yet disclosure that the response came from ChatGPT can still reduce affective, cognitive, and conative reactions. Keating et al. [176] likewise find that anthropomorphic design can improve outcomes in AI-based service recovery, but only under specific conditions rather than universally. This is a useful corrective for the present framework. In customer-facing and service processes, augmentation can help with speed, consistency, and scale, but the final design problem remains managerial: firms still need to decide which journey frictions matter most, which interventions justify automation, and where customer-centric process improvement should take precedence over narrow efficiency gains [177].

8.3. Supply Chain and Logistics Processes

Supply chain and logistics processes are one of the strongest application domains for the framework because execution no longer sits inside a single organizational boundary. Information, materials, approvals, transport events, and inventory states move across firms, systems, and infrastructures that are only partially visible to one another. Oldenburg et al. [178] show that process mining is becoming relevant to supply chain management precisely because it can uncover inefficiencies, compliance issues, and improvement opportunities across these extended flows. At the same time, the transfer from classical BPM to logistics is not frictionless. Graves et al. [179] argue that many logistics settings depend on item counts, stock thresholds, and decoupling conditions that standard event-log assumptions do not capture well, while Li et al. [180] show in air-cargo operations that real event data are often noisy, incomplete, and difficult to align with actual physical movement without substantial preprocessing. In this domain, then, the process intelligence layer is valuable, but only when it is adapted to the material and interorganizational character of logistics processes rather than imported in a generic form.

A second reason this domain matters is that visibility is not a secondary reporting feature; it is often the condition for coordination, resilience, and timely intervention. Helo and Thai [181] show that smart tracking and tracing applications create value in logistics through operational efficiency, visibility, transparency, and safety/security. That result becomes more persuasive when read together with Tiwari et al. [182] and Jia et al. [183], who show that supply chain visibility functions as a foundational resource for digital capabilities and is positively associated with resilience under uncertainty. Zheng and Brintrup [184] extend the same logic into privacy-sensitive network settings by showing that graph-based learning combined with federated learning can improve visibility without requiring raw cross-organizational data sharing. What this suggests is more specific than the usual claim that “data improve logistics”. The data and computation layer matters here because it enables cross-actor visibility under real constraints of fragmentation, privacy, and dynamism, which are central rather than incidental features of supply chain work.

The decision layer becomes more visible once firms move from observing disruptions to testing responses and redesigning control mechanisms. Li et al. [185] propose a multi-agent digital-twin-enabled DSS for supplier management that integrates fuzzy decision logic with a validation mechanism for supplier-development strategies, while Ivanov and Gusikhin [186] show, in a large-scale Ford case, how supply chain digital twins can support visibility, resilience, stress testing, and broader data-driven management. Still, the literature is not uniformly optimistic. Benhamou et al. [187] note that operational digital-twin deployments in supply chain management remain rarer than the rhetoric suggests, and Wube et al. [188] show in their review of resilient and sustainable closed-loop supply chain DSS research that uncertainty modeling, decision levels, and resilience strategies are still unevenly developed across the field. So, supply chain and logistics processes illustrate both the promise and the discipline of the framework: visibility and analytics matter, but they only become managerially useful when tied to explicit decision structures, intervention logic, and realistic deployment conditions.

The augmentation layer is beginning to matter here as well, but the evidence is still less mature than in many front-office or document-centric uses. Culot et al. [189], reviewing empirical AI research in SCM, explicitly warn against hype and show that implementation challenges remain tied to data requirements, deployment processes, interorganizational integration, and performance implications. Bahroun et al. [190] reach a similar conclusion for GenAI, more specifically: most reported applications cluster around planning and enabling activities, the evidence is still largely prototype-level, and system-wide KPI reporting remains limited. Al-khatib et al. [191] do provide positive empirical evidence that genAI capabilities are associated with improved digital supply chain performance in manufacturing firms, but their design is cross-sectional and context-specific, which limits how broadly that result should be generalized. For this reason, supply chain and logistics processes are a useful but demanding test case for the framework. They show where BI, process intelligence, analytics, GenAI, and DSS can reinforce one another, but they also make it difficult to hide weak grounding, immature evaluation, or overly promotional claims about automation.

8.4. Finance, Compliance, and Risk-Sensitive Processes

Finance, compliance, and other risk-sensitive processes are a demanding application domain for the framework because efficiency alone is never the sole criterion of success. Here, process performance has to be aligned with documentation quality, regulatory conformity, control integrity, and defensible decision trails. That changes the meaning of optimization. A faster process is not necessarily a better one if it weakens traceability or increases control bypass risk. Recent work on business process compliance and regulatory compliance monitoring makes this point quite clearly: organizations need ways to compare actual executions with prescribed rules, but they also need mechanisms for interpreting deviations in a form that supports intervention rather than just post hoc reporting [192,193].

This is where the process intelligence layer becomes particularly useful. In regulated environments, the main challenge is often not the lack of control documents, but the gap between formal controls and lived execution. Process mining and related compliance-checking approaches can help surface rule violations, anomalous patterns, and deviant process paths that would remain difficult to detect through sampling or static documentation alone. At the same time, the literature is careful not to overstate maturity. Regulatory compliance monitoring still depends heavily on manual preparation, formalization choices, and process-data quality, while deviance mining only becomes managerially meaningful when abnormal patterns can be linked back to operational risk or control failure rather than treated as abstract statistical outliers [192,193,194].

The auditing and financial-reporting literature adds an important decision-support perspective. In this domain, BI and analytics do not merely summarize transactions; they support judgments about misstatement risk, control weakness, and assurance priorities [195]. Recent studies show that hybrid DSS designs can improve financial-misstatement identification, that XAI can make model-based audit assessments more interpretable, and that process mining can support audit work more systematically across assurance structures such as the three-lines model. Yet the same literature also documents the constraints: AI in auditing still faces concerns around explainability, robustness, privacy, bias, overreliance, and the need for AI-specific auditability measures and competencies. So, the framework works here not because it automates audit judgment, but because it helps connect evidence generation, process-level visibility, explainability, and accountable managerial or assurance action [196,197,198,199].

Anti-money-laundering and RegTech settings make the same architecture visible in a more operationally intense form. These processes depend on large-scale transaction monitoring, exception handling, escalation logic, and increasingly complex regulatory obligations [200]. Recent work suggests that RegTech can strengthen AML effectiveness and risk monitoring, but adoption is mediated by organizational readiness, integration difficulty, and information-privacy concerns rather than by technical promise alone [201,202]. More broadly, finance research on genAI is already warning that methodological contingencies, replicability issues, and context sensitivity remain central. That is a useful caution for this subsection: in finance and compliance, the augmentation layer may help with querying, summarization, and policy interpretation, but its use has to remain tightly bounded by verification, governance, and human accountability. In these settings, the framework is most convincing when it is used to discipline judgment, not to bypass it [203].

8.5. Procurement, Sourcing, and Contract Management Processes

Procurement is one of the clearest domains in which the layered logic of this review becomes operational rather than merely conceptual. Decisions in this area depend simultaneously on spend visibility, supplier intelligence, approval paths, document flows, and contractual control, so weak integration across BI, BPM, analytics, and DSS quickly becomes costly. Handfield et al. [204] had already noted that advanced procurement analytics remained underused even as the data environment was expanding, largely because trusted spend data, contract repositories, and governance routines were still immature. That caution still holds. Altundag and Wynn [205], in a recent strategic procurement case, show that digital maturity is constrained not only by technical availability but also by compliance requirements, fragmented data practices, and uneven organizational readiness. Procurement, then, does not benefit very much from isolated dashboards alone; it benefits more from an integrated architecture in which data discipline, process traceability, and decision authority are aligned.

At the sourcing stage, AI can support supplier discovery, bid comparison, document screening, and parts of supplier evaluation, but the literature does not justify the stronger claim that sourcing has become autonomously intelligent. Guida et al. [206] map AI functionalities across strategic purchasing, sourcing, and supply, yet they also show that adoption remains uneven and conceptually underdeveloped. Spreitzenbarth et al. [207] reach a similar conclusion from a mixed-methods review, identifying multiple use-case clusters while still describing organizational usage as nascent. More specifically, Bodendorf et al. [208] demonstrate how business analytics and text mining can be applied to supplier documents in strategic purchasing, which is useful because procurement decisions are often slowed not by a lack of information, but by the difficulty of extracting comparable signals from heterogeneous files. Even so, document-level intelligence does not resolve the harder governance problem: weak evaluation criteria, inconsistent supplier master data, or poorly framed sourcing objectives can simply be processed faster rather than improved.

A similar pattern appears in operational procurement execution. Lakhal et al. [209] show that AI use across the source-to-pay framework spans source-to-contract, purchase-to-pay, and supplier relationship management, with data quality, API integration, and organizational readiness emerging as central enablers rather than secondary technical details. Ronellenfitsch et al. [210], working directly on procure-to-pay data, make the process view more concrete by showing that P2P inefficiencies are tied to requestor-, item-, and supplier-related factors and are closely linked to resource consumption and compliance risk. This matters because procurement BI on its own may reveal spend levels, invoice delays, or cycle times, yet it often says little about how those outcomes were produced. When event-log analysis is linked to supplier-oriented DSS, as in Li et al. [185], procurement can move beyond static scorecards toward scenario-based supplier evaluation and development. Still, the evidence suggests that predictive or prescriptive support is strongest when it remains tied to explicit process controls and human review, not when it is framed as a substitute for procurement judgment.

Contract management is where the value of integration becomes most demanding and where overstatement becomes easiest. Vlachos [211] shows that contract design is not a passive legal afterthought; it shapes supplier performance through the balance of formal, relational, and contextual factors. More recent work by Dikmen et al. [212] indicates that NLP and machine learning can assist contract review by extracting risk and responsibility signals from large contract sets when manual review is time-constrained. Yet this should not be read as evidence that contractual interpretation has become a solved automation problem. Foged [213] demonstrates, in green public procurement, that contract management efficiency still depends heavily on organizational capacity. So, in procurement, sourcing, and contract management, the framework is most persuasive when it is used to connect spend intelligence, process evidence, supplier evaluation, and contract oversight into a single decision structure. Its weakest version is the fashionable one: adding AI interfaces to fragmented procurement routines without first resolving data discipline, process accountability, and institutional capability.

The application areas discussed in this section also clarify why the implementation tensions examined next are not abstract concerns. In supply chain, healthcare, procurement, customer-facing services, and other process-intensive domains, the value of the proposed framework depends on whether data sources can be integrated, process evidence can be trusted, GenAI outputs can be verified, and decision-support recommendations can remain accountable. Application failures therefore provide the practical entry point for the challenges discussed in Section 9: weak interoperability limits end-to-end visibility, poor evaluation inflates confidence in analytical outputs, and insufficient governance turns augmentation into a potential source of operational and compliance risk.

9. Challenges and Implementation Tensions

The integrative architecture proposed in this review should not be confused with frictionless implementation. The literature suggests a more uneven reality: organizations can often deploy isolated analytics, process-mining, or GenAI applications faster than they can align the data structures, evaluation logic, and cross-functional routines needed to support dependable business processing at scale. Beerepoot et al. [214] make a related point from the BPM side by arguing that several foundational problems remain unresolved despite rapid methodological progress. In the present context, the issue is not a shortage of tools. It is the difficulty of making heterogeneous data, process representations, analytical models, and decision routines work together without creating partial visibility, misleading precision, or weakly comparable performance claims. For that reason, the discussion begins with frictions at the data and evidence level before moving to oversight- and governance-oriented concerns in the following subsections.

The central implementation problem is that these barriers accumulate across layers rather than appearing as isolated technical defects. Poor data quality weakens BI outputs and process-mining results; weak interoperability limits the possibility of end-to-end process visibility; unrealistic evaluation can make analytical and GenAI systems appear more dependable than they are in actual organizational use; and unclear governance leaves decision makers uncertain about responsibility when recommendations are wrong, incomplete, or difficult to contest [215,216,217]. The same logic applies to organizational capacity. Firms may possess advanced tools but still lack data stewardship routines, process ownership, model-monitoring practices, or decision protocols that allow those tools to be used responsibly [218,219,220]. A critical reading of the literature therefore suggests that integration is not mainly a question of adding GenAI to existing BI, BPM, or DSS infrastructures. It is a question of whether the surrounding organization can maintain evidence quality, interpretability, accountability, and human control as these infrastructures become more connected [221,222,223,224].

9.1. Data, Interoperability, and Evaluation Frictions

Data quality in this domain should not be reduced to correctness alone. Fu et al. [215] show that, in data-driven industrial settings, quality is shaped not only by technical design but also by how data are used, interpreted, and maintained over time. In business-processing environments, that point becomes sharper because the same records often need to support execution, reporting, process mining, analytics, and decision support simultaneously. Goel et al. [216], from a process-mining perspective, argue that dependable insight requires stronger process-data governance around ownership, context, and interoperability. This is why poor data quality is rarely a local defect. Once event records, master data, and contextual attributes are weakly aligned, distortions travel upward through the rest of the architecture.

Interoperability creates a second and closely related tension. In principle, digital business processing promises a unified view across enterprise systems, interaction traces, and process evidence. In practice, data are often captured at incompatible levels of abstraction and with unstable case definitions. Abb and Rehse [31] show this clearly for process-related user interaction logs, where the absence of common conceptual and implementation standards limits exchange and downstream analytical use. What follows is not merely a technical inconvenience. It means that some claims of end-to-end visibility are built on sources that were never properly harmonized in the first place. Under those conditions, integration becomes more performative than real, and analytics can appear weaker than they are because the representational base is fragmented rather than because the analytical methods are inherently inadequate [216].

Evaluation frictions are no less important, partly because they are easier to conceal behind strong-looking accuracy or performance figures. Rama-Maneiro et al. [217], in their review and benchmark of deep learning for predictive business process monitoring, show that fair comparison remains difficult when studies rely on different event logs, feature encodings, prediction targets, and experimental setups. A similar issue appears in the BI&A literature, though in a different form. Ul Ain et al. [123] note that success measurement remains inconsistent across BI&A studies, which weakens comparability and makes it harder to judge whether claimed benefits are technical, organizational, or genuinely decision-related. So, the evaluation problem is not limited to one stream of the paper. It extends across predictive monitoring, business analytics, and decision support more broadly.

Recent GenAI-oriented BPM research does not resolve this problem; in some respects, it intensifies it. Ceravolo et al. [45] argue that predictive process monitoring still faces unresolved conceptual and methodological challenges even before generative layers are added. Kourani et al. [78], working on LLM-based business process modeling, likewise show substantial performance variation across models and benchmark settings. That matters because visually plausible outputs and fluent explanations can create a false sense of methodological maturity. A more defensible conclusion is therefore narrower: progress in digital business processing depends not only on stronger models but also on better data definitions, more interoperable structures, and evaluation designs that reflect real process conditions rather than only convenient benchmarks.

9.2. Explainability, Trust, and Human Oversight

Explainability is often presented as the natural remedy for opacity, but the literature is more restrained than that formulation suggests. Balasubramaniam et al. [225] show that explainability only becomes meaningful when organizations define, in a structured way, what the explanation is actually for, for whom it is intended, and which negative consequences it is supposed to mitigate. Wang and Yin [226] reach a related conclusion from experimental work on AI-assisted decision-making: explanations do not produce uniform effects across settings and should not be treated as a universal design fix. In business-processing contexts, this matters because dashboards, process alerts, or GenAI-generated justifications can create the appearance of interpretability without necessarily improving the quality of managerial reasoning. An explanation layer can therefore clarify, but it can also cosmetically stabilize weak outputs.

A second issue is that trust should be calibrated rather than maximized. Afroogh et al. [227], in their review of trust in AI, distinguish between trustworthiness and trust itself, which is important here because users may place confidence in a system for reasons that exceed its actual reliability. Zhang et al. [228] make that problem more concrete by showing that confidence information can help calibrate reliance in AI-assisted decisions, yet calibration alone does not automatically improve joint decision quality. So the central challenge is not simply whether users trust the system, but whether they know when trust is warranted and when skepticism is still necessary. In managerial settings, excessive trust can be just as problematic as resistance, particularly when analytical outputs are delivered with enough fluency and visual coherence to discourage further checking.

Recent empirical work also suggests that explainability does not reliably prevent overreliance. Cecil et al. [229], in a personnel-selection context, found that explainable AI advice did not significantly reduce people’s tendency to follow incorrect advice. Buçinca et al. [230] similarly show that simple explanations are often weaker than cognitive forcing mechanisms when the goal is to reduce overreliance on AI recommendations. This is an important corrective for the present review because it means that interpretability features should not be equated with effective oversight. A system may be explainable in presentation terms while still encouraging automation bias in practice. That distinction becomes especially relevant in process-sensitive environments where users work under time pressure, handle large case volumes, or interact with AI outputs repeatedly enough to develop habitual reliance.

For that reason, human oversight should be understood as an active organizational capability, not as a symbolic human-in-the-loop requirement. Te’eni et al. [231] argue that meaningful control depends on feedback structures, learning, and the deliberate design of responsibility delegation between humans and AI. In other words, oversight is not achieved merely by keeping a person nominally responsible for the final click or approval. It requires that users remain able to question outputs, detect changing conditions, and intervene without being cognitively or institutionally locked into the system’s recommendations. Across BI, BPM, and AI-supported DSS, the real tension is therefore not between automation and no automation. It is between systems that preserve contestability and those that quietly replace it with procedural reassurance.

9.3. Governance, Privacy, Security, and Organizational Readiness

Governance in this domain should not be treated as a thin layer of principles added after technical deployment. Papagiannidis et al. [221] make a useful distinction between responsible AI principles and responsible AI governance, arguing that the harder problem lies in operationalizing governance through structural, relational, and procedural practices rather than through abstract commitments alone. Rana et al. [222] reach a compatible conclusion in the GenAI adoption literature, where ethical considerations such as fairness, accountability, transparency, accuracy, and autonomy are shown to shape organizational use rather than sitting outside it as secondary concerns. In other words, governance is not separate from implementation. It is part of the organizational architecture that determines whether AI-supported business processing remains contestable, reviewable, and aligned with institutional obligations.

Privacy and security create a related but sharper set of constraints because they expose the consequences of weak governance in concrete operational terms. Diro et al. [223] show that GenAI adoption in workplace settings introduces risks that extend beyond generic cybersecurity language, including data leakage, model-related vulnerabilities, AI-driven monitoring concerns, and regulatory compliance burdens. Novelli et al. [224], from the legal and regulatory side, similarly argue that generative systems challenge existing frameworks across privacy, liability, and cybersecurity because their behavior is difficult to predict fully and because compliance cannot be reduced to ordinary software governance. For business-processing environments, this means privacy and security are not peripheral “risk sections” at the end of a project. They are design constraints that shape what data can be used, how models can be embedded into workflows, and which outputs can be treated as operationally legitimate.

Organizational readiness is the point where many ambitious deployments become uneven in practice. Hughes et al. [218] show that greater GenAI adoption is strongly conditioned by organizational change capacity and by the interaction between complexity and staff skills, which is a more sober finding than much of the current implementation rhetoric. Merhi [219], in a broader AI implementation context, likewise demonstrates that successful adoption depends on a ranked set of interdependent critical factors rather than on technological enthusiasm alone. Soudi and Bauters [220] add an important nuance by showing that smaller firms often lack the resources, tailored guidance, and sector-specific governance support needed for responsible AI uptake. So, readiness should not be interpreted narrowly as willingness to experiment. It includes governance literacy, data stewardship, training, process redesign capacity, and the ability to absorb compliance and security obligations without reducing them to symbolic policy language.

These concerns above suggest that governance, privacy, security, and readiness are best understood as mutually reinforcing conditions rather than as separable implementation checkboxes. Organizations can often pilot AI tools faster than they can establish clear responsibility structures, durable control mechanisms, and reliable escalation paths when things go wrong. That asymmetry helps explain why adoption can appear advanced at the interface level while remaining institutionally fragile underneath. For the present review, the implication is straightforward: the more tightly BI, BPM, big data analytics, GenAI, and DSS are integrated into core business processes, the less viable it becomes to treat governance and organizational readiness as afterthoughts. They are part of what makes integration sustainable in the first place.

These challenges do not undermine the value of integration, but they define the conditions under which future research should examine it. The next section therefore turns from current implementation tensions to the research agenda needed for more governable, evaluable, and process-aware forms of AI-supported business decision-making.

10. Limitations of the Review and Future Agenda

10.1. Limitations

This review acknowledges several limitations:

First, it is a narrative and conceptual review rather than an empirical study, a PRISMA-style systematic review, or a meta-analysis. Its purpose is to synthesize and organize a fragmented body of literature, not to provide an exhaustive inventory of publications or a statistical aggregation of findings.

Second, the proposed framework has not yet been validated through real organizational case studies, experiments, survey evidence, or longitudinal field research. It should therefore be read as a conceptual architecture for interpreting the integration of BI, BPM, big data analytics, process mining, GenAI, and DSS, rather than as a tested implementation model.

Third, the reviewed literature spans several fields with different levels of empirical maturity. Evidence on BI, BPM, and process mining is comparatively more established, whereas evidence on GenAI in process-critical business environments remains newer, less stable, and often closer to prototype, early adoption, or controlled evaluation settings.

These limitations do not reduce the value of the synthesis, but they do define the boundaries within which its conclusions should be interpreted.

10.2. Future Work

Future research should move beyond asking whether individual tools improve business outcomes in general terms. A more useful agenda is to examine how these layers interact under real organizational constraints, how their value should be evaluated across processes rather than isolated tasks, and where current claims still exceed the available evidence. In that spirit, the most important directions appear to be the following:

• Cross-layer evaluation frameworks: Much of the current literature still evaluates BI, process mining, GenAI, or DSS components in relative isolation. Future work should develop evaluation designs that examine how these elements perform together across full business-processing settings, including data quality, interpretability, decision usefulness, and downstream process outcomes. This would help the field move away from fragmented performance claims and toward more realistic assessments of organizational value.
• Human-centered and explainability-aware GenAI for BPM: The next step is not simply to generate better process artifacts or more fluent explanations, but to understand how different users actually interpret, challenge, and rely on those outputs in practice. Research should pay closer attention to oversight conditions, cognitive burden, contestability, and the difference between explanations that look persuasive and those that genuinely support better judgment. More field-based work would be especially valuable here.
• Privacy-preserving and federated process analytics: As business processes become more distributed and more data-sensitive, centralized analytical architectures will not always be feasible or desirable. Future studies should examine how federated learning, privacy-preserving analytics, and distributed process intelligence can support monitoring and decision support without requiring unrestricted data pooling. This is likely to become increasingly important in regulated, cross-organizational, platform-based environments.
• Process-aware LLM and multimodal systems: Current GenAI applications in BPM often remain heavily text-centered, even though business processes unfold through combinations of documents, event logs, interfaces, images, messages, and structured operational records. A strong research direction is therefore the development of process-aware systems that can reason across multiple modalities while remaining grounded in business context and formal process logic. The challenge is not only technical capability, but also whether such systems can remain interpretable and dependable enough for managerial use.
• Real-time adaptive decision support under governance constraints: One of the most promising but still underdeveloped areas is the design of DSS that adapts to changing process conditions in near real time without becoming opaque or weakly governed. Future work should examine how adaptive recommendations, alerts, and interventions can remain auditable, accountable, and aligned with organizational control structures. In other words, the problem is not just responsiveness but responsive support that remains institutionally trustworthy.

These directions suggest that the next phase of research should be less concerned with adding yet another intelligent layer and more concerned with building integrated, governable, and evaluable business-processing systems. That is where the literature still appears comparatively thin, and it is also where future contributions are likely to matter most.

11. Conclusions

This review examined business intelligence, business process management, big data analytics, process mining, genAI, and decision support systems through a single business-processing perspective. The literature here does not support the claim that these domains have already converged into one stable or fully coherent field. Their histories, analytical logics, and implementation traditions remain partly distinct. BI and business analytics still emphasize organizational visibility and interpretation, BPM and process mining remain anchored in process structure and execution evidence, big data analytics provides the enabling computational and evidentiary base, GenAI reshapes interaction with knowledge and analytical outputs, and DSS continues to occupy the decision-facing layer where action is framed and operationalized. What the review shows, then, is not completed fusion, but a clear movement toward tighter integration under digital conditions, where isolated capabilities are increasingly insufficient.

That movement matters because contemporary business processes are no longer managed effectively through separated reporting systems, static process models, or narrow decision tools alone. Organizations increasingly need architectures in which data, process evidence, analytical reasoning, and managerial intervention are linked in a more continuous way. The framework proposed in this paper was intended to clarify that layered relationship. It showed that organizational insight, process intelligence, data and computation, generative augmentation, and decision support should be understood as interacting layers rather than as competing technologies or sequential upgrades. It also showed that the practical value of integration depends less on technological novelty by itself and more on whether these layers are made interoperable, interpretable, governable, and usable in real decision contexts.

At the same time, the review remained deliberately cautious. Much of the recent literature is promising, but it is also uneven. Strong technical developments often coexist with weak evaluation logic, fragmented data conditions, overstated implementation claims, and unresolved tensions around trust, oversight, privacy, and governance. For that reason, the contribution of the paper is not to argue that AI-enabled business processing has reached maturity. It is to offer a more disciplined synthesis of where the literature is already converging, where important complementarities are emerging, and where important barriers remain.

In that sense, the main conclusion is straightforward. BI, BPM, big data analytics, process mining, GenAI, and DSS are moving toward a more integrated architecture for digital business processing and managerial decision support, but that architecture is still developing, unevenly implemented, and not yet settled. Its future significance will depend not only on more capable models or interfaces but on the quality of the data foundations, the realism of evaluation, the strength of governance, and the continued preservation of human judgment within increasingly intelligent process environments.