Intelligent Cloud-Based Process Automation for Saudi Enterprises under Vision 2030: Integrating SAP BTP, Robotic Process Automation, and Enterprise Workflow Orchestration

1Introduction

Enterprise automation has evolved beyond replacing repetitive keystrokes. Contemporary organisations coordinate transactions across finance, procurement, human resources, customer service and regulatory reporting, often spanning multiple applications and ownership boundaries. In such environments, the speed of an individual bot is less important than whether the complete process reaches an accurate, authorised and recoverable outcome. Foundational RPA research identifies promising efficiency gains but also persistent difficulties involving scalability, governance and the relationship between automation and business process management [1,2]. Cloud deployment introduces another dimension: automation components can be provisioned flexibly, yet durable transactions must remain consistent when services, interfaces or participants become unavailable [3].

Saudi Arabia's Vision 2030 provides a strategic setting for examining these concerns. Enterprises seeking more productive operations must modernise existing enterprise resource planning landscapes while sustaining financial discipline, trustworthy digital services and local organisational capability. Saudi studies of cloud adoption indicate that technological suitability alone does not determine uptake; managerial support, staff capability, compatibility and perceived risk influence investment decisions [4,5]. Research on enterprise systems and decision quality similarly suggests that the value of digital integration depends on how information reaches accountable decision-makers [6]. These findings justify treating cloud automation as an organisational design problem rather than a licensing exercise.

The study addresses a specific gap. Literature evaluates RPA implementation, process mining, cloud enterprise systems and low-code development, but these streams rarely specify how a Saudi enterprise should distribute responsibilities between SAP BTP services and legacy applications under one controlled operating model. This review therefore asks: how can cloud-based workflow orchestration and selective software robots jointly deliver end-to-end automation without reproducing brittle interfaces, opaque decisions or fragmented ownership? Its aim is to construct a reasoned integration framework applicable to mixed SAP and non-SAP estates. The objectives are to clarify functional boundaries, assess the supporting evidence, develop governance and architecture principles, and identify measurable propositions for future Saudi validation.

2Conceptual foundations and related evidence

2.1From task automation to accountable process outcomes

RPA performs structured sequences of user interface actions or related digital tasks. Its attraction lies in reaching systems for which modern APIs are unavailable or prohibitively expensive to introduce. However, a robot that copies invoice fields or downloads reports is not equivalent to a process owner, an approval authority or a transaction coordinator. Syed and colleagues' research agenda [1] and subsequent reviews [2,7] expose the tension between local task efficiency and enterprise process coherence. Treating every manual step as an automation candidate overlooks upstream data defects, downstream exceptions and the costs of maintaining scripts after screen changes.

Business process management supplies the missing end-to-end perspective: an explicit sequence of events, decisions, responsibilities and completion conditions. Process models become useful when they express not just a happy path but also rejected requests, unavailable systems, rework and evidence retention. Herm and colleagues [8] propose an implementation framework connecting organisational choices to delivery stages, while Crisan and colleagues [9] identify distinct mechanisms through which automation changes work. Taken together, these studies support a layered interpretation: robots execute selected tasks, workflow engines coordinate cases and managers remain responsible for policy, controls and outcomes. Automation maturity therefore cannot be inferred from bot counts alone.

2.2Cloud platforms, integration services and process orchestration

SAP BTP provides a potential environment for coordinating automation services outside a tightly coupled core ERP installation. In an illustrative configuration, SAP Build Process Automation can support workflow, decisions, forms and robotic steps; integration services can mediate APIs and messages; connectivity services can enable controlled communication with authorised on-premise resources. These are functional design categories, not a claim that every subscription, deployment region or release exposes identical features. The architecture must be validated against current service entitlements, data pathways and operating constraints before implementation.

Cloud orchestration is not simply a chain of remote procedure calls. Long-running enterprise cases may involve human approvals lasting days, compensating actions after partial failure and asynchronous events arriving out of order. Ouyang and colleagues [3] demonstrate why scalable process engines cannot rely on stateless load balancing assumptions alone. Calcaterra and Tomarchio [10] show the value of policy-based management for distributed application lifecycles, while Hachemi [11] emphasises explicit modelling of orchestration and execution. Consequently, workflow state, integration transport and application transaction state should remain distinguishable even when surfaced through a common operations dashboard.

2.3Process intelligence and the limits of automation readiness

Process mining transforms event histories into evidence about actual process variants, handovers and waiting time. When combined with RPA, it can reveal candidate routines and provide a baseline against which automation outcomes can be assessed [12]. Yet user-interface event logs are sensitive to inconsistent activity labels and incomplete context. Research on robotic process mining [13], reactive robot synthesis [14] and user behaviour mining [15] suggests substantial analytical potential but also a risk of inferring appropriate conduct from practices that are merely frequent. An observed shortcut may violate the intended approval procedure.

Process discovery should therefore be interpreted alongside policy documents, task interviews and control evidence. Egger and colleagues [16] demonstrate why bot logs and process logs should be analysed jointly: apparent task success does not establish process completion. Cross-organisational process mining adds further concerns over access rights, semantic alignment and commercially sensitive information [17]. The practical lesson is to automate only after distinguishing approved variation from undocumented workarounds. Process intelligence is a diagnostic instrument; it is not an independent source of authorisation.

3Review methodology

3.1Review design, boundaries and eligibility

An integrative critical review was selected because the research question concerns relationships between technologies, operating models and institutional constraints rather than the pooled effect of a single intervention. Targeted literature identification covered publisher records, academic discovery services and bibliographic catalogues. Search concepts included robotic process automation, business process management, process mining, workflow orchestration, cloud ERP, low-code automation, automation governance and Saudi cloud adoption. Candidate sources were examined for the relevance of their methods, findings and conceptual contribution to this question. The final purposive corpus comprises thirty DOI-identifiable publications with journal publication years between 2020 and 2025. It is not presented as an exhaustive census of all eligible studies.

Inclusion required a clear contribution to at least one of five domains: task discovery and selection; automation implementation and value; cloud or workflow architecture; human and security governance; or Saudi organisational adoption. Editorial commentary without substantive analytical insight, vendor promotional claims and sources outside the date boundary were not used as the scholarly evidence base. Applied studies from sectors outside Saudi Arabia were retained for transferable mechanisms, but their outcomes were not reclassified as Saudi evidence. The evidence boundary excludes unrelated outcomes and distinguishes technology performance from organisational impact; this reduces the risk of extending sector-specific observations beyond their settings.

3.2Synthesis and methodological safeguards

Each selected publication was examined for research setting, unit of analysis, technological scope, method, reported benefit, limitation and relevance to the proposed framework. Findings were compared through a concept matrix rather than aggregated statistically. Contradictory implications were interpreted in terms of context: a task that succeeds within one well-defined application may not generalise to a multi-organisation approval chain. Research based on design artefacts and case demonstrations was distinguished from literature syntheses and survey evidence. The analytical output is a set of design propositions supported by convergent findings, not a causal estimate of productivity improvement.

Three safeguards limit overstatement. First, vendor-specific product descriptions are treated as implementation assumptions to verify, not as proof of business benefit. Secondly, references to Saudi policy indicate strategic relevance rather than government endorsement of any particular software platform. Thirdly, no interviews, organisational records, performance observations or newly collected datasets were obtained for this review. Search counts, agreement coefficients and adoption percentages are therefore not invented. These boundaries make the contribution transparent while leaving field validation open for subsequent research.

4Critical synthesis of adoption and delivery challenges

4.1Automation candidate selection

Successful selection begins with a business outcome and an evidence-based map of its constituent activities. Highly repetitive work with stable rules is often suitable for bots, but frequency alone provides an incomplete economic case. Farinha and colleagues [18] identify process characteristics relevant to feasibility; Šperka and Halaška [19] connect candidate assessment to process performance analysis. A useful selection exercise therefore examines data quality, rule stability, exception variety, system access, control criticality, demand variability and expected maintenance effort. Tasks requiring frequent judgement should not receive the same unattended execution status as deterministic reconciliation steps.

The distinction between automatable and worthwhile is consequential. An unstable screen-based process may be technically automatable but commercially inferior to improving an API or correcting master data. Conversely, a low-volume compliance action may justify orchestrated evidence capture because failure has disproportionate consequences. Investment appraisal must account for licence commitments, cloud usage, operational monitoring, rework, security reviews and staff training alongside minutes saved. Ylä-Kujala and colleagues [20] offer a disciplined approach to discounted cost comparison; the case evidence on procurement automation [21] indicates that value can include staff redeployment and service improvement rather than headcount reduction.

4.2Delivery models and organisational ownership

There is no universally optimal operating model. Asatiani and colleagues [22] distinguish sourcing, deployment and tooling choices that interact with internal capability and organisational risk. Central teams can impose standards but become bottlenecks; decentralised teams understand local process variation but may proliferate uncontrolled scripts. A federated arrangement is more defensible for complex Saudi enterprises: enterprise architecture and security teams define reusable standards, while authorised domain teams design and maintain processes within clear approval gates. A named process owner remains accountable across system and departmental boundaries.

Schlegel and colleagues [23] identify technical, organisational and human influences on RPA project success. Plattfaut and colleagues [24] likewise underline the importance of early collaboration between business and technology specialists. These findings challenge a common assumption that low-code environments make engineering discipline unnecessary. Easier configuration expands participation, but it also increases the need for version control, separation of duties, structured testing and controlled promotion between environments. Low-code tools should reduce incidental development effort, not the obligation to document rules and prove that automation behaves correctly under adverse conditions.

4.3Reliability, transparency and continuous improvement

At enterprise scale, reliability must be defined end to end. A process can fail even when every bot reports successful execution: an invoice may be duplicated, a downstream approval may not arrive, or a message may be retried without idempotency protection. Process orchestration should preserve correlation identifiers, enforce explicit state transitions and route unresolved cases to accountable staff. Bot observability needs to be joined to application events, business outcomes and human decisions. Research combining bot logs with process mining [16] offers a methodological foundation for this cross-layer visibility.

Failure handling requires an explicit classification of uncertainty. Technical exceptions include expired sessions, inaccessible endpoints and malformed responses; business exceptions include disputed invoices, insufficient approval authority and mismatched supplier identities. The first category may permit automatic retry after a safe delay, but the second often demands a human decision. A case must record its current state before retrying so that repeated execution cannot create a second purchase order or payment. Engineers should test duplicate events, reordered messages, timeouts, partial commits and restoration from backup. They should also distinguish availability from recoverability: a service that restarts promptly may still lose the context needed to finish an interrupted approval. Acceptance criteria should include evidence of reconciliation between the workflow record and the authoritative transaction. This taxonomy turns resilience from an infrastructure claim into an accountable business requirement, and makes incidents comparable across departments.

Continuous improvement follows operational evidence rather than vendor dashboards alone. Lameijer and colleagues [25] demonstrate how structured improvement methods can be applied to RPA environments, while Chapela-Campa and Dumas [26] describe the movement from process discovery towards augmented execution. The implication is a closed feedback cycle: compare approved process design with actual variants, investigate recurrent exceptions, simplify redundant steps and retire brittle automations. Measurement must separate technology uptime from realised service value. A healthy system may occasionally stop an automated case because it correctly enforces a control; counting such stops as operational failures would reward unsafe behaviour.

5Proposed SAP BTP-centred enterprise framework

5.1Functional allocation and reference architecture

The proposed framework separates interaction, orchestration, integration, execution and assurance. Business users initiate a request or respond to an assigned decision. A workflow engine maintains the case state, enforces decision rules and assigns human tasks. Integration services connect authoritative applications through governed interfaces and messages. RPA agents are invoked only for remaining interface-dependent tasks that cannot be accessed through a stable service contract. The systems of record retain ownership of master data and financial postings. Security controls and telemetry span each layer rather than residing exclusively in a final audit step (Figure 1).

This allocation intentionally avoids placing an unattended bot between every two systems. API-based transactions normally offer clearer contracts and more stable error handling than screen navigation. A bot remains appropriate for a confined legacy interface, provided its permissions, session handling, execution window and recovery route are explicitly managed. Event-driven notifications should communicate business state changes without silently bypassing approvals. Where an application cannot support distributed transactions, orchestration should define compensation, reconciliation and manual escalation before production deployment. This design follows the process-centric view of scalable workflow execution [3,10] and extends it with a deliberate boundary for RPA.

5.2Choosing the right execution mechanism

Selection among APIs, workflows, rules and bots should be recorded as an architectural decision, not left to whichever tool a team knows best. A candidate's interface availability, change frequency, transaction integrity and audit requirements determine its safest execution route. The decision matrix in Table 1 translates these conditions into implementation guidance. It is deliberately qualitative because there are no field data from which reliable Saudi-specific scoring weights could be estimated. Organisations may later calibrate thresholds using observed failure rates and unit costs.

Process condition	Preferred mechanism	Necessary safeguard
Stable supported business service	API or integration flow	Identity scope, contract tests, retries
Long-running cross-team approval	Workflow orchestration	Case state, escalation, decision audit
Deterministic legacy screen task	Bounded RPA agent	Credential vault, screen-change monitoring
Variable policy-driven classification	Decision service plus human review	Rule version, confidence and override trail
Asynchronous system notification	Governed business event	Correlation, deduplication and replay
Unstructured or ambiguous exception	Assigned human task	Evidence capture and accountable resolution

5.3Identity, segregation and operational controls

Automation introduces non-human identities with powers that may exceed those of individual employees if they are designed carelessly. Each service and robot should have the narrowest permitted scope, with managed secrets, distinct development and production credentials, and a monitored lifecycle. Sensitive approvals should not be both initiated and authorised by the same automated identity. Application logs must establish who configured the rule, which identity executed the step, what evidence was supplied and which person approved an exception. These requirements are particularly significant for finance, procurement and personnel records, where speed without traceability creates institutional exposure.

A security architecture should also classify process data and prevent unnecessary extraction into bot workstations or integration payloads. Retention, encryption, regional hosting requirements and third-party access conditions need legal and technical review for each deployment. Saudi evidence linking cybersecurity practices to digital service quality [27] reinforces the importance of organisational controls, although it does not validate a particular platform implementation. Integration quality matters equally: a secure workflow can still transmit inaccurate values if it lacks schema checks, master-data reconciliation and explicit ownership of corrections.

An additional challenge arises when an automated decision appears administratively correct but is substantively unjustified. A rules table may approve a request because an outdated delegation limit remains active, while an apparently successful robot may transmit obsolete bank details. Controls must therefore protect the provenance and effective dates of business rules and reference data. Material changes require independent review, impact assessment and an identifiable release record. Where classification or extraction uses probabilistic models, a confidence score alone cannot determine authority: the organisation must define unacceptable errors, evidence requirements and situations requiring mandatory human inspection. Every overridden recommendation should retain the original evidence and a reason for departure. This makes automation explainable to affected staff and auditors without claiming that a technically traceable event is necessarily a fair or lawful decision.

6Application to Saudi enterprise priorities

6.1Procurement and supplier coordination

Procurement is a strong candidate for integrated automation because purchase requests, vendor records, approvals, goods receipts and invoice exceptions span departments and systems. A proposed workflow would receive a request, validate budget and supplier information through supported services, route policy-based approval, record the purchasing decision and monitor fulfilment. RPA would be reserved for a legacy supplier portal or document capture step where no dependable interface exists. Procurement evidence from another national setting [21] supports attention to staff capability and progressive adoption; it cannot establish the magnitude of savings in Saudi organisations.

The critical design challenge is not submitting orders faster but preventing unauthorised commitments and incomplete reconciliations. Contractual thresholds should be held in versioned rules, procurement owners should review unusual supplier changes, and exceptions should remain visible until closure. Inter-organisational process research [17] suggests that supplier coordination requires agreement about shared events and information boundaries. The architecture can strengthen locally coordinated supply chains only when participation and data standards extend beyond the buyer's internal automation team.

6.2Finance, shared services and workforce administration

In accounts payable, a cloud workflow can compare invoice references with purchase orders, check for possible duplicates and schedule approval of legitimate exceptions. A supported ERP API should post an authorised transaction; RPA becomes a fallback for a constrained external interface. Payment release remains subject to segregation of duties. In shared human resources services, similar principles apply to joining documentation, employee changes and controlled updates, but personal data sensitivity makes unattended copying especially risky. The aim is a reliable case history that an auditor or employee can understand, rather than a black box reporting transactions completed.

Saudi findings on cloud accounting adoption [5] highlight the influence of compatibility, organisational resources and employee capabilities. Research on ERP and business intelligence integration [6] further suggests that analytical benefits depend on the quality of connected information. Consequently, automation should be deployed with master-data stewardship and targeted training, not merely alongside dashboards. Business units also need an agreed definition of completion: an approved document, a posted accounting entry and a communicated service outcome are different milestones and should be measured separately.

6.3Industry case study: SAP-integrated workflow automation at Juffali Commercial Vehicles, Saudi Arabia

To contextualise the proposed enterprise automation framework within Saudi Arabia's industrial environment, the implementation at Juffali Commercial Vehicles provides a relevant example of workflow digitalisation. The case illustrates how integrating established SAP ERP systems with electronic signature services can improve approval processes, operational transparency and administrative efficiency. It also offers a practical basis for evaluating opportunities to extend conventional workflow automation through cloud-based orchestration and SAP Business Technology Platform capabilities.

6.4A phased implementation and assurance cycle

A staged programme can reduce the risk of converting poorly understood practices into inflexible digital routines. Initial discovery should establish process ownership, event evidence, customer consequences and control obligations. Qualification then compares redesign, integration and RPA options. Design makes exception paths explicit, and assurance tests security, accounting integrity and recoverability. A limited pilot demonstrates performance under representative conditions before a production release. Operational monitoring subsequently determines whether a process should be improved, expanded or retired. Figure 2 treats the programme as a feedback loop rather than a one-way implementation checklist.

The lifecycle requires an agreed measurement contract from the outset. Table 2 lists candidate indicators and the accountable role for each. Measures must use consistent case identifiers, document their denominators and distinguish baseline from post-deployment observations. Thresholds should be set locally after risk assessment, rather than copied from unrelated case studies. Reporting automation success as a single percentage would conceal the competing interests of speed, control, service accessibility and operating cost.

Indicator	Operational definition	Accountable owner
End-to-end cycle time	Median hours from valid request to confirmed closure	Process owner
Straight-through completion	Eligible cases closed without manual correction / eligible cases	Operations lead
Exception recovery time	Median time from exception detection to resolution	Service manager
Control adherence	Cases with complete required approvals / sampled cases	Risk and compliance
Technical rework rate	Cases reopened for bot or integration defect / completed cases	Platform operations
Value realised	Verified net benefit after recurring and change costs	Finance partner

7Discussion: Conditions for sustainable automation

The synthesis points towards three interacting conditions. The first is architectural fit: stable integration contracts should carry authoritative business transactions, while bots provide controlled reach into otherwise inaccessible applications. The second is governance fit: process owners, security officers and technical teams must share responsibility for end-to-end results. The third is adaptive capacity: employee participation, observable events and periodic redesign keep automations aligned with changing procedures. Evidence on RPA implementation [8,23,24,28] and low-code integration [29] supports the relevance of these conditions, although the proposed combination has not been directly tested in a Saudi field setting.

Cloud adoption also changes the locus of dependence. Moving process execution to a platform may reduce local maintenance overhead while creating reliance on service entitlements, network connectivity, identity infrastructure and commercial roadmaps. A credible business case therefore includes exit planning, data portability, documented interface contracts and continuity procedures when a cloud region or dependent service is inaccessible. Cloud ERP research [30] associates architectural flexibility with resilience, but resilience cannot be assumed without testing prolonged outages, replay behaviour and recovery of unfinished workflow instances.

The Saudi context makes capability development particularly important. Local teams need enough process analysis, integration engineering and control expertise to challenge supplier designs, interpret exceptions and revise automation rules safely. Training restricted to drag-and-drop construction would leave a gap in security judgement, data stewardship and operating assurance. Ayadi [4] and Mujalli and colleagues [5] indicate that organisational characteristics shape cloud decisions in Saudi sectors. Their findings support a differentiated adoption strategy: organisations with weak data governance should begin with well-bounded pilots, whereas mature enterprises can establish reusable cross-functional services and federated delivery teams.

Implementation design should account for bilingual working practices, diverse supplier capabilities and variation between local branches and centrally managed services. A workflow that presents clear English field names to its developers may nevertheless cause misunderstanding when supporting documents arrive in Arabic, contain inconsistent transliterations or follow different numbering conventions. Validation rules should preserve original document values, identify the authoritative identifier and surface uncertain matches for review instead of silently normalising them. Business-continuity rehearsals must involve front-line staff rather than technology operators alone. Accessibility and clear communication about automated decisions are therefore part of service quality. These requirements offer a practical route to wider adoption without presuming that every Saudi organisation has the same systems, language mix or maturity.

8Research agenda, limitations and conclusion

8.1Testable propositions and future research

Future studies should compare workflow-led integration with bot-centred automation in matched Saudi enterprise processes. The first proposition is that a higher proportion of stable service-based steps reduces maintenance incidents without increasing unapproved transactions. The second is that case-level monitoring across robots, applications and approvals shortens exception recovery relative to isolated bot dashboards. The third is that joint business and technology ownership increases sustained use and reduces unauthorised workflow variants. Longitudinal designs could examine these effects in procurement, finance and workforce services, measuring both operating outcomes and control effectiveness. Qualitative interviews would help explain why similar technical deployments succeed in one organisation and underperform in another.

A rigorous evaluation would establish comparable pre-intervention baselines, specify which process changes accompany technology deployment and document seasonal changes in workload. Researchers could use interrupted time-series designs or matched operational units where random assignment is impractical. Outcome data should include cycle time distributions, exception closure, control breaches, customer complaints and maintenance expenditure, not merely average processing speed. Negative cases are informative: an intervention that reduces labour time but increases error correction should not be characterised as unequivocal progress. Audit logs and interviews should be triangulated to distinguish genuine process improvement from altered recording practices. Reporting should disclose implementation effort, excluded transactions and dependencies on vendor configuration, permitting readers to assess transferability rather than treating a successful pilot as universal proof.

8.2Limitations and conclusions

This review uses a purposive, cross-disciplinary body of thirty studies, not exhaustive evidence retrieval or meta-analysis. Studies differ in geography, methodology, process granularity and technology generation; their findings should not be collapsed into a universal return-on-investment claim. Product features and deployment arrangements can evolve, and Saudi-specific empirical evidence on the combined architecture remains limited. The diagrams and decision matrix are proposed design artefacts rather than results of field experimentation. These limitations define the need for evaluation rather than diminishing the practical importance of careful architecture.

Intelligent cloud-based automation contributes to Vision 2030 most credibly when it improves reliable organisational outcomes rather than maximising unattended activity. SAP BTP can provide a coordination environment, but platform selection does not substitute for process redesign, governance or human accountability. RPA is valuable where interface constraints persist; orchestration is essential when an outcome crosses actors, systems and controls. The resulting strategy is selective integration, measurable assurance and continuous improvement. Its central promise is not automation without people, but enterprise processes in which technology handles repeatable execution while authorised professionals retain responsibility for judgement, exceptions and public trust.

References

1. [1]Syed R, Suriadi S, Adams M, et al. Robotic Process Automation: Contemporary themes and challenges. Computers in Industry. 2020;115:103162. https://doi.org/10.1016/j.compind.2019.103162
2. [2]Stravinskienė I, Serafinas D. Process Management and Robotic Process Automation: The Insights from Systematic Literature Review. Organizacijų Vadyba: Sisteminiai Tyrimai. 2021;85:87–106. https://doi.org/10.1515/mosr-2021-0006
3. [3]Ouyang C, Adams M, ter Hofstede AHM, Yu Y. Design and Realisation of Scalable Business Process Management Systems for Deployment in the Cloud. ACM Transactions on Management Information Systems. 2021;12(4):36. https://doi.org/10.1145/3460123
4. [4]Ayadi F. Critical factors affecting the decision to adopt cloud computing in Saudi health care organizations. Electronic Journal of Information Systems in Developing Countries. 2022;88(6):e12231. https://doi.org/10.1002/isd2.12231
5. [5]Mujalli A, Wani MJG, Almgrashi A, et al. Investigating the factors affecting the adoption of cloud accounting in Saudi Arabia's small and medium-sized enterprises (SMEs). Journal of Open Innovation: Technology, Market, and Complexity. 2024;10(2):100314. https://doi.org/10.1016/j.joitmc.2024.100314
6. [6]Jaradat Z, Al-Hawamleh A, Hamdan A. Examining the integration of ERP and BI in the industrial sector and its impact on decision-making processes in KSA. Digital Policy, Regulation and Governance. 2025;27(2):117–144. https://doi.org/10.1108/DPRG-04-2024-0077
7. [7]Moreira S, Mamede HS, Santos A. Process automation using RPA: a literature review. Procedia Computer Science. 2023;219:244–254. https://doi.org/10.1016/j.procs.2023.01.287
8. [8]Herm LV, Janiesch C, Helm A, et al. A framework for implementing robotic process automation projects. Information Systems and e-Business Management. 2023;21:1–35. https://doi.org/10.1007/s10257-022-00553-8
9. [9]Crisan EL, Chis DM, Bodea EE, Buchmann R. Mechanisms for robotic process automation implementation in organizations: a systematic literature review. Journal of Advances in Management Research. 2023;20(5):920–946. https://doi.org/10.1108/JAMR-04-2023-0100
10. [10]Calcaterra D, Tomarchio O. Policy-Based Holistic Application Management with BPMN and TOSCA. SN Computer Science. 2023;4:232. https://doi.org/10.1007/s42979-022-01616-w
11. [11]Hachemi A. POEML: a Process Orchestration, Execution, and Modeling Language. Journal of Software: Evolution and Process. 2022;34(6):e2456. https://doi.org/10.1002/smr.2456
12. [12]El-Gharib NM, Amyot D. Robotic process automation using process mining: A systematic literature review. Data & Knowledge Engineering. 2023;148:102229. https://doi.org/10.1016/j.datak.2023.102229
13. [13]Leno V, Polyvyanyy A, Dumas M, et al. Robotic Process Mining: Vision and Challenges. Business & Information Systems Engineering. 2021;63:301–314. https://doi.org/10.1007/s12599-020-00641-4
14. [14]Agostinelli S, Lupia M, Marrella A, Mecella M. Reactive synthesis of software robots in RPA from user interface logs. Computers in Industry. 2022;142:103721. https://doi.org/10.1016/j.compind.2022.103721
15. [15]Rehse JR, Abb L, Berg G, et al. User Behavior Mining. Business & Information Systems Engineering. 2024;66:799–816. https://doi.org/10.1007/s12599-023-00848-1
16. [16]Egger A, ter Hofstede AHM, Kratsch W, et al. Bot log mining: An approach to the integrated analysis of Robotic Process Automation and process mining. Information Systems. 2024;126:102431. https://doi.org/10.1016/j.is.2024.102431
17. [17]Rott J, Böhm M, Krcmar H. Laying the ground for future cross-organizational process mining research and application: a literature review. Business Process Management Journal. 2024;30(8):144–206. https://doi.org/10.1108/BPMJ-04-2023-0296
18. [18]Farinha D, Pereira R, Almeida R. A framework to support Robotic process automation. Journal of Information Technology. 2024;39(1):149–166. https://doi.org/10.1177/02683962231165066
19. [19]Šperka R, Halaška M. The performance assessment framework (PPAFR) for RPA implementation in a loan application process using process mining. Information Systems and e-Business Management. 2023;21:277–321. https://doi.org/10.1007/s10257-022-00602-2
20. [20]Ylä-Kujala A, Kedziora D, Metso L, et al. Robotic process automation deployments: a step-by-step method to investment appraisal. Business Process Management Journal. 2023;29(8):163–187. https://doi.org/10.1108/BPMJ-08-2022-0418
21. [21]van Hoek R, Larsen JG, Lacity M. Robotic process automation in Maersk procurement: applicability of action principles and research opportunities. International Journal of Physical Distribution & Logistics Management. 2022;52(3):285–298. https://doi.org/10.1108/IJPDLM-09-2021-0399
22. [22]Asatiani A, Copeland O, Penttinen E. Deciding on the robotic process automation operating model: A checklist for RPA managers. Business Horizons. 2023;66(1):109–121. https://doi.org/10.1016/j.bushor.2022.03.004
23. [23]Schlegel D, Rosenberg B, Fundanovic O, Kraus P. How to conduct successful business process automation projects? An analysis of key factors in the context of robotic process automation. Business Process Management Journal. 2024;30(8):99–119. https://doi.org/10.1108/BPMJ-06-2023-0465
24. [24]Plattfaut R, Borghoff V, Godefroid M, et al. The Critical Success Factors for Robotic Process Automation. Computers in Industry. 2022;138:103646. https://doi.org/10.1016/j.compind.2022.103646
25. [25]Lameijer B, de Vries ESL, Antony J, et al. The implementation of Lean Six Sigma for the optimization of robotic process automation systems in financial service operations. Business Process Management Journal. 2024;30(8):232–259. https://doi.org/10.1108/BPMJ-08-2023-0640
26. [26]Chapela-Campa D, Dumas M. From process mining to augmented process execution. Software and Systems Modeling. 2023;22:1977–1986. https://doi.org/10.1007/s10270-023-01132-2
27. [27]Al-Hawamleh AM. Investigating the multifaceted dynamics of cybersecurity practices and their impact on the quality of e-government services: evidence from the KSA. Digital Policy, Regulation and Governance. 2024;26(3):317–336. https://doi.org/10.1108/DPRG-11-2023-0168
28. [28]Moderno OBS, Braz AC, Nascimento PTS. Robotic process automation and artificial intelligence capabilities driving digital strategy: a resource-based view. Business Process Management Journal. 2024;30(1):105–134. https://doi.org/10.1108/BPMJ-08-2022-0409
29. [29]Falih N, Supangkat SH, Lubis FF, Prabowo OM. Revolutionizing Process Automation: The Synergy of Low-Code Development Platforms, Robotic Process Automation, and Integrated Smart System Platform. IEEE Access. 2024;12:118694–118706. https://doi.org/10.1109/ACCESS.2024.3447882
30. [30]Lee C, Kim HF, Lee BG. A Systematic Literature Review on the Strategic Shift to Cloud ERP: Leveraging Microservice Architecture and MSPs for Resilience and Agility. Electronics. 2024;13(14):2885. https://doi.org/10.3390/electronics13142885