Enterprise sop model driven process orchestration and dynamic adjustment method

Abstract

The application provides an enterprise SOP model driven process arrangement and dynamic adjustment method, including: carrying out element extraction and structural conversion on the original SOP document of the enterprise business process, extracting elements including process nodes, inter-node logical relationships, approval rules and data interaction requirements, to generate a structured SOP model; based on the structured SOP model, mapping the process nodes, inter-node logical relationships, approval rules and data interaction requirements to generate an initial process arrangement model; based on the process running data generated during the running of the initial process arrangement model, generating a process exception feature set; based on the process exception feature set, combining the original rules in the structured SOP model, generating a dynamically adjusted process arrangement model; based on the dynamically adjusted process arrangement model, generating an executable process model conforming to the enterprise SOP. The application alleviates the technical problems of process deviation from SOP and high verification cost in the traditional scheme.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more specifically, to a method for enterprise SOP model-driven process orchestration and dynamic adjustment. Background Technology

[0002] In the process of enterprise digital transformation, the standardization and efficiency of business processes directly affect the operational efficiency of enterprises. As the core basis for standardizing business processes, the digital implementation and automated orchestration of enterprise standard operating procedures (SOPs) have become key requirements for enterprises to improve their management level. Especially for enterprises whose business processes involve multiple nodes and multiple rule interactions, it is not only necessary to transform SOPs into executable processes, but also to quickly adapt the processes to changes in the business environment or deviations in process operation, so as to ensure that the processes always meet the enterprise's operational standards and efficiency requirements.

[0003] Existing enterprise business process orchestration solutions are mostly based on preset fixed process templates. First, based on the enterprise's historical business process experience or industry-standard process frameworks, static process templates are built that are not directly associated with the original SOP documents. Then, through code development or visual configuration tools, the static process templates are transformed into process instances that the system can recognize and execute, thus completing the process orchestration. During the process execution phase, monitoring tools independent of the process orchestration module are needed to collect process execution data. Once the data has accumulated to a certain scale, manual analysis is used to determine whether the process needs to be adjusted.

[0004] The existing solutions mentioned above have obvious technical flaws: the process templates they construct lack a structured connection with the company's original SOP documents. When anomalies are found and adjustments are made during process operation, adjustment strategies can only be formulated based on monitoring data and human experience. They cannot make precise adjustments based on the core rules of the original SOP (such as node logical relationships, approval requirements, etc.). This makes it easy for the adjusted process to deviate from the company's established SOP specifications, which not only affects the compliance of process execution, but also requires additional resources to perform a second verification of the consistency between the adjusted process and the SOP, increasing process management costs and time costs. Summary of the Invention

[0005] To address the aforementioned technical problems, this application provides a method for enterprise SOP model-driven process orchestration and dynamic adjustment, which can at least alleviate the aforementioned technical problems.

[0006] The technical solutions provided in this application are as follows:

[0007] A method for enterprise SOP model-driven process orchestration and dynamic adjustment includes: Step 1, extracting and structuring elements from the original SOP document of the enterprise business process, extracting elements including process nodes, logical relationships between nodes, approval rules, and data interaction requirements to generate a structured SOP model; Step 2, based on the structured SOP model, performing executable mapping on the process nodes, logical relationships between nodes, approval rules, and data interaction requirements to generate an initial process orchestration model; Step 3, generating a process anomaly feature set based on the process operation data generated during the operation of the initial process orchestration model; Step 4, generating a dynamically adjusted process orchestration model based on the process anomaly feature set and the original rules in the structured SOP model; Step 5, generating an executable process model that conforms to the enterprise SOP based on the dynamically adjusted process orchestration model.

[0008] The enterprise SOP model-driven process orchestration and dynamic adjustment method provided in this application has the following specific technical advantages:

[0009] This application transforms the core specifications of the original SOP into a structured data carrier through step 1, "extracting elements and performing structured transformation on the original SOP document to generate a structured SOP model containing process nodes, logical relationships between nodes, approval rules, and data interaction requirements." Then, through step 2, "performing executable mapping based on the structured SOP model to generate an initial process orchestration model," the source of the initial process orchestration is directly anchored to the original SOP, rather than relying on non-SOP related experience or frameworks. Compared to traditional solutions, the initial process orchestration model of this application has a higher degree of alignment with the enterprise's SOP specifications, avoiding the problem of initial processes being disconnected from SOPs from the outset.

[0010] This application provides precise anomaly localization for adjustments through step 3, "generating a process anomaly feature set based on the operational data of the initial process orchestration model." Then, through step 4, "generating a dynamically adjusted process orchestration model based on the process anomaly feature set and the original rules in the structured SOP model," the anomaly adjustment process always references the core elements of the original SOP, such as node logic relationships and approval rules, rather than relying on subjective human judgment. Compared to traditional solutions, the adjusted process orchestration model exhibits better consistency with the enterprise's SOP specifications, significantly reducing the likelihood of processes deviating from the SOP due to adjustments.

[0011] This application generates an executable process model conforming to the enterprise's SOPs through step 5, "based on the dynamically adjusted process orchestration model." Since the preceding steps (steps 1-4) consistently rely on the structured SOP model—initial orchestration originates from the SOP, and anomaly adjustments reference the original SOP rules—the resulting executable process model already possesses high SOP compliance, eliminating the need for extensive additional consistency verification work as in traditional solutions. Compared to traditional solutions, this application offers lower time and resource costs for process management and higher efficiency in process implementation. Attached Figure Description

[0012] Figure 1 This is a flowchart illustrating an enterprise SOP model-driven process orchestration and dynamic adjustment method according to an embodiment of this application.

[0013] Figure 2 This is a schematic diagram of a device for orchestrating and dynamically adjusting a process driven by an enterprise SOP model, as described in an embodiment of this application. Detailed Implementation

[0014] Figure 1 This is a flowchart illustrating a method for enterprise SOP model-driven process orchestration and dynamic adjustment, as described in an embodiment of this application. Figure 1 As shown, a method for enterprise SOP model-driven process orchestration and dynamic adjustment includes: Step 1, extracting and structuring elements from the original SOP document of the enterprise business process, extracting elements including process nodes, logical relationships between nodes, approval rules, and data interaction requirements to generate a structured SOP model; Step 2, based on the structured SOP model, performing executable mapping on the process nodes, logical relationships between nodes, approval rules, and data interaction requirements to generate an initial process orchestration model; Step 3, generating a process anomaly feature set based on the process operation data generated during the operation of the initial process orchestration model; Step 4, generating a dynamically adjusted process orchestration model based on the process anomaly feature set and the original rules in the structured SOP model; Step 5, generating an executable process model that conforms to the enterprise SOP based on the dynamically adjusted process orchestration model.

[0015] Optionally, step 2 specifically involves: based on the structured SOP model, performing executable mapping on the process nodes, logical relationships between nodes, approval rules, and data interaction requirements, so as to map the process nodes to system-recognizable task units, the logical relationships between nodes to the triggering conditions of task units, and the approval rules to the verification logic of task units, in order to generate an initial process orchestration model.

[0016] Optionally, step 2 specifically includes step 21: converting the process nodes in the structured SOP model into a system-recognizable format, parsing the operation subject, operation content, and data input / output items of the process nodes to generate system-recognizable task units.

[0017] Preferably, the specific implementation process of step 21 is as follows: Taking the process node in the structured SOP model as the initial processing object, the process node is first decomposed hierarchically. According to the functional module division standard of the enterprise business process (such as the "application initiation", "department review", "financial approval" and other functional modules in the manufacturing procurement process), the composite process node containing multiple business actions is decomposed into atomic nodes of single business actions. At the same time, the hierarchical affiliation of each atomic node in the overall business process is recorded (such as the "budget verification" atomic node under the "financial approval" module) to generate a process node hierarchical decomposition table.

[0018] Preferably, in the specific technical implementation of step 21, based on the generated process node hierarchy decomposition table, the operation subject parsing process is performed on the atomic nodes of each level: extract the execution role keywords (such as "auditor", "submitter", "verifier") in the atomic node description, associate them with the job information in the enterprise organizational structure database (this database stores the job names, job responsibilities and authority scope of each department of the enterprise), determine the specific operation position corresponding to each atomic node (such as the operation subject of the "budget verification" atomic node is "budget position in the finance department"), and establish the correspondence between atomic nodes and operation positions to generate a node-operation subject mapping table;

[0019] Preferably, in a scenario, when step 21 is specifically implemented, based on the generated node-operation subject mapping table, the operation content of each atomic node is subjected to structured transformation processing: the natural language operation description of the atomic node (such as "check the quantity of materials and inventory balance in the purchase application") is decomposed into a structured expression of "action instruction + operation object + judgment condition" (such as "action instruction: check; operation object: quantity of materials in the purchase application, inventory balance; judgment condition: quantity of materials ≤ inventory balance"), and at the same time, the order of operation execution is supplemented (such as "first extract inventory balance data, then check the quantity of materials"), so as to generate a structured list of node operation content;

[0020] Preferably, in the specific implementation of step 21, the generated structured list of node operation content is further parsed and processed for data input and output items: for each "operation object" in the structured operation content, its data source (e.g., "quantity of materials in purchase application" comes from the "quantity of materials" field of the purchase application form, and "inventory balance" comes from the "current inventory" data table of the inventory management system), data type (e.g., text, numeric, date) and data format requirements (e.g., numeric data retains integers, and date data adopts the "year-month-day" format) are determined. At the same time, the output data after the operation is executed (e.g., "verification result" and "abnormal prompt information") and its storage location (e.g., the "operation result table" in the intermediate database of the process) are determined to generate a node data interaction detail sheet;

[0021] Preferably, in the specific technical implementation of step 21, the generated process node hierarchy decomposition table, node-operation subject mapping table, structured list of node operation content, and node data interaction details are integrated and encapsulated according to a standardized data format recognizable by the system (such as JSON format, where the "nodeId" field corresponds to the unique identifier of the atomic node, the "layer" field corresponds to the level affiliation, the "operator" field corresponds to the operation subject position, the "operation" field corresponds to the structured operation content, and the "dataIO" field corresponds to the data input and output details). This ensures that the encapsulated data can be directly read and recognized by the process orchestration system as the smallest executable business unit, so as to generate a task unit recognizable by the system.

[0022] This technology differs from traditional solutions that simply rename process nodes. Through a full-chain process of "hierarchical decomposition - subject matching - content structuring - data IO parsing - standardized encapsulation," it solves the problems of process nodes being disconnected from actual enterprise positions and ambiguous operation content leading to inaccurate system identification in traditional solutions. Furthermore, through atomic decomposition and structured description, the generated task units possess the characteristics of "individual execution, precise traceability, and flexible combination," providing standardized basic data support for trigger condition mapping in step 22 and verification logic mapping in step 23.

[0023] Optionally, step 2 specifically includes step 22: based on task units, performing trigger condition mapping on the logical relationships between nodes in the structured SOP model, converting the sequential relationships, branching relationships, and merging relationships between nodes into the pre-execution conditions and post-trigger rules of task units, so as to generate the trigger conditions of task units.

[0024] Preferably, the specific implementation process of step 22 is as follows: Based on the system-identifiable task unit generated in step 21, and simultaneously calling the logical relationships between nodes recorded in the structured SOP model (these logical relationships are the original elements extracted in step 1, including the sequential order, branch selection, result merging, and other related descriptions between process nodes), the logical relationships between nodes are first processed by type identification—through keyword matching (such as "execute after completion" corresponding to sequential relationship, "if...then..." corresponding to branch relationship, "execute after both are completed" corresponding to merging relationship), three types of logical relationships are distinguished: sequential relationship, branch relationship, and merging relationship. The original process node identifiers corresponding to each type of logical relationship are marked to generate a classification table of logical relationships between nodes. This classification table of logical relationships between nodes will serve as the core basis for subsequent type conversion trigger conditions, ensuring that the conversion of each logical relationship can accurately correspond to the specific business scenario requirements (such as "after the purchase application is submitted, the department reviews it" in the manufacturing procurement process, which is a sequential relationship, and "if the purchase amount exceeds the preset threshold, the general manager approves it; otherwise, the department approves it" is a branch relationship).

[0025] Preferably, in the specific technical implementation of step 22, based on the generated logical relationship classification table between nodes, the sequential relationship is processed first: First, according to the sequential relationship records in the logical relationship classification table between nodes, the task units generated in step 21 are associated (by matching the original process node identifier with the "node affiliation" field of the task unit), and the preceding and following task units constituting the sequential order are determined (e.g., the preceding task unit is the "purchase application submission unit", and the following task unit is the "department review unit"); then, the constraint description of this sequential order in the structured SOP model is parsed (e.g., "after the preceding task is completed and the result is passed, the following task is triggered"), and the constraint description is converted into... Instead, a conditional expression is used: "Previous task unit execution status = completed" and "Previous task unit execution result = passed". At the same time, a trigger time limit is configured for this conditional expression (such as "The subsequent task is triggered within N hours after the completion of the preceding task, and it needs to be retried if the time limit is exceeded", where N is a general time limit set according to business needs, which can be set to 24 hours in the manufacturing procurement scenario and 48 hours in the administrative approval scenario) to generate a sequential triggering rule table. This sequential triggering rule table directly clarifies the association logic and triggering constraints between the preceding task unit and the subsequent task unit, avoiding the problem of process mis-triggering caused by simply recording "execution sequence" in the traditional solution while ignoring result constraints and time limit constraints.

[0026] Preferably, in a scenario, when step 22 is specifically implemented, based on the classification table of logical relationships between nodes, the branch relationships are then processed: First, according to the "judgment condition description" in the branch relationship record (such as "purchase amount > M yuan" and "supplier level is A" in the structured SOP model), the data source (such as "purchase amount" comes from the "amount" field of the "purchase requisition" data table, and "supplier level" comes from the "level" field of the "supplier management" data table) and comparison logic (such as ">", "=", "∈") in the judgment condition are extracted, and the natural language judgment condition is converted into a standardized data comparison expression (such as "purchase requisition.amount > M" and "supplier management.level = A"); then, the task units generated in step 21 are associated to determine the target task unit corresponding to each branch (such as "purchase amount > M yuan"). The "Purchase Amount ≤ M Yuan" corresponds to the "General Manager Approval Unit," and the "Purchase Amount ≤ M Yuan" corresponds to the "Department Approval Unit." Finally, the standardized data comparison expression is bound to the corresponding target task unit to form a "condition-task unit" mapping relationship. At the same time, the triggering premise of this branch relationship is marked (e.g., "the branch judgment is triggered only after the execution result of the preceding task unit 'Purchase Application Review Unit' is passed") to generate a branch triggering rule table. This branch triggering rule table is different from the traditional branch control scheme based only on fixed parameters. It achieves flexible adaptation of branch logic by dynamically associating business data fields (such as purchase amount and supplier level), which can meet the needs of dynamic adjustment of branch conditions under different business scenarios (e.g., when the enterprise adjusts the purchase amount threshold M, it only needs to update the value of M in the standardized data comparison expression, without reconfiguring the branch logic structure).

[0027] Preferably, in the specific implementation of step 22, based on the classification table of logical relationships between nodes, the merging relationship is finally processed: First, according to the "description of participating merging nodes" in the merging relationship record (e.g., "both departmental review node and financial budget node are completed"), the task units generated in step 21 are associated to determine all the preceding task units (e.g., "departmental review unit" and "financial budget unit") and their corresponding following task units (e.g., "purchase order generation unit") participating in the merging; then, the constraints on the merging logic in the structured SOP model are parsed (e.g., "all preceding task units are completed" and "at least N preceding task units are completed", where N is the number set according to business needs, such as in the manufacturing procurement process where "all preceding tasks are completed"). The "Completion" parameter in the project approval process can be set to "2 or more prerequisite tasks completed". This parameter converts the constraint into an aggregate condition of the execution status of the prerequisite task units (e.g., "Department review unit execution status = completed" and "Financial budget unit execution status = completed"). At the same time, it configures the merging waiting time limit (e.g., "After the first prerequisite task is completed, it must wait for other prerequisite tasks to be completed within N hours; if the time limit is exceeded, the merging is judged as failed") and sets the handling logic after the merging fails (e.g., "Trigger the re-execution of prerequisite tasks after the time limit is exceeded") to generate a merging trigger rule table. This merging trigger rule table solves the problem of process stagnation caused by the lack of time limit control and failure handling in the traditional merging logic, which only waits for "all to be completed", and improves the fault tolerance of the merging logic.

[0028] Preferably, in the specific technical implementation of step 22, the generated sequential triggering rule table, branch triggering rule table, and merge triggering rule table are integrated. First, the three rule tables are associated and bound to the task units generated in step 21 through task unit identifiers (ensuring that each triggering rule can accurately correspond to a specific task unit). Then, conflicts between rules are checked (if the same task unit is simultaneously set as both a "sequential subsequent unit" and a "branch target unit," the priority needs to be determined according to the original logic in the structured SOP model, prioritizing rules consistent with the core business process). Finally, the rules are arranged in a rule format recognizable by the process orchestration system (such as XML format, where "ruleType" is specified). The system encapsulates the following fields: "preTask" (identifying rule type), "condition" (identifying pre-task unit), "postTask" (identifying trigger condition), and "postTask" (identifying post-task unit) to generate the trigger condition for the task unit. This trigger condition will be directly used for integration with the validation logic in step 23, ensuring that the initial process orchestration model has the characteristics of "clear logic, well-defined conditions, and high executability." This differs from traditional solutions where trigger conditions are disconnected from task units and condition descriptions are vague. From a technical perspective, it achieves a precise transformation of the logical relationships between nodes into executable rules for the system, meeting the dual requirements of enterprise SOPs for both process logic standardization and flexibility.

[0029] Optionally, step 2 specifically includes step 23: performing validation logic mapping on the approval rules in the structured SOP model, converting the data validation items, permission validation items, and condition validation items in the approval rules into automatic validation rules in the task unit execution process, and integrating the task unit, the triggering conditions of the task unit, and the validation logic of the task unit to generate an initial process orchestration model.

[0030] Preferably, the specific implementation process of step 23 is as follows: Taking the approval rules in the structured SOP model as the initial processing object (the approval rules are the original elements extracted in step 1, including three core contents: data verification items, permission verification items, and condition verification items. For example, in the manufacturing procurement process, "the format of the purchase requisition amount must be numerical" belongs to the data verification item, "only the finance position can perform budget verification" belongs to the permission verification item, and "the purchase amount exceeding the preset value requires additional approval" belongs to the condition verification item), the approval rules are first classified and parsed. Through keyword recognition (such as "format" and "range" corresponding to data verification items, "position" and "permission" corresponding to permission verification items, and "if...require..." corresponding to condition verification items), the specific contents of the three types of verification items are distinguished, and the applicable business scenarios for each type of verification item are marked (such as "supplier qualification verification" applicable to the "supplier screening" node of the procurement process, and "budget amount verification" applicable to the "financial approval" node), an approval rule classification list is generated. This approval rule classification list provides a clear basis for subsequent automatic verification rule conversion by type, avoiding the problem of chaotic conversion logic caused by the mixing of various rules in traditional solutions.

[0031] Preferably, in the specific technical implementation of step 23, based on the generated approval rule classification list, the data validation items are processed first: First, the description of the data validation items in the approval rule classification list is extracted (e.g., "the 'material quantity' field in the purchase requisition form must be a positive integer, and the 'application date' must be before the current date"). Then, the "data source" (e.g., "material quantity" comes from the "quantity" field of the purchase requisition form, and "application date" comes from the "applyDate" field of the form), "validation logic" (e.g., "positive integer judgment" and "date sequence comparison") and "error message requirements" (e.g., "material quantity must be a positive integer") are parsed for each data validation item. The system requires data types to be specified (e.g., integers less than 0, application dates cannot be later than the current date). Then, based on the data type differences (numeric, date, text), corresponding validation algorithms are configured (e.g., numeric fields use a "numeric range judgment algorithm," date fields use a "date difference calculation algorithm," and text fields use a "format matching algorithm"). The validation logic is then bound to error messages to generate an automatic data validation rule table. This automatic data validation rule table differs from traditional solutions that only record "data to be validated." By clearly defining the data source, validation algorithm, and error messages, it ensures that the task unit can accurately locate data anomalies and provide feedback on the causes during execution, improving the operability and user guidance of data validation.

[0032] Preferably, in one scenario, when step 23 is specifically implemented, based on the approval rule classification list, the permission verification items are then processed: First, the description of the permission verification item is extracted (e.g., "When the purchase amount is ≤ preset value A, the department manager can approve; when the purchase amount is > preset value A, the general manager can approve"), and associated with the system-recognizable task unit generated in step 21 (by matching the "operation subject" field of the task unit with the "position" in the permission verification item), and the applicable task unit corresponding to each permission verification item is determined (e.g., "Department manager approval" corresponds to "department purchase review unit", "general manager approval" corresponds to "overall purchase review unit"); then the "permission scope constraint" in the permission verification item is parsed (e.g., "Department manager can only approve purchase applications of their own department", "General manager can approve all public department purchase applications"). The system uses the "Company Procurement Application" function to link the company's organizational structure data (storing the subordinate relationships between departments and positions). It transforms the scope of permissions into a "position-department-task unit" relationship (e.g., "Department Manager (Sales Department) → Sales Department Procurement Application → Department Procurement Review Unit"). Simultaneously, it configures handling logic for failed permission checks (e.g., "Automatically push to superior position when no permission is available") to generate an automatic permission check rule table. The preset value A is a general threshold set according to the company's business scale; it can be set to 50,000 yuan for small and medium-sized manufacturing enterprises and 100,000 yuan for large enterprises. This automatic permission check rule solves the problem of "unauthorized approval" or "insufficient permission stagnation" caused by the disconnect between permissions and task units / business scenarios in traditional solutions, improving the scenario adaptability of permission checks.

[0033] Preferably, in the specific implementation of step 23, based on the approval rule classification list, the condition verification items are processed last: First, the description of the condition verification item is extracted (e.g., "The purchase order can only be triggered when the purchase application simultaneously meets 'supplier level A' and 'material inventory balance < preset value B'; if only one condition is met, it needs to be re-evaluated"). The logical relationship between the conditions ("AND" and "OR") and the data source of each condition are parsed (e.g., "supplier level" comes from the "supplierLevel" field of the supplier management system, and "inventory balance" comes from the "stockQuantity" field of the inventory management system). Then, the natural language condition description is converted into a standardized logical expression (e.g., "supplierLevel = 'A level' ∧ stockQuantity < ... The preset value B, where “∧” represents the logical “AND”, specifies the subsequent processing path when the condition is not met (e.g., “if only the supplier level is A but the inventory is sufficient, push to the ‘Inventory Optimization Assessment Unit’; if only the inventory is insufficient but the supplier level is not A, push to the ‘Supplier Screening Unit’”). The preset value B is a general threshold set according to the material consumption rate, such as 30 days of consumption for commonly used materials and 90 days of consumption for unpopular materials, to generate an automatic condition verification rule table. This automatic condition verification rule table is different from the traditional single-condition verification scheme. Through multi-condition logical combination and differentiated processing path design, it avoids the problem of “incomplete conditions leading to process misjudgment” in the traditional scheme and improves the logical integrity of condition verification.

[0034] Preferably, in the specific technical implementation of step 23, the generated automatic data verification rule table, automatic permission verification rule table, and automatic condition verification rule table are used as processing objects. First, the three types of automatic verification rules are bound to the corresponding system-recognizable task units through the task unit identifier (the "taskId" field of the task unit generated in step 21). This ensures that each task unit matches the complete set of automatic verification rules corresponding to its business function (e.g., "department procurement approval unit" is bound to "data verification (amount format) + permission verification (department manager position) + condition verification (procurement amount ≤ A)"). This generates a task unit-automatic verification rule association table. During the generation of this task unit-automatic verification rule association table, the "logical consistency between automatic verification rules" needs to be checked simultaneously. For example, if the automatic data verification rule requires "procurement amount to be a positive integer", while the automatic condition verification rule sets a threshold based on "procurement amount", it is necessary to ensure that the definitions of the "procurement amount" field are consistent to avoid logical conflicts.

[0035] Preferably, in the specific implementation of step 23, the task unit-automatic verification rule association table, the system-recognizable task units generated in step 21, and the triggering conditions of the task units generated in step 22 are used as the joint processing objects. First, three types of elements are integrated: the triggering conditions of the task units are used as "prerequisites for the execution of automatic verification rules" (e.g., the triggering condition of "department procurement review unit" is "the procurement application submission unit has been completed," and this triggering condition must be met before the subsequent automatic verification rules are executed); the automatic verification rules in the task unit-automatic verification rule association table are used as "core constraints for the execution of task units," forming a complete logical chain of "triggering condition → task unit → automatic verification rule"; then, the system-recognizable standardized format (e.g., YAML format, containing three core fields: "task_info", "trigger_condition", and "validation_rules") is arranged according to the process. The "on_rules" field is further subdivided into "data_check", "permission_check", and "condition_check" subfields, each corresponding to the specific content of the three types of automatic verification rules. This is then encapsulated. Finally, the integrated logic is checked to ensure it conforms to the original rules of the structured SOP model (e.g., whether the integrated "Overview Procurement Audit Unit" automatic verification rules are consistent with the description of "General Manager Approval Authority" in the SOP). After confirming no conflicts, an initial process orchestration model is generated. This initial process orchestration model differs from the traditional design of "dispersed storage of tasks, trigger conditions, and automatic verification rules." Through "logic chain integration + standardized encapsulation + original rule verification," it achieves deep association of the three elements, solving the problem of low process compliance caused by "no verification after triggering" and "verification being disconnected from tasks" during process execution in traditional solutions. This gives the initial process orchestration model the superior characteristics of "verification upon triggering, compliance upon verification."

[0036] Optionally, step 3 specifically involves: performing anomaly indicator analysis on the process operation data generated during the initial process orchestration model operation, identifying anomaly indicators including node processing time exceeding limits, rule verification failure, and data interaction interruption, in order to generate a process anomaly feature set.

[0037] Optionally, step 3 specifically includes step 31: extracting indicators from the process operation data generated during the operation of the initial process orchestration model, including the processing time of each task unit, the execution result of automatic verification rules, and the data interaction status, to generate a set of operation indicator datasets.

[0038] Preferably, the specific implementation process of step 31 is as follows: Taking the original process operation data generated during the operation of the initial process orchestration model as the initial processing object (this original data includes three core data types: process log, task execution record, and data transmission log, such as the start log of the "purchase application review unit" in the manufacturing procurement process, the execution record of the "budget automatic verification rule", and the transmission log of the "purchase application form data" to the inventory system), the original process operation data is first subjected to the scope of collection and format unification processing—based on the task unit identifier ("taskId" generated in step 21), the automatic verification rule identifier ("ruleId" generated in step 23), and the data interaction contained in the initial process orchestration model generated in step 2, the data is first subjected to the scope of collection and format unification processing. The interface identifier (“interfaceId” generated in step 21) is used to filter out the raw data associated with the identifier, excluding irrelevant and redundant data (such as system background operation and maintenance logs). Then, the raw data in different formats (such as JSON format task logs, CSV format execution records, and TXT format transmission logs) are converted into a unified structured data format (such as a relational database table structure, containing fields of “data type”, “association identifier”, “generation time”, and “data content”) to generate a standardized raw running dataset. This standardized raw running dataset solves the problem of difficulty in subsequent indicator extraction caused by mixed raw data formats and missing association identifiers in traditional solutions, and provides a unified and clearly associated data foundation for indicator extraction.

[0039] Preferably, in the specific technical implementation of step 31, based on the generated standardized original running dataset, the "processing time of each task unit" indicator is first extracted: by matching the "association identifier" field in the standardized original running dataset with the "taskId" of the system-identifiable task unit generated in step 21, the "start record" and "completion record" corresponding to each task unit are located (e.g., the start record of the "procurement application review unit" contains the "start_time" field, and the completion record contains the "end_time" field); the time difference between "end_time" and "start_time" of each task unit is calculated (the time difference is calculated using a uniform time unit, such as seconds), and the processing time of the task unit is recorded simultaneously. The processing time corresponds to the business scenario information (e.g., "a purchase application review unit with a processing time of 120 seconds corresponds to the raw material procurement scenario of the sales department"). If a task unit has a pause record (e.g., "pause_time" due to the temporary offline status of the operator), the pause time is deducted from the time difference to ensure that the processing time is the actual effective processing time. The "taskId", processing time, and business scenario information of each task unit are associated and stored to generate a task unit processing time detail table. This task unit processing time detail table differs from the traditional solution that only records the "total time". By associating the task unit identifier with the business scenario, the time limit judgment in the subsequent step 32 can accurately locate the specific task and scenario, improving the targeting of anomaly identification.

[0040] Preferably, in one scenario, when implementing step 31, based on the standardized original running dataset, the "automatic verification rule execution result" metric is extracted: by matching the "association identifier" field in the standardized original running dataset with the "ruleId" of the automatic verification rule generated in step 23, the "execution record" corresponding to each automatic verification rule is located (e.g., the execution record of the "data automatic verification rule" generated in step 23 includes the "ruleResult" field and the "failure reason" field); the "success" or "failure" status in the "ruleResult" field is extracted, and the "failure" status is... The records are further analyzed to determine the "failure reason" field (e.g., "incorrect data format," "insufficient permissions," "condition not met," corresponding to the failure of the data validation, permission validation, and condition validation items in step 23, respectively). Simultaneously, the "generation time" field and the "associated taskId" field in the standardized original running dataset are correlated to determine the task unit and execution time corresponding to the execution result of each automatic validation rule (e.g., "Automatic permission validation rule (ruleId=R001) failed to execute; the corresponding task unit is the procurement application review unit (taskId=T002), and the execution time is 2024-XX-XX"). 10:30:00); integrate and store "ruleId", automatic verification rule execution result, failure reason, associated "taskId", and execution time to generate an automatic verification rule execution result table; for example, in the manufacturing procurement scenario, "Data automatic verification rule (R002, verifying that the purchase amount is a positive integer) execution failed, the failure reason is 'the purchase amount field is text type', associated task unit T002", such detailed records provide a clear basis for the rule verification failure identification in the subsequent step 32, avoiding the difficulty of anomaly analysis caused by only knowing "failure" without knowing the reason in the traditional solution.

[0041] Preferably, in the specific implementation of step 31, based on the standardized original running dataset, the "data interaction status" indicator is finally extracted: The "association identifier" field in the standardized original running dataset is matched with the "interfaceId" of the task unit generated in step 21 (this "interfaceId" corresponds to the data interaction interface between the task unit and the external system, such as I001 being the data interaction interface identifier between the "purchase application review unit" and the inventory system), locating the "transmission log" (containing the fields of "transmission status code," "data volume," and "received system feedback") corresponding to each data interaction interface; according to the preset status code mapping rules (such as status code 200 representing "transmission successful," status code 500 representing "transmission interrupted," and status code 404 representing "received system not responding"), the "transmission status code" is converted to "success," "interrupted," and "not responding." The system identifies three data interaction states: "interrupted" and "non-responsive." For records of "interrupted" or "non-responsive" states, it extracts the "transmission interruption location" (e.g., "transmission interrupted in the 'supplier number' field of the purchase requisition form") or the "non-responsive system name" (e.g., "inventory management system non-responsive"). Simultaneously, it associates the "associated taskId" with the "generation time" to determine the task unit and interaction time corresponding to each data interaction state. The system integrates and stores the "interfaceId," data interaction state, supplementary information (interruption location / non-responsive system), associated "taskId," and interaction time to generate a data interaction state table. This data interaction state table differs from the traditional approach that only records "whether transmission was successful." By supplementing information such as the interruption location and non-responsive system, it provides accurate anomaly location for subsequent step 32's interaction interruption identification, improving the efficiency of data interaction anomaly handling.

[0042] Preferably, in the specific technical implementation of step 31, the generated task unit processing time detail table, automatic verification rule execution result table, and data interaction status table are used as the joint processing objects. First, the three tables are linked and integrated through the "taskId" field (ensuring that the processing time, corresponding automatic verification rule execution result, and corresponding data interaction status of the same task unit can correspond one-to-one, such as "the procurement application review unit with taskId=T002, processing time 120 seconds, automatic verification rule R001 executed successfully, R002 executed unsuccessfully, and data interaction interface I001 status is successful"). Then, the data integrity during the integration process is checked (if a task unit only has a processing time record but no automatic verification rule execution result record, it needs to be marked as "automatic verification rule not executed"). It also supplements the list of automatic verification rules that should be matched for the task unit in step 23. Finally, according to the structure of "task unit as the core and multi-indicator association", a running indicator dataset containing fields such as "taskId", "processing time", "automatic verification rule execution result list", "data interaction status list" and "business scenario" is generated. The generation process of this running indicator dataset, through "multi-indicator association integration + data integrity verification", ensures the correlation between indicators and data integrity. This is different from the situation in traditional solutions where indicators are stored separately and without association. It provides structured data support for the "multi-dimensional abnormal indicator comparison" in the subsequent step 32. From a technical point of view, it solves the problem of incomplete anomaly identification caused by the fragmentation of traditional indicators and meets the enterprise's need for multi-dimensional monitoring of process operation status.

[0043] Optionally, step 3 specifically includes step 32: based on the running indicator dataset, comparing the processing time of each task unit with the preset time threshold, comparing the execution result of the automatic verification rule with the preset success status, and comparing the data interaction status with the preset normal status, identifying indicators whose processing time exceeds the preset time threshold, whose automatic verification rule execution result is a failure, and whose data interaction status is interrupted, so as to generate a preliminary abnormal indicator set.

[0044] Preferably, the specific implementation process of step 32 is as follows: Based on the operational indicator dataset generated in step 31 (this dataset contains fields such as "taskId", "processing time", "automatic verification rule execution result list", "data interaction status list", and "business scenario", such as "taskId=T002 (purchase application review unit), processing time 360 ​​seconds, automatic verification rule R002 execution failure, data interaction interface I001 status success, business scenario is regular procurement" in the manufacturing procurement process), firstly, the scenario-based preset thresholds and status standards are constructed—based on the "taskId" in the operational indicator dataset, the system-identifiable task units generated in step 21 are associated (the business functions of the task units are determined, such as "purchase application review unit" and "budget verification unit"), combined with " The "Business Scenario" field (e.g., regular procurement, emergency procurement, special procurement) references the timeliness and quality requirements for different tasks and scenarios in the enterprise's SOP (e.g., the SOP stipulates that "the application review time for regular procurement shall not exceed 300 seconds, and for emergency procurement, it shall not exceed 180 seconds"). Preset standards are then developed for each task and scenario, including preset time thresholds, preset success status (fixed as "verification passed"), and preset normal status (fixed as "data transmission completed"), to generate a scenario-based preset standard table. This scenario-based preset standard table differs from the traditional design where "all tasks share a fixed threshold." Through the dual association between task function and business scenario, the preset standards have better scenario adaptability, avoiding the problems of "misjudging normal as abnormal" in emergency scenarios or "missing abnormal judgment" in regular scenarios caused by traditional fixed thresholds.

[0045] Preferably, in the specific technical implementation of step 32, based on the generated scenario-based preset standard table and the "task unit processing time" information in the operation indicator dataset generated in step 31, the first level of anomaly identification is carried out: First, through the "taskId" and "business scenario" fields, the processing time of each task unit in the operation indicator dataset (from the task unit processing time details table in step 31) is associated and matched with the corresponding preset time threshold in the scenario-based preset standard table (e.g., "taskId=T002 (procurement application review unit) + regular procurement scenario" corresponds to a preset time threshold of 300 seconds, "taskId=T002 + emergency procurement scenario" corresponds to 180 seconds); then, the difference between the actual processing time of the task unit and the preset time threshold is calculated. If the actual processing time is less than the preset time threshold, the difference is considered. If the duration exceeds the preset threshold, it is marked as "duration exceeded", and the excess duration (actual duration - preset threshold), the associated "taskId", and the business scenario are recorded. If the actual duration is less than or equal to the preset threshold, it is marked as "duration normal" and excluded. All "duration exceeded" records are integrated, and the "abnormal subtype = node processing time exceeded" field is added to generate a duration exceeded indicator table. For example, in a regular procurement scenario in manufacturing, "the actual processing time of the procurement application review unit of taskId=T002 is 360 seconds, the preset threshold is 300 seconds, the excess is 60 seconds, and it is marked as duration exceeded". This table provides the first type of abnormal data for the subsequent preliminary abnormal indicator set, and all records can be traced to the specific task unit and business scenario through "taskId".

[0046] Preferably, in a scenario, when step 32 is specifically implemented, a second layer of anomaly identification is carried out based on the "preset success status" (i.e., "verification passed") in the scenario-based preset standard table and the "automatic verification rule execution result list" in the operation indicator dataset generated in step 31: First, the "automatic verification rule execution result list" field is extracted from the operation indicator dataset (this field comes from the automatic verification rule execution result table in step 31 and contains "ruleId", "ruleResult", and "failure reason" information), and records where the "ruleResult" field is not equal to "verification passed" (i.e., "verification failed" records) are filtered out; then, the "taskId" is associated with the automatic verification rule type generated in step 23 (distinguishing between data verification items, permission verification items, and condition verification items), and "anomaly subtype = rule" is added to each failed record. The table records "Verification Failure" and specific failure types (e.g., "Data Verification Failure", "Permission Verification Failure", "Condition Verification Failure"), while retaining the "Failure Reason" field (e.g., "Incorrect Data Format", "Operation Not Performed by the Specific Position", "Purchase Amount Did Not Meet the Trigger Condition"). All "Verification Failure" records are integrated to generate a rule verification failure index table. For example, "The automatic verification rule R005 (condition verification item) of taskId=T003 (budget verification unit) failed to execute. The reason for the failure is 'The purchase amount did not exceed the preset value C (e.g., 50,000 yuan) but triggered the general manager's approval', and it is marked as rule verification failure (condition verification failure)". This table differs from the traditional design that only records "Verification Failure" without classification. By refining the failure types, it provides more accurate anomaly information for feature labeling in the subsequent step 33, improving the efficiency of anomaly analysis.

[0047] Preferably, in the specific implementation of step 32, based on the "preset normal state" (i.e., "data transmission completed") in the scenario-based preset standard table and the "data interaction status list" in the operation indicator dataset generated in step 31, a third layer of anomaly identification is carried out: First, the "data interaction status list" field is extracted from the operation indicator dataset (this field comes from the data interaction status table in step 31 and contains "interfaceId", "interaction status", and "supplementary information"), and records where the "interaction status" field is not equal to "data transmission completed" (i.e., "interrupted" and "unresponsive" records) are filtered out; then, the interaction objects corresponding to "taskId" and "interfaceId" are associated (e.g., "interfaceId=I001 corresponds to the inventory management system, inte...). (rfaceId=I002 corresponds to the supplier management system). For each abnormal record, add "Abnormal subtype = data interaction interruption" and specific abnormal details (such as "interruption location = 'supplier number' field in the purchase requisition form" and "unresponsive system = inventory management system"). Integrate all "interaction abnormal" records to generate a data interaction interruption index table; for example, "taskId=T004 (supplier qualification review unit) data interaction interface I002 (interaction with the supplier management system) status is 'unresponsive', supplementary information is 'system maintenance in progress', marked as data interaction interruption (unresponsive)". This table, by supplementing abnormal details, solves the technical defect of the traditional solution of "only knowing the interaction abnormality but not being able to locate the problem point", and provides accurate location basis for subsequent abnormal handling.

[0048] Preferably, in the specific technical implementation of step 32, the generated time-exceeding indicator table, rule verification failure indicator table, and data interaction interruption indicator table are used as joint processing objects to carry out abnormal data integration: First, the records in the three tables are associated through the "taskId" field. If the same "taskId" has multiple types of abnormalities (such as a procurement application review unit having both time-exceeding and verification failure), the records are merged and all abnormal subtypes and details are supplemented (such as "taskId=T002, abnormal subtype=node processing time exceeding limit + rule verification failure, exceeding limit time 60 seconds, failure reason=data format error"). Then, the uniqueness of the data in the integration process is checked to exclude duplicate records (such as the same "ruleId" verification failure record not being duplicated). (Repeated in the same table); Finally, add a "preliminary anomaly identifier" (such as Y001, Y002) to each integrated anomaly record, and unify the field format (including "preliminary anomaly identifier", "taskId", "anomaly subtype", "anomaly details", and "business scenario" fields) to generate a preliminary anomaly indicator set; the generation process of this preliminary anomaly indicator set realizes the technical logic of "dimension-based identification and association integration". Each sub-indicator table generated in each preceding step serves as the core data source for subsequent integration, ensuring no logical breakpoints; at the same time, this set, through the dual recording of "anomaly subtype + details", not only meets the feature annotation requirements of step 33, but also differs from the traditional "only listing anomaly indicators" solution, achieving the structuring and refinement of anomaly information from a technical perspective.

[0049] Optionally, in step 33, feature annotation is performed on the preliminary abnormal indicator set, and the abnormal type and associated task unit information corresponding to each abnormal indicator are annotated and integrated to form a process abnormal feature set. The abnormal types include node processing time exceeding the limit, rule verification failure, and data interaction interruption.

[0050] Preferably, the specific implementation process of step 33 is as follows: Taking the preliminary anomaly indicator set generated in step 32 as the initial processing object (this set contains fields such as "preliminary anomaly identifier", "taskId", "anomaly subtype", "anomaly details", and "business scenario", such as "preliminary anomaly identifier Y001, taskId=T002, anomaly subtype=duration exceeding limit, anomaly details=60 seconds exceeding limit, business scenario=routine procurement"), firstly, standardize the annotation of anomaly types—based on the three anomaly types defined in the claims (node ​​processing time exceeding limit, rule verification failure, data interaction interruption), classify and map the "anomaly subtypes" in the preliminary anomaly indicator set: if the "anomaly subtype" is "duration exceeding limit", then it is annotated as "node processing time exceeding limit". If the error is "data verification failed", "permission verification failed", or "condition verification failed", it will be uniformly labeled as "rule verification failed"; if the error is "transmission interrupted" or "receiving system not responding", it will be uniformly labeled as "data interaction interrupted"; at the same time, each record will be supplemented with an "abnormal type code" (e.g., JT-001 represents node processing time exceeding limit, JY-001 represents rule verification failed, and JZ-001 represents data interaction interrupted) to generate an anomaly set with anomaly type annotation; this annotation process solves the problem of "dispersed anomaly subtype descriptions" in the initial anomaly index set, makes the anomaly types conform to the unified standard defined in the claims, and provides a standardized basis for the classification and annotation in the subsequent step 41, which is different from the difficulty of subsequent processing caused by the chaotic anomaly type descriptions in the traditional scheme.

[0051] Preferably, in the specific technical implementation of step 33, the generated exception set with exception type annotations is used as the processing object, and then the full information annotation of the associated task unit is carried out: the system-identifiable task unit generated in step 21 is associated through the "taskId" field, and three types of core information of the task unit are extracted: "operation subject" (such as the procurement department review post, the finance department budget post), "business function description" (such as regular procurement application review, emergency procurement budget verification), and "data input and output item identifier" (such as procurement application form field identifier F001, inventory data interface identifier I001), and supplemented to the exception set with exception type annotations, forming This creates a record associated with "Abnormality Type - Task Unit Information"; for example, "Preliminary Abnormality Identifier Y001, taskId=T002, Abnormality Type=Node Processing Time Exceeded Limit, Operation Subject=Purchasing Department Review Position, Business Function Description=Regular Purchase Application Review, Data Input / Output Item Identifier=F001 (Purchase Amount Field)". This annotation process differs from the traditional approach that only associates "taskId" without supplementing task unit details. It allows abnormal records to be directly traced to specific operation positions and business functions, providing richer association dimensions for the subsequent "Abnormality Type - Task Unit Classification" step 41 and improving classification accuracy.

[0052] Preferably, in a scenario, when step 33 is specifically implemented, the exception set with exception type annotation (with complete task unit information supplemented) is used as the processing object, and further exception relationship annotation is carried out—analyzing the consistency between the "taskId" relationship of different exception records in the preliminary exception indicator set and the "business scenario", identifying related exceptions caused by upstream and downstream dependencies of the same business process: if there are "taskId=T002 (procurement application review unit, exception type=node processing time exceeded)" and "taskId=T003 (budget verification unit, exception type=rule verification failed)" and both belong to the "regular procurement" scenario, and the triggering condition of the task unit generated in step 22 shows "T003 needs to be triggered after T002 is completed", then "T003 rule verification" is annotated. The error message "The failure to verify T002 is an associated anomaly due to the time limit exceeding the limit" is added, along with "Associated anomaly identifier" (e.g., Y001 associated with Y002) and "dependency relationship" (T002→T003). If the anomaly occurs independently (without upstream or downstream dependencies), it is marked as "No associated anomaly". This generates an anomaly set with associated relationship annotations. For example, in the manufacturing procurement process, "Y002 (T003 rule verification failure) is marked as an associated anomaly of Y001 (T002 time limit exceeding the limit), with the dependency relationship being the budget verification triggered after the procurement application is approved". This annotation process solves the problem of "viewing anomalies in isolation and ignoring the chain reaction of anomalies caused by process dependencies" in the traditional solution. It provides key information on the "scope of impact of anomalies" for the subsequent step 42 when matching the original rule clauses, improving the comprehensiveness of rule matching.

[0053] Preferably, in the specific implementation of step 33, the abnormal set with associated labels is used as the processing object, and the abnormal context details are supplemented by adding three types of context information related to the abnormality in the operation index dataset generated in step 31: "time information" (time of occurrence of abnormality, duration of abnormality), "environmental information" (such as whether the abnormality occurred during a business peak period, whether the system resource utilization rate exceeded the preset load threshold, the preset load threshold can be set according to the enterprise system configuration, such as 70% for small and medium-sized enterprises and 85% for large enterprises), and "historical occurrence frequency" (the number of times the "taskId" has occurred in the same business scenario in the past 30 days), and adding them to the abnormality record; For example, “Y001 anomaly occurred at 10:00 AM on a weekday (peak business period), system resource utilization was 75%, and similar anomalies occurred twice in the past 30 days”; at the same time, the “verification item identifier” related to the anomaly in the automatic verification rules generated in step 23 (such as “ruleId=R002” associated with rule verification failure) is associated with the anomaly, forming a set of anomalies with contextual details; this annotation process is different from the traditional solution that only records the “anomaly itself” without supplementing the context, so that the anomaly record has multi-dimensional characteristics of “time-environment-history”, providing a basis for “anomaly severity and occurrence pattern” when matching adjustment strategies in the subsequent step 43, avoiding the problem of “one-size-fits-all” adjustment strategies.

[0054] Preferably, in the specific technical implementation of step 33, the anomaly set with contextual details is used as the final integration object to carry out the structured construction of the process anomaly feature set: First, the core fields of the feature set are determined, including "unique anomaly identifier" (composed of "preliminary anomaly identifier + business scenario code", such as Y001-CG001, where CG001 represents a regular procurement scenario), "anomaly type" (three categories: strict reuse node processing time exceeding limit, rule verification failure, and data interaction interruption), "related task unit information" (including taskId, operation subject, business function description, and data input / output item identifier), "anomaly details" (including the time exceeding the limit / loss period). The data structure includes: "Failure Reason / Interruption Location, Anomaly Occurrence Time, Environmental Information, Historical Frequency," "Associated Anomaly Information" (including associated anomaly identifiers and dependencies; fill in "None" if there is no association), and "Associated Rule Identifiers" (including ruleId and interfaceId; fill in "None" if none exists). Next, check the integrity of each field to ensure no record is missing (e.g., if "Associated Rule Identifier" indicates node processing time exceeding limits, fill in "None"; if it indicates rule validation failure, fill in the corresponding ruleId). Finally, sort by "Unique Anomaly Identifier," encapsulate it in a structured data format (e.g., a JSON array), with each array element corresponding to a fully annotated anomaly record. This generates a set of process anomaly features. For example, in a manufacturing procurement scenario, a complete feature record would be: "Unique anomaly identifier Y001-CG001, anomaly type = node processing time exceeded limit, associated task unit information = {taskId: T002, operating subject: procurement department review post, business function description: routine procurement application review, data input / output item identifier: F001}, anomaly details = {exceeded limit duration: 60 seconds, occurrence time: weekday 10:00, environment information: peak business period / resource utilization rate 75%, historical frequency: 2 times / 30 days}, associated anomaly information = {association identifier: Y002, dependency relationship: T0 02→T003}、Association rule identifier: None”; This process's anomaly feature set achieves comprehensiveness and usability of anomaly information through "multi-dimensional annotation + structured integration". The results of each preceding annotation step serve as the core data source for the integration stage (such as anomaly type annotation, task unit information annotation, association relationship annotation, and context annotation are all included in the feature set fields), forming a complete logical closed loop; Its technological innovation lies in breaking through the limitations of traditional "fragmented anomaly information" and providing full-chain data support for the subsequent step 4 (dynamic adjustment) through refined annotation of association relationships and context, including "anomaly root cause location, impact scope assessment, and adjustment strategy matching".

[0055] Optionally, step 4 specifically involves: based on the process anomaly feature set and combined with the original rules in the structured SOP model, performing rule matching and parameter updates on the initial process orchestration model, matching the anomaly indicators in the process anomaly feature set with the preset adjustment rule library, and updating the triggering conditions or verification logic of the task unit according to the matching results to generate a dynamically adjusted process orchestration model.

[0056] Optionally, step 4 specifically includes step 41, classifying and labeling the process exception feature set according to exception type and associated task unit, distinguishing the associated task unit identifiers corresponding to three types of exceptions: node processing time exceeding limit, rule verification failure, and data interaction interruption, in order to generate the classified exception feature set.

[0057] Preferably, the specific implementation process of step 41 is as follows: Taking the process anomaly feature set generated in step 33 as the initial processing object (this set contains fields such as "unique anomaly identifier", "anomaly type", "associated task unit information", "anomaly details", and "associated anomaly information", such as "unique anomaly identifier Y001-CG001, anomaly type = node processing time exceeded limit, associated task unit information = {taskId=T002, operation subject = procurement department review post}, anomaly details = exceeded limit by 60 seconds, associated anomaly information = Y002-CG001 (T003 rule verification failed)" in the manufacturing procurement process), the feature set preprocessing before classification is first carried out - checking the integrity of the core fields of each record in the process anomaly feature set, focusing on verifying the "anomaly type" (which needs to strictly match the node). The preprocessing process includes three categories of descriptions: processing time exceeding limits, rule verification failure, and data interaction interruption. The "taskId" in the "Associated Task Unit Information" (which must be able to associate with the system-recognizable task unit generated in step 21) and the logical consistency of the "Associated Anomaly Information" (such as whether the "Anomaly Type" of the associated anomaly has upstream or downstream dependencies with the main anomaly) are considered. For records lacking "taskId" or with non-standard "Anomaly Type" descriptions, the information is supplemented by reverse association between the preliminary anomaly indicator set in step 32 and the task unit list in step 21 to generate a preprocessed process anomaly feature set. This preprocessing process solves the problem of potential data loss or non-standard descriptions in the original feature set, laying a data foundation for subsequent accurate classification, unlike the "classification omission" or "misclassification" problems caused by direct classification in traditional solutions.

[0058] Preferably, in the specific technical implementation of step 41, based on the generated preprocessed process anomaly feature set, a first-dimensional classification is performed: the feature set is divided into three temporary classification subsets according to the "anomaly type" field, namely, the node processing time exceeding the limit subset, the rule verification failure subset, and the data interaction interruption subset. The division is achieved through precise matching of the "anomaly type" field: all records with the "anomaly type" field value of "node processing time exceeding the limit" are assigned to the node processing time exceeding the limit subset, and the "classification identifier" of this subset is recorded as FL-001; records with the "anomaly type" value of "rule verification failure" are assigned to the rule verification failure subset, and the classification identifier is FL-002; records with the "anomaly type" value of "data interaction interruption" are assigned to the data interaction interruption subset, and the classification identifier is FL-003. Each temporary category subset retains the complete fields of the process exception feature set, distinguishing the type only by the category identifier, such as "Y001-CG001 (T002 time limit exceeded) is classified into the FL-001 subset, and Y002-CG001 (T003 rule verification failed) is classified into the FL-002 subset". This classification method is different from the traditional solution's design of "classifying in a general way according to the time of exception occurrence or business scenario". By dividing the "exception type" into precise dimensions, the rule clause matching in the subsequent step 42 can directly focus on the same type of exception, improving the matching efficiency.

[0059] Preferably, in a scenario, when step 41 is specifically implemented, the three generated temporary classification subsets (FL-001, FL-002, FL-003) are used as processing objects to carry out the second-dimensional association task unit identification deepening annotation: for each temporary classification subset, the system-identifiable task unit generated in step 21 is associated through the "taskId" field in "Associated Task Unit Information", and the two types of supplementary identifiers, "task unit code" (such as TC-002, which corresponds one-to-one with taskId=T002 and is used for system fast indexing) and "belonging business module identifier" (such as BM-CG, which represents the procurement business module, and BM-CW, which represents the financial business module), are extracted and added to each record of the corresponding temporary classification subset to form an association relationship of "abnormal record-task unit multiple identifiers". For example, in the FL-001 subset (node ​​processing time exceeded the limit), the record "Y001-CG001" is supplemented with "task unit code = TC-002, business module identifier = BM-CG". This in-depth annotation process solves the problems of "low system indexing efficiency" and "unclear business module affiliation" caused by using only "taskId" to associate task units in the traditional solution. It enables the classified subset to accurately associate task units and quickly locate the business module to which it belongs, which facilitates the matching of module-level rule clauses in the structured SOP model in the subsequent step 42.

[0060] Preferably, in the specific implementation of step 41, the three temporary classification subsets with supplemented task unit multi-identifiers are used as processing objects to further classify and integrate the associated anomalies: for each temporary classification subset containing "associated anomaly information" (such as the Y001-CG001 record of the FL-001 subset being associated with the Y002-CG001 record of the FL-002 subset), according to the "dependency relationship" marked in step 33 (such as T002→T003), the associated anomaly record is assigned to the "associated anomaly submodule" of the temporary classification subset where the main anomaly is located, rather than being scattered separately in other subsets. For example, Y002-CG001 (which failed the T003 rule check and originally belonged to the FL-002 subset) is classified as an "associated exception submodule" into the FL-001 subset where Y001-CG001 is located. At the same time, the original record of Y002-CG001 in the FL-002 subset is retained and marked "associated with the main exception Y001-CG001 in the FL-001 subset". This integration process is different from the "exception logic fragmentation" problem caused by "independent classification of associated exceptions" in the traditional solution. It enables the main exception and associated exceptions to reflect their dependency relationship within the same category subset. When matching rule clauses in the subsequent step 42, the exception chain reaction can be analyzed simultaneously to improve the comprehensiveness of rule matching.

[0061] Preferably, in the specific technical implementation of step 41, the three temporary classification subsets that have completed the integration of associated anomalies are taken as the final processing objects, and the structured generation of the anomaly feature set after classification is carried out: "Classification meta-information" is added to each temporary classification subset, including classification identifier (FL-001 / FL-002 / FL-003), number of classification records, list of task unit codes involved (e.g., FL-001 subset involves TC-002, TC-005), and set of business module identifiers (e.g., BM-CG, BM-JJ); then, the process is carried out according to "Classification identifier → Classification meta-information → Anomaly record list (including The hierarchical structure of the "Association Anomaly Submodule" integrates the three temporary classification subsets into unified structured data (such as XML format, where the "classification" tag corresponds to the classification identifier, the "metaInfo" tag corresponds to the classification meta information, and the "abnormalRecords" tag corresponds to the list of abnormal records). Finally, it checks the consistency of association anomaly labeling between each classification subset (e.g., if a record is an associated anomaly in the FL-001 subset, the original record in the FL-002 subset must be labeled with the association status simultaneously). After confirming that there are no errors, the classified anomaly feature set is generated. For example, in the categorized anomaly feature set, the structure of the FL-001 subset (node ​​processing time exceeded the limit) is: "Category Identifier = FL-001, Category Meta-information = {Number of Records = 2, Task Unit Code List = [TC-002, TC-005], Business Module Identifier Set = [BM-CG]}, Anomaly Record List = [Y001-CG001 (including associated anomaly sub-modules Y002-CG001), Y003-JJ001 (TC-005, emergency procurement time exceeded the limit)]". This technology achieves "dual-dimensional classification + association integration + structured encapsulation", which differs from the traditional solution's "single-dimensional classification, no association integration" design. This allows the categorized anomaly feature set to possess both "clear anomaly types and explicit task unit identifiers" and reflect the logical dependencies between anomalies, providing "accurate type and complete association" data support for the subsequent step 42, "anomaly-rule clause matching".

[0062] Optionally, step 4 specifically includes step 42: based on the original rules in the structured SOP model, perform rule clause matching on the classified abnormal feature set to determine the process constraint clauses in the original rules corresponding to each abnormality, so as to generate an abnormal-rule association table.

[0063] Preferably, the specific implementation process of step 42 is as follows: Taking the classified anomaly feature set generated in step 41 (containing three subsets: FL-001 (node ​​processing time exceeds limit), FL-002 (rule verification failure), and FL-003 (data interaction interruption), each subset containing the fields of "unique anomaly identifier," "taskId," "business module identifier," and "anomaly details") and the original rules in the structured SOP model generated in step 1 as the joint processing objects, the preprocessing of the original rules of the structured SOP is first carried out—the original rules in the structured SOP model (including four categories: process node timeliness rules, inter-node logical constraint rules, automatic approval verification rules, and data interaction specification rules) are classified in two dimensions according to "business module + rule type," and a unique "rule identifier" (e.g., ...) is assigned to each type of rule. GZ-CG-SX-001 represents the timeliness rules for process nodes in the procurement business module, and GZ-CG-JY-002 represents the automatic approval verification rules for the procurement business module. At the same time, the "core constraint clauses" (such as "regular procurement review time ≤ 300 seconds" for the timeliness rule and "procurement amount must be a positive integer" for the automatic verification rule) and the "applicable task unit scope" (determined by associating the task unit "business function description" in step 21, such as GZ-CG-SX-001 being applicable to "procurement application review unit" and "procurement order confirmation unit") of each rule are extracted to generate a structured SOP rule table. This preprocessing process solves the matching difficulties caused by the "disorganized and unclear classification" of the original SOP rules in the traditional solution, and provides a structured rule foundation for subsequent accurate matching.

[0064] Preferably, in the specific technical implementation of step 42, based on the generated structured SOP rule table and the FL-001 subset (node ​​processing time exceeding the limit) of the classified abnormal feature set, the first type of abnormal-rule matching is carried out: First, the "business module identifier" (such as BM-CG) of each abnormal record in the FL-001 subset is associated with the "process node timeliness rule" (such as GZ-CG-SX-001) of the corresponding business module in the structured SOP rule table. Then, the "business function description" (such as "regular procurement application review") of the task unit associated with "taskId" is matched with the "applicable task unit scope" in the rule table to initially screen out the timeliness rules that may be applicable. Next, the "abnormal details" (such as "60 seconds over the limit, actual duration 360 seconds") in the FL-001 subset are extracted and compared with the "core constraint clause" (such as "≤300 seconds") of the initially screened rules to confirm that the abnormality is caused by violating the rule (such as 360 seconds > 300 seconds, violating GZ-CG-SX-001). The "rule identifier" and "core constraint clause" are recorded as the process constraint clause corresponding to the exception. If no matching rule is found in the initial screening, it is marked as "rule to be supplemented" and the exception details are recorded (e.g., "FL-001 subset Y003-JJ001 (emergency procurement review unit exceeds the limit) has no matching time limit rule"). All matching results are integrated to generate a temporary exception-rule association table specific to the FL-001 subset, with fields including "unique exception identifier", "taskId", "matching rule identifier", "core constraint clause", and "matching status". For example, "Y001-CG001 (T002, regular procurement review exceeds the limit) → matching rule GZ-CG-SX-001, core constraint clause 'regular procurement review time ≤ 300 seconds', matching status = success". This matching process is different from the traditional solution's design of "direct fuzzy matching without distinguishing rule types". Through three-level precise matching of "business module → task unit → exception details", the matching accuracy of time-sensitive exceptions and rule clauses is improved.

[0065] Preferably, in one scenario, when implementing step 42, based on the structured SOP rule table and the FL-002 subset (rule validation failure) of the categorized abnormal feature set, a second type of anomaly-rule matching is performed: First, the "business module identifier" of the abnormal record in the FL-002 subset is associated with the "approval automatic validation rule" (e.g., GZ-CG-JY-002) of the corresponding module in the structured SOP rule table. The "failure reason" (e.g., "purchase amount is text type") in the "abnormal details" is matched with the "validation content" (e.g., "purchase amount must be a positive integer") of the "core constraint clause" in the rule table to determine that the failure is due to a violation of the approval automatic validation rule. Then, the consistency check between the "applicable scenario constraint" (e.g., GZ-CG-JY-002 applies to "all purchase scenarios") of the rule and the "business scenario" (e.g., "regular purchase") of the abnormal record is performed. If they are consistent, the match is confirmed. Configure this rule; for example, “FL-002 subset Y004-CG002 (T005, rule validation failed, failure reason 'purchase amount is text type') → match rule GZ-CG-JY-002, core constraint clause 'purchase amount must be a positive integer', applicable scenario 'all purchase scenarios', matching status = successful”; at the same time, for “related abnormal information” in the FL-002 subset (such as related validation failure caused by the main abnormality), it is necessary to synchronously match the rule corresponding to the main abnormality (such as the main abnormality matching GZ-CG-SX-001, the related abnormality needs to be marked with “related main rule GZ-CG-SX-001”) to generate a temporary table of abnormality-rule association specific to the FL-002 subset; this matching process solves the problem of “not knowing which SOP rule is violated” in the traditional solution for validation failure anomalies through the direct association of “failure reason-validation content”, and improves the targeting of the matching.

[0066] Preferably, in the specific implementation of step 42, based on the structured SOP rule table and the FL-003 subset (data interaction interruption) of the classified abnormal feature set, a third type of abnormality-rule matching is performed: The "business module identifier" of the abnormal record in the FL-003 subset is associated with the "data interaction specification rule" of the corresponding module in the structured SOP rule table (e.g., GZ-CG-JH-003, representing the data interaction specification rule of the procurement business module). The "interruption location" in the "abnormal details" (e.g., "transmission interrupted in the 'supplier number' field of the purchase requisition form") is matched with the "data interaction requirements" of the "core constraint clauses" in the rule table (e.g., "the supplier number field must be completely transmitted to the inventory system") to confirm that the interruption violates the interaction rule; simultaneously, the abnormal record is associated with... The "data input / output item identifier" (e.g., F001) recorded in the table and the "applicable data field range" (e.g., including F001) in the rule table are used to further verify the accuracy of the match. For example, "FL-003 subset Y006-CG003 (T007, data interaction interrupted, interruption position F001) → matching rule GZ-CG-JH-003, core constraint clause 'supplier number field must be transmitted completely', applicable data field range = F001, matching status = success" is generated. A temporary table for exception-rule association is generated specifically for the FL-003 subset. This matching process is aimed at the precise association between the "interruption position" of data interaction exceptions and the "data requirements" of the rules. This is different from the traditional solution that only matches "interaction failure" without locating the specific violation clause, thus improving the precision of the match.

[0067] Preferably, in the specific technical implementation of step 42, the generated temporary tables for exception-rule association specific to the three subsets FL-001, FL-002, and FL-003 are used as the processing objects to carry out the integration and generation of exception-rule association tables: First, the field format of all temporary tables is unified, including "unique identifier of exception", "exception type" (strict reuse node processing time limit exceeded, rule verification failure, data interaction interruption), "taskId", "business module identifier", "matching rule identifier", "core constraint clause (process constraint clause)", "matching status", and "associated exception rule identifier (fill in 'none' if none)"; then, the consistency of associated exception matching between different temporary tables is checked (e.g., if an exception in subset FL-002 is an associated exception of the main exception in subset FL-001, it is necessary to ensure that the "associated exception rule identifier" is consistent with the "matching rule identifier" of the main exception); finally, the record of "matching status = rule to be supplemented" is processed. Summarize and annotate (e.g., "2 rules to be supplemented, involving urgent procurement timeliness") to form a complete anomaly-rule association table; for example, a complete record in this table is: "Unique anomaly identifier Y001-CG001, anomaly type = node processing time exceeded limit, taskId=T002, business module identifier = BM-CG, matching rule identifier = GZ-CG-SX-001, core constraint clause = regular procurement review time ≤ 300 seconds, matching status = successful, associated anomaly rule identifier = GZ-CG-JY-002 (associated with Y002-CG001)"; the generation of this association table achieves precise binding between anomalies and original SOP rules through the logic of "type matching - unified integration - consistency verification", which is different from the defect of "no clear association between anomalies and rules" in traditional solutions, and provides key information of "abnormal violation basis" for the subsequent step 43 matching adjustment strategy.

[0068] Optionally, step 4 specifically includes step 43: based on the preset adjustment rule base, perform adjustment strategy matching on the exception-rule association table, so as to match the corresponding trigger condition adjustment method or verification logic modification scheme from the adjustment rule base according to the exception type and the associated original rule clause, so as to generate an exception adjustment scheme set.

[0069] Preferably, the specific implementation process of step 43 is as follows: Taking the anomaly-rule association table generated in step 42 (containing fields such as "unique anomaly identifier", "anomaly type", "matching rule identifier", "core constraint clause", and "taskId", such as "Y001-CG001, node processing time exceeds limit, GZ-CG-SX-001, regular procurement review time ≤ 300 seconds, T002") and the preset adjustment rule library (storing adjustment strategies for different anomaly types and different SOP rule clauses, such as "time limit exceeds limit → dynamic threshold adjustment" and "verification failure → logic optimization") as the joint processing objects, firstly, perform structured preprocessing of the preset adjustment rule library—classify it in two dimensions according to "anomaly type + applicable rule clause type", assign a unique "adjustment strategy identifier" to each adjustment strategy (such as TZ-SX-001 representing the adjustment strategy for time-related rules, and TZ-JY-002 representing the adjustment strategy for verification rules), and at the same time clarify the "core adjustment method" of each strategy. The system generates a structured adjustment rule table by defining the following parameters: "Formula" (e.g., "Dynamically adjust preset duration threshold" and "Add data format pre-verification step"), "Applicable anomaly degree" (e.g., "Mild over-limit: Over-limit duration ≤ preset ratio D, Moderate over-limit: Preset ratio D < Over-limit duration ≤ 2D, D is the ratio value set by the enterprise, such as 20%), "Associated adjustment object type" (e.g., "Trigger condition parameter" and "Verification logic algorithm"), and "Post-adjustment verification requirements" (e.g., "Requires 3 consecutive normal operation tests after adjustment"). This preprocessing process solves the matching chaos problem caused by the "dispersed strategies and no clear scope of application" in the adjustment rule base of traditional solutions, and provides a standardized strategy foundation for subsequent accurate matching. For example, in the manufacturing procurement scenario, "TZ-SX-001 strategy: Applicable anomaly type = node processing duration over-limit, Applicable rule clause = time-sensitive, Core adjustment method = dynamically adjust preset duration threshold, mild over-limit applicable (D=20%), Associated adjustment object type = time-sensitive parameter in the trigger condition".

[0070] Preferably, in the specific technical implementation of step 43, based on the generated structured adjustment rule table and the exception-rule association table, the first type of adjustment strategy matching is carried out: First, through the "exception type" and "matching rule identifier" (such as GZ-CG-SX-001, time-sensitive rule) in the exception-rule association table, the adjustment strategies (such as TZ-SX-001, TZ-SX-003) in the structured adjustment rule table with "applicable exception type = node processing time exceeding limit" and "applicable rule clause type = time-sensitive" are associated. Then, the "exceedance duration" of the "exception details" in the exception-rule association table is extracted (such as the excess duration of Y001-CG001 = 60 seconds, the original preset threshold = 300 seconds), the excess ratio is calculated (exceedance duration / original preset threshold = 20%), and the corresponding "applicable exception degree" in the structured adjustment rule table is matched (such as TZ-SX-001 is applicable to mild excess ≤20%, TZ-SX-00...). 3. Applicable to moderate over-limit > 20%); if the over-limit ratio = 20%, then match the TZ-SX-001 strategy, whose core adjustment method is "dynamically adjust the preset duration threshold to the original threshold × (1 + over-limit ratio)" (e.g., 300 seconds × 1.2 = 360 seconds), and the associated adjustment object type is "the preset duration threshold parameter in the trigger condition of the task unit" (corresponding to the timeliness parameter in the trigger condition of the task unit generated in step 22). The verification requirement after adjustment is "continuously test the procurement application review process 3 times to ensure that the processing time ≤ 360 seconds"; associate the matching result with the "taskId" (T002) and "unique identifier of anomaly" (Y001-CG001) of the anomaly record to generate a temporary table of adjustment strategies for node processing time over-limit anomalies; this matching process is different from the traditional solution's design of "uniform adjustment without distinguishing the degree of anomaly". Through the precise association of "over-limit ratio - anomaly degree - strategy", the adjustment strategy has a better degree of refinement and avoids the waste of resources caused by excessive adjustment for mild over-limits.

[0071] Preferably, in a scenario, when step 43 is specifically implemented, based on the "rule validation failure" exception records (exception type = rule validation failure) in the structured adjustment rule table and the exception-rule association table, a second type of adjustment strategy matching is carried out: First, by using the "exception type" and "matching rule identifier" (e.g., GZ-CG-JY-002, validation rule) in the exception-rule association table, the adjustment strategies (e.g., TZ-JY-002, TZ-JY-004) in the structured adjustment rule table that have "applicable exception type = rule validation failure" and "applicable rule clause type = validation" are associated; then, the "failure reason" of the "exception details" in the exception-rule association table is extracted (e.g., the failure reason of Y004-CG002 = "purchase amount is text type"), and the strategy (e.g., TZ-JY-002, core adjustment method = "add data format pre-correction before task unit execution") in the structured adjustment rule table that has "applicable failure reason = data format error" is matched. The verification process automatically identifies non-numerical data and prompts for correction. Simultaneously, it confirms that the "Associated Adjustment Object Type = Verification Logic Algorithm" of the strategy (corresponding to the data verification algorithm in the automatic verification rules generated in step 23). The adjusted verification requirement is: "Test 5 purchase applications containing text-based amounts; all must trigger pre-verification prompts and fail to enter the verification stage." If the failure reason is "Insufficient permissions" (e.g., operation by a non-designated position), then the TZ-JY-004 strategy is matched, with the core adjustment method being "Optimize permission verification logic and automatically push to the superior authorized position." The matching result is associated with the "taskId" (T005) and "unique anomaly identifier" (Y004-CG002) of the exception record to generate a temporary table of adjustment strategies for rule verification failure anomalies. This matching process, through the direct association of "failure reason - strategy," solves the problem of "lack of specificity and reliance on manual trial and error" in traditional solutions for verification failure adjustments, improving adjustment efficiency and accuracy.

[0072] Preferably, in the specific implementation of step 43, based on the "data interaction interruption" type exception records (exception type = data interaction interruption) in the structured adjustment rule table and the exception-rule association table, a third type of adjustment strategy matching is carried out: First, through the "exception type" and "matching rule identifier" (such as GZ-CG-JH-003, interaction rule) in the exception-rule association table, the adjustment strategies (such as TZ-JH-001, TZ-JH-005) in the structured adjustment rule table with "applicable exception type = data interaction interruption" and "applicable rule clause type = interaction type" are associated; then, the "interruption type" of the "exception details" in the exception-rule association table is extracted (such as the interruption type of Y006-CG003 = "field transmission interruption", interruption position = F001 supplier number field), and matched with the strategy in the structured adjustment rule table with "applicable interruption type = field-level interruption" (such as TZ-JH-001, core adjustment method = "add to data interaction interface"). The system performs field integrity verification logic and automatically retryes transmission when a field is missing. If the interruption type is "system not responding" (e.g., inventory system not responding), then the TZ-JH-005 strategy is matched, and the core adjustment method is "configure a backup interaction interface, and automatically switch to the backup interface when the main interface does not respond". At the same time, the "associated adjustment object type" of the strategy is confirmed (e.g., TZ-JH-001 corresponds to "verification logic of data interaction interface", and TZ-JH-005 corresponds to "interface selection parameters in trigger conditions"). The verification requirement after adjustment is "test 3 field transmission interruption scenarios, and all of them must be able to automatically retry successfully". The matching result is associated with the "taskId" (T007) and "unique identifier of exception" (Y006-CG003) of the exception record to generate a temporary table of adjustment strategies for data interaction interruption exceptions. This matching process designs differentiated strategies for different interruption types, which is different from the single strategy of "unified retry" in traditional solutions, and improves the success rate of interaction exception adjustment.

[0073] Preferably, in the specific technical implementation of step 43, the generated temporary tables for three types of adjustment strategies—node processing time exceeding the limit, rule verification failure, and data interaction interruption—are used as processing objects to integrate and generate an abnormal adjustment scheme set. First, the field format of all temporary tables is unified, including "abnormal adjustment scheme identifier" (composed of "unique abnormal identifier + adjustment strategy identifier," such as Y001-CG001-TZ-SX-001), "associative unique abnormal identifier" (such as Y001-CG001), "abnormal type" (strictly reused node processing time exceeding the limit, rule verification failure, data interaction interruption), "matching adjustment strategy identifier" (such as TZ-SX-001), and "core adjustment..." The following parameters are defined: "Method" (e.g., "Dynamically adjust the preset duration threshold in the trigger condition of task unit T002 to 360 seconds"), "Associated task unit identifier" (e.g., T002, corresponding to the system-recognizable task unit in step 21), "Associated adjustment object type and parameters" (e.g., "Trigger condition parameters: preset duration threshold, original parameter value 300 seconds, new parameter value 360 ​​seconds"), "Verification requirements after adjustment" (e.g., "Continuous testing for 3 times to ensure normal operation"), and "Instructions for handling associated anomalies" (e.g., "If associated anomaly Y002-CG001 exists, its adjusted status must be verified synchronously"). Next, the consistency of strategies for associated anomalies between different temporary tables is checked (e.g., adjustment trigger of main anomaly Y001-CG001). Conditional parameters and adjustment strategies for associated anomalies Y002-CG001 must be adapted to these parameter changes to avoid logical conflicts. Finally, according to the structure of "anomaly type grouping and scheme identifier sorting," all scheme records are integrated into structured data (such as JSON format, with "abnormalAdjustmentPlans" as the root node and sub-nodes "timeOutPlans," "checkFailPlans," and "interruptPlans") to generate an anomaly adjustment scheme set. For example, in a manufacturing procurement scenario, a complete scheme record would be: "Anomaly Adjustment Scheme Identifier = Y001-CG001-TZ-SX-001" The following parameters are defined: 1. **Unique identifier for associated anomalies:** Y001-CG001; 2. **Anomaly type:** Node processing time exceeded limit; 3. **Matching adjustment strategy identifier:** TZ-SX-001; 4. **Core adjustment method:** Dynamically adjust the preset time threshold in the trigger condition of T002 (procurement application review unit) to 360 seconds; 5. **Associated task unit identifier:** T002; 6. **Associated adjustment object type and parameters:** Trigger condition parameters - preset time threshold (original 300 seconds → new 360 seconds); 7. **Verification requirements after adjustment:** Test the procurement application review process three times consecutively, with processing time ≤ 360 seconds for each time; 8. **Associated anomaly handling instructions:** Associated anomaly Y002-CG001 (T003 rule verification failed) needs to be tested synchronously to ensure no chain anomalies.The generation of this solution set is based on the technical logic of "precise matching by type - integration of multi-dimensional information - collaborative verification of related anomalies". It is different from the traditional solution design of "fragmented adjustment strategy and no verification requirements". It clarifies "what to adjust, how to adjust, and how to verify after adjustment" and solves the problem of collaborative handling of related anomalies.

[0074] Optionally, step 4 specifically includes step 44: updating the parameters of the initial process orchestration model based on the set of exception adjustment schemes, modifying the triggering conditions or verification logic of the corresponding task units according to the adjustment methods in the set of exception adjustment schemes, and integrating all updated task units, triggering conditions and verification logic to generate a dynamically adjusted process orchestration model.

[0075] Preferably, the specific implementation process of step 44 is as follows: Taking the abnormal adjustment scheme set generated in step 43 (including fields such as "abnormal adjustment scheme identifier", "associated task unit identifier", "core adjustment method", "associated adjustment object type and parameters", and "post-adjustment verification requirements", such as "Y001-CG001-TZ-SX-001, T002, dynamically adjust the preset duration threshold to 360 seconds, trigger condition parameters (original 300 seconds → new 360 seconds), and three consecutive tests for normal operation") and the initial process orchestration model generated in step 2 (including system-recognizable task units, trigger conditions of task units, and verification logic of task units) as the joint processing objects, the pre-adjustment preprocessing is first carried out—loading the structured data of the initial process orchestration model (stored according to the "task unit-trigger condition-verification logic" associated structure, such as "task", "triggerCondition", "validationLocal" in XML format) The system uses the "gic" tag to parse all "associated task unit identifiers" (such as T002, T005) and "associated adjustment object types" (such as trigger condition parameters, verification logic algorithms) in the abnormal adjustment scheme set, and establishes a mapping index of "adjustment scheme - initial model element". Then, it checks for adjustment conflicts within the abnormal adjustment scheme set: if there are two schemes that both target the "preset duration threshold in the trigger condition of task unit T002" (such as scheme A adjusting to 360 seconds, scheme B adjusting to 380 seconds), then the abnormal-rule association table in step 42 is associated through the "associated rule identifier", and a unique adjustment value is determined according to the original rule priority in the structured SOP model (such as "emergency scenario timeliness rule priority is higher than regular scenario"), generating an abnormal adjustment scheme set after conflict handling. This preprocessing process solves the problem of logical contradictions after adjustment caused by "direct update without conflict checking" in traditional schemes, and provides a conflict-free scheme basis for subsequent accurate updates.

[0076] Preferably, in the specific technical implementation of step 44, based on the generated set of abnormal adjustment schemes after conflict handling and the initial process orchestration model, the first type of parameter update is carried out: For the scheme "Associated adjustment object type = trigger condition parameter" (such as Y001-CG001-TZ-SX-001), firstly, the corresponding system-identifiable task unit (T002, procurement application review unit) in the initial process orchestration model is located through the "Associated task unit identifier" (T002); then, the trigger condition of the task unit associated with this task unit is extracted (from the trigger condition generated in step 22, such as "preceding task completed and processing time ≤ 300 seconds"). According to the "Associated adjustment object type and parameter" in the scheme (trigger condition parameter: original 300 seconds → new 360 seconds), the parameter field corresponding to the "processing time threshold" in the trigger condition (such as "timeThreshold") is found, and its value is replaced from 300 seconds to 360 seconds. At the same time, the description of the trigger condition is updated. The text describes the process (e.g., "Prerequisite task completed and processing time ≤ 360 seconds"); for adjustments to trigger conditions with associated anomalies (e.g., the trigger condition of task unit T003 depends on the completion status of T002), it is necessary to simultaneously check whether the trigger condition parameters of T003 need to be adjusted accordingly (e.g., after the duration threshold of T002 is extended, the trigger waiting time of T003 is extended synchronously) to avoid upstream and downstream dependency conflicts; all task units whose trigger conditions have been adjusted are marked as "trigger conditions updated", and an updated set of trigger conditions is generated; for example, in a manufacturing procurement scenario, "the trigger condition 'timeThreshold' parameter of task unit T002 is updated from 300 seconds to 360 seconds, and the trigger waiting time of task unit T003 is synchronously updated from the original 300 seconds to 360 seconds"; this update process differs from the coarse approach of "global parameter replacement" in traditional solutions, and ensures the targeting and logical coherence of trigger condition adjustments through "precise task unit positioning + upstream and downstream dependency adaptation".

[0077] Preferably, in a scenario, when step 44 is specifically implemented, based on the set of abnormal adjustment schemes after conflict handling and the initial process orchestration model, a second type of parameter update is carried out: For the scheme of "associated adjustment object type = verification logic algorithm" (such as Y004-CG002-TZ-JY-002, adjusting the verification logic of task unit T005, adding a data format pre-verification step), firstly, the verification logic of the corresponding task unit in the initial process orchestration model is located through the "associated task unit identifier" (T005, budget verification unit) (from the automatic verification rules generated in step 23, such as "purchase amount value verification → permission verification → condition verification"); according to the "core adjustment method" in the scheme (adding a data format pre-verification step, automatically identifying non-numerical data and prompting correction), a "data format pre-verification algorithm" (such as a text data recognition algorithm, matching numerical format through regular expressions, and outputting "please enter a valid value" for non-numerical data) is inserted into the first step of the original verification logic. The system will update the execution order description of the verification logic (e.g., "data format pre-verification → purchase amount value verification → permission verification → condition verification"). If the adjustment involves modifying the verification logic parameters (e.g., expanding the job scope in permission verification), the corresponding parameter field (e.g., "authorizedPostList") will be found and replaced with the new parameter value specified in the solution (e.g., expanding from "department manager position" to "department manager position + deputy manager position"). All task units with completed verification logic adjustments will be marked as "verification logic updated", and an updated set of verification logic will be generated. For example, "After inserting the data format pre-verification step into the verification logic of task unit T005, the system will automatically trigger a prompt when the text-type amount '50,000' is input, and the subsequent verification steps will not be entered." This update process, through the refined operation of "algorithm insertion + parameter replacement", differs from the high-cost method of "overall rewriting of verification logic" in traditional solutions, improving the efficiency and maintainability of verification logic adjustments.

[0078] Preferably, in the specific implementation of step 44, the updated trigger condition set and the updated verification logic set are used as processing objects to carry out adjusted local verification: For each task unit marked as "trigger condition updated" or "verification logic updated" (such as T002, T005), the "adjusted verification requirements" corresponding to the abnormal adjustment scheme set are extracted (such as T002 needs to test the purchase application review process 3 times consecutively, and T005 needs to test 5 applications containing text-type amounts); the running environment of the initial process orchestration model is simulated (loading the same business scenario data, such as regular purchase application forms and emergency purchase application forms), and these task units and their direct upstream and downstream task units (such as the pre-task T001 and post-task T003 of T002) are executed separately to verify whether the adjusted trigger conditions can trigger the task execution normally. The process involves checking whether the adjusted verification logic can identify anomalies as expected (e.g., when T002 processes for 350 seconds, the trigger condition is considered normal), and whether the pre-verification prompts that the anomaly is normal when a text-type amount is entered in T005. If the verification fails (e.g., T002 is still judged as exceeding the limit after adjustment, 350 seconds is still considered excessive), then the "associated adjustment object type and parameters" of the anomaly adjustment scheme set are traced back to check whether the parameter replacement is incorrect (e.g., 300 seconds is mistakenly entered as 360 seconds). After correction, the verification is repeated until the "post-adjustment verification requirements" are met, and a set of updated elements that have passed the verification (including the verified task unit, trigger condition, and verification logic) is generated. This local verification process is different from the high-risk approach of "direct overall operation after adjustment" in traditional schemes. By "small-scale simulation verification", adjustment defects are identified in advance, reducing the probability of anomalies in the overall operation of the initial process orchestration model.

[0079] Preferably, in the specific technical implementation of step 44, the generated set of updated elements that have passed verification and the unadjusted elements in the initial process orchestration model (task units, trigger conditions, and verification logic not covered by the abnormal adjustment scheme set) are used as joint processing objects to carry out the integration and generation of the dynamically adjusted model: First, the unadjusted elements in the initial process orchestration model (such as task units T001, T004, etc. and their associated trigger conditions and verification logic) are retained to ensure that the process parts that do not involve abnormalities maintain their original logic; then, the set of updated elements that have passed verification is spliced ​​and integrated with the unadjusted elements according to the original association structure of "task unit-trigger condition-verification logic" (the association consistency is ensured by the "taskId" field, such as the updated trigger condition of T002 being rebound with the original verification logic); then, the integrity of the integrated model logic is checked (such as all task units have corresponding trigger conditions and verification logic, and the dependency relationship between upstream and downstream tasks is not broken), and model meta-information is supplemented (such as adjustment time, list of abnormal adjustment scheme identifiers involved, etc.). (Verification passed record); Finally, it is encapsulated according to the structured format (such as JSON format) of the initial process orchestration model to generate the dynamically adjusted process orchestration model; for example, in this model, "task unit T002 is associated with the updated trigger condition (timeThreshold=360 seconds) and the original verification logic, task unit T005 is associated with the original trigger condition and the updated verification logic (including data format pre-verification), and the remaining task units remain in the initial state"; This integration process ensures the model logic is closed-loop through "structured splicing of updated elements + unadjusted elements", which is different from the incomplete model problem caused by "only retaining the updated part" in the traditional solution; Its technical innovation lies in: through the full-link design of "conflict pre-check - precise update by object - local verification - structured integration", it not only solves the defects of "many logical conflicts, high verification cost, and easy model incompleteness" in the traditional adjustment, but also ensures that the dynamically adjusted process orchestration model can fit the original rules of the structured SOP model, laying a better foundation for the consistency verification in the subsequent step 5.

[0080] Optionally, step 5 specifically involves: performing a consistency check between the dynamically adjusted process orchestration model and the structured SOP model to verify whether the adjusted task units, triggering conditions, and verification logic meet the requirements of the original SOP elements, so as to generate an executable process model that conforms to the enterprise SOP.

[0081] Optionally, step 5 specifically includes step 51, extracting task units, triggering conditions, and verification logic from the dynamically adjusted process orchestration model, as well as process nodes, logical relationships between nodes, and approval rules from the structured SOP model, to generate a set of elements to be verified so as to perform consistency verification between the dynamically adjusted process orchestration model and the structured SOP model.

[0082] Preferably, the specific implementation process of step 51 is as follows: Taking the dynamically adjusted process orchestration model generated in step 44 (including the updated system-recognizable task units, the updated trigger conditions of the task units, and the updated verification logic of the task units, such as "T002 Purchase Application Review Unit (trigger condition threshold 360 seconds) and T005 Budget Verification Unit (including data format pre-verification)" in the manufacturing procurement process) and the structured SOP model generated in step 1 (including process nodes, logical relationships between nodes, approval rules, and data interaction requirements, such as "Purchase Application Review Node, the sequential logic of Purchase Application → Budget Verification, and automatic verification rules for purchase amount values") as the joint processing objects, firstly, perform element decomposition preprocessing of the dynamically adjusted model—load the structured storage data of the dynamically adjusted process orchestration model (adopting a "task unit as the core" association structure, such as "task" node nested under "tri" in JSON format) By parsing the model's metadata identifiers (such as "adjustedModelVersion" and "taskIdList"), the system locates all updated system-identifiable task units and their associated triggering conditions and validation logic. Then, each task unit is tagged with an "adjustment status label" (such as "parameter updated," "logic added," and "not adjusted," with T002 labeled "parameter updated," T005 labeled "logic added," and unadjusted task units labeled "not adjusted"), clearly distinguishing between the adjusted elements requiring key validation and the baseline elements that do not require adjustment, thus generating a list of element components for the dynamically adjusted model. This preprocessing solves the problem of ambiguous validation focus caused by "extracting elements without distinguishing adjustment status" in traditional solutions, laying the foundation for accurate extraction of elements to be validated.

[0083] Preferably, in the specific technical implementation of step 51, based on the generated list of element components of the dynamically adjusted model, the first part of element extraction is carried out: for the "system-identifiable task units" in the dynamically adjusted process orchestration model, their core feature information is extracted—including four categories of key information: "taskId" (such as T002, T005, consistent with the identifier generated in step 21), "operation subject" (such as the procurement department's review post, the finance department's budget post, from the task unit attributes updated in step 44), "business function description" (such as regular procurement application review, budget verification with format pre-validation, reflecting the functional changes after adjustment), and "data input / output item identifier" (such as the F001 procurement amount field, I001 inventory interface, consistent with those extracted in step 21), ensuring that each type of information can correspond to the process node features in the structured SOP model (such as the "node function" corresponding to the process node in the "business function description"); and marking the "adjustment status" Task units tagged with "Parameter Update / Logic Addition" (such as T002, T005) are supplemented with an "Adjustment Summary" field (e.g., T002 is labeled "Trigger condition duration threshold changed from 300 seconds to 360 seconds", T005 is labeled "Added data format pre-validation step") to record the core differences before and after the adjustment. All extracted task unit information is sorted by "taskId" to generate a subset of adjusted task unit elements; for example, "Task unit T002: taskId=T002, Operation subject=Purchasing department review post, Business function description=Regular purchase application review, Data input / output item identifier=F001, Adjustment status tag=Parameter Update, Adjustment summary=Trigger condition duration threshold 300 seconds → 360 seconds"; This extraction process differs from the crude approach of "only extracting task unit identifiers" in traditional solutions. By supplementing the operation subject, function description, and adjustment summary, it provides multi-dimensional basis for subsequent matching verification with process nodes.

[0084] Preferably, in the specific technical implementation of step 51, based on the element component list of the dynamically adjusted model, the second and third parts of element extraction are carried out: For the "trigger conditions of the updated task units", the core information corresponding to the "logic relationship between nodes" of the structured SOP model is extracted - including "triggerId" (unique identifier of the trigger condition, such as TC-T002), "associated taskId" (such as T002, corresponding to the task unit), "trigger type" (such as sequential triggering, branch triggering, consistent with the trigger condition type in step 22), "core parameters" (such as duration threshold of 360 seconds, preceding task identifier T001, reflecting the adjusted parameter value), "trigger logic description" (such as "T001 is completed and processing time ≤ 360 seconds then triggers T002"), generating an adjusted trigger condition element subset; For the "verification logic of the updated task units", the core information corresponding to the "approval rules" of the structured SOP model is extracted - including "value". The system generates an adjusted subset of validation logic elements, including: "applicationId" (unique identifier for validation logic, such as VL-T005), "associated taskId" (such as T005), "validation type" (such as data validation, permission validation, consistent with the validation type in step 23), "automatic validation rule content" (such as "purchase amount must be numerical (new pre-validation), permission post is financial budget post"), and "validation failure handling logic" (such as "if format is incorrect, prompt for correction"). For example, "TC-T002 trigger condition: triggerId=TC-T002, associated taskId=T002, trigger type=sequential triggering, core parameter=duration threshold 360 seconds, trigger logic description=T001 completes and processing time ≤ 360 seconds triggers T002". This extraction process avoids the problem of subsequent validation lacking a basis due to the disconnect between element extraction and the original SOP rules in traditional solutions by precisely matching "trigger condition-node logic" and "validation logic-approval rule".

[0085] Preferably, in a scenario, when step 51 is specifically implemented, the structured SOP model generated in step 1 is used as the processing object, and the original SOP element extraction is carried out: the stored data of the structured SOP model is loaded (adopting a relational structure with "process nodes as the core", such as "logicRelation" and "approvalRule" child nodes nested under the "processNode" node in XML format), and the three types of original information corresponding to the adjusted model elements are extracted—for "process nodes", "nodeId" (such as N002, which is consistent with the original node identifier of task unit T002), "node operation subject" (such as the procurement department review position, the execution role specified in the SOP), "node function description" (such as regular procurement application review, the core responsibility defined in the SOP), and "node data interaction requirements" (such as needing to obtain the F001 field of the procurement application form, the input and output specified in the SOP) are extracted, and the original SOP process node subset is generated; for "logical relationship between nodes", "logicId" (such as L002) and "related nodeId" (such as N002→N005) are extracted. This involves extracting the following elements: "node dependency corresponding to T002→T005", "logical type" (e.g., sequence, branch, consistent with the adjusted trigger type), and "logical constraints" (e.g., "N005 is triggered after N002 is completed, N002 processing time ≤ 300 seconds", the time constraint specified in the SOP), generating the original SOP logical relationship subset; for "approval rules", extracting "ruleId" (e.g., R005), "associated nodeId" (e.g., N005), "rule type" (e.g., data validation, permission validation, consistent with the adjusted validation type), and "rule..." Then, the core content (such as "the purchase amount must be numerical, and the approval post is the financial budget post," as specified in the SOP) generates a subset of approval rules; for example, "original SOP process node N002: nodeId=N002, node operation subject=purchasing department review post, node function description=regular purchase application review, node data interaction requirement=get field F001"; this extraction process ensures that the original SOP elements and the adjusted model elements completely correspond in the dimensions of "type, identifier, and core content," providing a unified comparison benchmark for subsequent consistency verification.

[0086] Preferably, in the specific technical implementation of step 51, the structured integration of the set of elements to be verified is carried out using the generated adjusted task unit element subset, adjusted trigger condition element subset, adjusted verification logic element subset, and the original SOP process node subset, original SOP logical relationship subset, and approval rule subset as processing objects: First, a "dual-source" association mapping is established—through unified identifiers (such as "taskId=T002" corresponding to "nodeId=N002", "triggerId=TC-T002" corresponding to "logicId=L002", and "validationId=VL-T005" corresponding to "ruleId=R005"), the three types of subsets of the adjusted model are bound one by one with the three types of subsets of the original SOP, forming paired association items of "adjusted element-original element"; then, "verification dimension labels" are added to each association item (such as "operation subject consistency, functional description matching degree, and data interaction item conformity" for task unit association items). Trigger condition related items are labeled with "logical type consistency, constraint parameter matching degree", and verification logic related items are labeled with "rule type consistency, rule content compliance" to clarify the specific dimensions to be checked in subsequent step 52; finally, according to the structure of "related items as units", all related items and their corresponding subset information are integrated into a standardized data format (such as an Excel spreadsheet or JSON array, containing fields such as "related item identifier", "adjusted element information", "original element information", and "verification dimension") to generate a set of elements to be verified; for example, a complete related item record in the set of elements to be verified is: "related item identifier = T002-N002, Adjusted Element Information = [T002 Task Unit: Operation Entity Procurement Department Review Position, Function Description Regular Procurement Application Review, Adjusted Data Interaction Item F001], Original Element Information = [N002 Process Node: Operation Entity Procurement Department Review Position, Function Description Regular Procurement Application Review, Original Data Interaction Item F001], Verification Dimension Labels = Operation Entity Consistency, Function Description Matching Degree, Data Interaction Item Compliance”; This integration process differs from the traditional design of “dispersed storage of adjusted elements and original elements”. Through unified identifier binding and verification dimension preset, it ensures that the set of elements to be verified has the characteristics of “precise correspondence and clear dimensions”, providing structured support for efficient comparison in step 52.

[0087] Optionally, step 5 specifically includes step 52: based on the set of elements to be verified, perform element correspondence comparison, check the matching degree between task units and process nodes, verify the compliance of triggering conditions and logical relationships between nodes, and compare the consistency of verification logic with approval rules to generate a verification result set and generate an executable process model that conforms to the enterprise SOP.

[0088] Preferably, the specific implementation process of step 52 is as follows: Taking the set of elements to be verified generated in step 51 (containing three types of related items: "adjusted task unit - original process node", "adjusted trigger condition - original logical relationship", and "adjusted verification logic - original approval rule", each type of related item contains the fields "adjusted element information", "original element information" and "verification dimension label") as the core processing object, the first type of comparison is carried out first - the matching degree verification of task units and process nodes. The processing object is the related items of "adjusted task unit element subset" and "original SOP process node subset" in the set of elements to be verified (such as the related item identifier T002-N002, corresponding to task unit T002 and process node N002), and the verification is carried out step by step according to the three dimensions of "operation subject consistency, functional description matching degree, and data interaction item conformity" in "verification dimension label": the first step is operation subject comparison - extract the "operation subject" of the adjusted task unit (such as the procurement department review post) and the "node operation subject" of the original process node (such as the procurement department review post), and judge the document If the descriptions are completely consistent, mark them as "Consistent Operational Entities". If there are differences in job title abbreviations (e.g., "Purchase Review Position" and "Purchase Department Review Position"), verify whether they are the same position through the enterprise organizational structure database. If the verification passes, mark them as "Basically Consistent Operational Entities"; otherwise, mark them as "Inconsistent Operational Entities". The second step is to check the matching degree of the business function descriptions. A keyword extraction algorithm (e.g., TF-IDF) is used to extract the core keywords of the adjusted task unit "business function description" (e.g., "Budget Verification with Data Format Pre-verification") and the original process node "node function description" (e.g., "Budget Verification" is a common core term, and "Data Format Pre-verification" is a newly added keyword after adjustment). If the adjusted description contains all the core keywords of the original description and there are no conflicting expressions (e.g., no reverse keywords such as "Cancel Budget Verification"), mark it as "High Matching Degree of Functional Description". If some non-core keywords are missing (e.g., the original contained "Monthly Budget Verification", but the adjusted version does not mention "Monthly" but is still executed monthly), mark it as "Medium Matching Degree of Functional Description". If core keywords are missing, mark it as "Low Matching Degree of Functional Description". The third step is to check the data interaction items. Compliance Check – Compare the adjusted task unit's "Data Input / Output Item Identifier" (e.g., F001 Purchase Amount, I001 Inventory Interface) with the identifier list in the original process node's "Node Data Interaction Requirements". If they are completely consistent, mark "Data Interaction Item Fully Compliant". If the newly added input item after adjustment (e.g., the "Data Format Identifier" field F009 needs to be read for pre-validation) is a derived field of the original requirement (not a newly added independent field), mark "Data Interaction Item Basically Compliant". If the core identifier of the original requirement is missing (e.g., F001 Purchase Amount is not included), mark "Data Interaction Item Does Not Compliant".The verification results from the three dimensions are integrated and processed according to the following rules: "Consistent operating entity + high matching degree of functional description + complete compliance of data interaction items = high matching degree," "Basic compliance of any dimension and no non-compliance items = medium matching degree," and "Existence of any non-compliance item = low matching degree." This generates a task unit-process node matching degree result table. For example, in a manufacturing procurement scenario, "Related items T005-N005 (T005 task unit includes pre-verification, N005 process node is budget verification): Consistent operating entity (financial budgeting position), high matching degree of functional description (including the core term 'budget verification'), basic compliance of data interaction items (newly added F009 as a derived field) → medium matching degree overall." This verification process differs from the traditional approach of "only comparing name identifiers." Through multi-dimensional layered verification and database-assisted validation, it ensures that the matching degree results have superior accuracy and traceability.

[0089] Preferably, in the specific technical implementation of step 52, based on the set of elements to be verified, a second type of comparison is carried out—the conformity verification of the logical relationship between triggering conditions and nodes. The processing object is the related items (such as the related item TC-T002-L002, corresponding to the triggering condition of TC-T002 and the logical relationship of L002) between the "adjusted triggering condition element subset" and the "original SOP logical relationship subset" in the set of elements to be verified. The verification is carried out according to three dimensions: "consistency of logical type, rationality of core parameters, and conformity of triggering logic". The first step is to verify the consistency of logical type—extract the "trigger type" (such as sequential triggering) of the adjusted triggering condition and the "logical type" (such as sequential relationship) of the original logical relationship. If the expression is completely consistent, it is marked as "consistent logical type". If there are differences in expression but the essence is the same (such as "branch triggering" and "conditional branch relationship"), it is marked as "consistent logical type". The consistency is verified through a logical relationship dictionary (the mapping relationship between preset trigger types and original logical types). If the consistency is achieved, it is marked as "logical types are basically consistent"; otherwise, it is marked as "logical types are inconsistent". The second step is to verify the rationality of core parameters—for the "core parameters" of the adjusted trigger conditions (such as a threshold of 360 seconds for regular procurement review time), the parameter range of the "logical constraints" in the original SOP logical relationship is correlated (such as the original SOP stipulating "regular procurement review time ≤ 300 seconds, which can be increased by ≤ 20% during peak business periods"). The deviation ratio between the adjusted parameters and the original baseline parameters is calculated ((360-300) / 300 = 20%). If the deviation is within the allowable range, it is marked as "core parameters are reasonable". If the parameters exceed the allowed range but have special business authorization (such as a temporary enterprise approval allowing a 30% increase during peak periods), mark them as "Core parameters are basically reasonable"; otherwise, mark them as "Core parameters are unreasonable". The third step is to verify the compliance of the triggering logic—compare the "triggering logic description" of the adjusted triggering conditions (e.g., "T001 completes and processing time ≤ 360 seconds triggers T002") with the "logic constraint description" of the original logical relationship (e.g., "After the preceding node is completed, the subsequent node is triggered, and the processing time does not exceed the baseline value by 20%). If the adjusted description fully conforms to the original logical framework (only parameter updates), mark it as "Triggering logic fully compliant". If a non-conflicting supplementary description is added (e.g., "Timeout requires re-application for triggering"), the following steps are taken: If the trigger logic is not fully met, it is marked as "Trigger logic basically meets the requirements". If it violates the original logic (e.g., "Trigger can be triggered if the prerequisite is not completed"), it is marked as "Trigger logic does not meet the requirements". The verification results of the three dimensions are integrated and generated into a trigger condition-logic relationship compliance result table according to the rules of "consistent logic type + reasonable core parameters + fully compliant trigger logic = compliance passed", "basically compliant in any dimension and no non-compliant items = compliance pending confirmation", and "existence of any non-compliant item = compliance failed". For example, "related item TC-T002-L002: consistent logic type (sequential order), reasonable core parameters (20% deviation within the allowable range), fully compliant trigger logic (prerequiring the prerequisite completion trigger framework) → compliance passed".This verification process, through a layered verification of "type-parameter-logic," overcomes the shortcomings of traditional solutions that "only check if the parameters are the same while ignoring the logical framework," ensuring that adjustments to trigger conditions do not deviate from the logical constraints of the original SOP.

[0090] Preferably, in a scenario, when step 52 is specifically implemented, a third type of comparison is performed based on the set of elements to be verified—a consistency comparison between verification logic and approval rules. The processing object is the related items (such as related item VL-T005-R005, corresponding to VL-T005 verification logic and R005 approval rule) between the "adjusted verification logic element subset" and the "approval rule subset" in the set of elements to be verified. The comparison is performed according to three dimensions: "verification type consistency, core rule compatibility, and failure handling compliance". The first step is verification type consistency comparison—extracting the "verification type" (such as data verification, permission verification) of the adjusted verification logic and the "rule type" (such as automatic data verification rule, permission approval rule) of the original approval rule. If they correspond one-to-one, they are marked as "verification type is completely consistent". If the newly added verification after adjustment is not consistent, the comparison is marked as "verification type is completely consistent". If the type (e.g., "data format pre-validation") belongs to a sub-type of the original type (e.g., the original "data validation" includes sub-types such as format and range), it is marked as "validation type is basically consistent". If a new type that conflicts with the original type is added (e.g., a new type is added when the original type does not have permission to validate), it is marked as "validation type is inconsistent". The second step is core rule compatibility comparison - analyzing the "automatic validation rule content" of the adjusted validation logic (e.g., "data format pre-validation → purchase amount value validation → permission validation") and the "rule core content" of the original approval rule (e.g., "purchase amount must be numerical, and the permission position is the financial budget position"). If the adjusted rule completely includes the original rule and there is no conflict, (If the pre-validation is to better meet the "numerical" requirement) then mark it as "Core Rule Fully Compatible". If the adjusted rule adds non-conflicting supplementary clauses (e.g., "Amounts exceeding 10,000 yuan require additional explanation") then mark it as "Core Rule Basically Compatible". If the adjusted rule violates the original rule (e.g., "Purchase amount can be text-based") then mark it as "Core Rule Incompatible". The third step is failure handling compliance comparison—comparing the "validation failure handling logic" of the adjusted validation logic (e.g., "Data format error prompt 'Please enter a valid value'") with the "abnormal handling requirements" of the original approval rule (e.g., "Data error requires prompt for correction direction"). If the handling logic is fully compatible... If the original requirements are met, the system is marked "Failure handling fully compliant". If the handling methods are different but the goals are the same (e.g., the original "prompt for correction", the adjusted "prompt for correction and provide an example"), the system is marked "Failure handling basically compliant". If the handling logic violates the original requirements (e.g., "data error is directly rejected without prompt"), the system is marked "Failure handling does not comply". The comparison results of the three dimensions are integrated and a consistency result table of verification logic and approval rules is generated according to the rules of "consistent verification type + fully compatible core rules + fully compliant failure handling = consistency passed", "basically compliant in any dimension and no non-compliance items = consistency pending confirmation", and "existence of any non-compliance item = consistency not passed".For example, "Related item VL-T005-R005: Verification type is basically consistent (new pre-verification is a subdivision of data verification), core rules are fully compatible (pre-verification meets numerical requirements), failure handling is fully compliant (correction prompt) → consistency passed"; this comparison process uses a full-chain check of "type-rule-processing" to avoid the problem of verification logic being disconnected from the original SOP caused by "only focusing on rule content and ignoring failure handling" in traditional solutions.

[0091] Preferably, in the specific technical implementation of step 52, the generated task unit-process node matching result table, trigger condition-logical relationship compliance result table, and verification logic-approval rule consistency result table are used as processing objects to integrate and generate the verification result set: First, a unique "verification result identifier" (such as JY-T002-N002) is assigned to each associated item in the set of elements to be verified, and the results of the associated item in the three types of comparisons (including the results of each dimension subdivision and the overall result) are associated accordingly; then, comprehensive automatic verification rules are set: if the results of the three types of comparisons are all "high matching degree / compliance passed / consistency passed", the comprehensive result is marked "passed"; if there are "medium matching degree / basic compliance / basic compatibility" and no "low matching degree / non-compliance / incompatibility", the comprehensive result is marked "pending confirmation" (requires manual review for special business scenarios); if there is any "low matching degree / non-compliance / incompatibility", the comprehensive result is marked "failed"; at the same time, a "result description" is added to each comprehensive result, listing in detail the specific judgment basis of each dimension (such as "original criteria to be confirmed"). Because: F009 has been added as a derived field to the data interaction item of task unit T005, it is necessary to confirm whether it conforms to the original SOP data specification); finally, sorted by "verification result identifier", it is encapsulated in a structured format (such as an Excel spreadsheet or JSON array) and includes fields such as "verification result identifier", "related item identifier", "task unit matching degree result", "trigger condition compliance result", "verification logic consistency result", "comprehensive verification result", and "result description" to generate a verification result set; for example, in the manufacturing procurement scenario, "verification result identifier JY-T002-N002, related item identifier T002-N002, task unit matching degree high matching degree, trigger condition compliance passed, verification logic consistency passed, comprehensive verification result passed, result description: all dimensions meet the requirements of the original SOP elements, no review is required"; this integration process, through "multi-dimensional result association + comprehensive rule judgment + detailed explanation", is different from the simple result of "only outputting pass / fail" in the traditional solution, ensuring that technical personnel can clearly locate the problem and trace the judgment basis.

[0092] Optionally, step 5 specifically includes step 53: based on the verification result set, perform executable code conversion and interface adaptation on the dynamically adjusted process orchestration model that has passed all comparison items, and integrate the converted code and the adapted interface to generate an executable process model that conforms to the enterprise SOP.

[0093] Preferably, the specific implementation process of step 53 is as follows: Taking the verification result set generated in step 52 (including the fields of "verification result identifier", "comprehensive verification result", and "related item identifier", such as "JY-T002-N002, comprehensive verification result = passed, related dynamic adjustment model identifier = ADJ-M001") and the dynamically adjusted process orchestration model generated in step 44 as joint processing objects, firstly, the screening and preprocessing of the passing models are carried out—extracting all records of "comprehensive verification result = passed" from the verification result set, and reverse-linking the complete structural data of the dynamically adjusted process orchestration model (including the updated task units, triggering conditions, verification logic and meta-information) through the "related item identifier", excluding model components of "comprehensive verification result = pending confirmation / failed" (e.g., a task unit needs to be readjusted due to failure of verification, and is not included in the conversion for the time being); then, the number of screened models is processed. The process involves standardizing the format: unifying the attribute naming of model components (e.g., "taskId" is unified as "task unit identifier", "triggerCondition" is unified as "trigger condition configuration"), and supplementing the technical metadata required for code conversion (e.g., the execution environment identifier of the task unit "Java / Python", the scheduling cycle unit of the trigger condition "seconds / minutes") to generate a standardized adjustment model to be converted. This preprocessing process solves the problem of code redundancy or runtime abnormalities caused by "direct conversion without screening unqualified components" in traditional solutions, providing a "compliant and standardized" model foundation for subsequent code conversion. For example, in the manufacturing procurement scenario, "only task units such as T002 and T003 with a comprehensive verification result of 'pass' are screened out, along with associated trigger conditions and verification logic, to generate a standardized adjustment model ADJ-M001-STD."

[0094] Preferably, in the specific technical implementation of step 53, based on the generated standardized adjustment model to be converted, the first stage—executable code conversion—is carried out, and the conversion is performed component by component in the order of "task unit → trigger condition → verification logic": First, the conversion of "updated task unit" is processed: the "business function description" (such as "regular purchase application review"), "data input and output item identifier" (such as F001 purchase amount, F002 supplier number), and "operation subject permission" (such as the purchase department review post can execute) of the task unit in the standardized adjustment model are extracted, and the corresponding template is matched according to the preset code template library (classified by business scenario and execution environment, such as Java task function template and Python data processing template for manufacturing purchase scenario); for example, "T002 purchase application review unit" is matched with Java service class template, and "data input items F001, F002" are converted into function parameters (String purchaseAmount, String supplierId), "business function description" is converted into function body core logic (such as calling the purchase application data query interface, executing the review status update), and "operation subject permission" is converted into function annotation (@Auth(role = (e.g., the Java class PurchaseApplyAuditService.java)); then, the "updated triggering conditions" are processed: extracting the "trigger type" (e.g., sequential triggering), "core parameters" (e.g., triggering T002 within 360 seconds after T001 completes), and "associated task unit identifier" (T001→T002), matching the triggering condition code template (e.g., Spring Cloud Stream message trigger template, Quartz timed scheduling template), converting the "core parameter 360 seconds" into a scheduling parameter (fixedDelay = 360000), converting the "trigger type" into message routing logic (e.g., sending a message to a topic after T001 completes execution, and T002 listening to that topic), and generating the code snippet corresponding to the triggering conditions (e.g., the trigger configuration class TriggerConfig).(java); Finally, process the "updated validation logic" transformation: extract the "validation type" (e.g., data format validation, permission validation), "automatic validation rule content" (e.g., "F001 Purchase amount must be numeric"), and "failure handling logic" (e.g., return "Amount format error" message), match the validation logic code template (e.g., Hibernate Validator annotation template, custom validation utility class template), for example, "T002 purchase amount numeric validation" is converted into parameter validation annotation (@DecimalMin(value = "0", message ="Purchase amount must be greater than 0")), and "newly added data format pre-validation" is converted into a custom utility class call (FormatCheckUtil.isNumeric(purchaseAmount, The code snippet corresponding to the validation logic (such as the validation utility class ValidationUtil.java and parameter annotations) is generated based on the "purchase amount". These three types of code snippets are then organized into a structure where "task unit code is the main class, trigger condition code is the configuration class, and validation logic code is the utility class", generating a preliminary executable code package (including .java / .py source files and configuration files). This conversion process differs from the inefficient "manual coding" approach of traditional solutions. Through automated conversion of "standardized model → template matching → parameter filling", it ensures consistency between the code and model functionality, significantly reduces code development costs, and allows the code snippets to be directly integrated into the enterprise's existing technical architecture (such as Spring Boot microservice architecture).

[0095] Preferably, in one scenario, when implementing step 53, based on the generated preliminary executable code package, the second stage—interface adaptation—is carried out to solve the interaction compatibility issues between the code and the enterprise's existing external systems (such as the procurement management system, inventory system, and organizational structure system): First, "data interface adaptation" is performed: extracting the external system interaction points involved in the preliminary executable code (such as the T002 task unit needing to query the inventory balance of the inventory system, and the T005 verification unit needing to call the permission interface of the organizational structure system), and obtaining the interface documents of the enterprise's existing external systems (such as the REST provided by the inventory system). The API interface is http: / / inventory-system / api / stock / query, and the Dubbo interface of the organizational structure system is com.enterprise.org.service.AuthService. A mapping relationship is established between the abstract data input / output items in the code (such as F003 inventory balance) and the external system interface parameters (such as the stockQuantity field of the inventory system interface), generating an interface parameter mapping table (such as F003→stockQuantity, data type String→Integer). If the code data format is inconsistent with the external system interface format (such as the code output being in JSON format, while the external system interface requires XML format), then format conversion logic is added to the code (such as using the Jackson library to implement JSON→XML conversion), or existing enterprise format conversion middleware (such as Apache Camel) is integrated. Next, "permission interface adaptation" is performed: for the permission verification of the operation subject involved in the code (such as the purchasing department approval position), the permission identifier in the code (such as "purchasing department approval position") is mapped to the permission code in the organizational structure system (such as role_code = ...). A mapping is established using "PURCHASE_AUDIT". Dynamic permission verification is implemented by calling the permission query interface of the organizational structure system (AuthService.queryRoleCodeByRoleName(roleName)), avoiding the subsequent maintenance difficulties caused by hard-coded permissions. Finally, "exception interface adaptation" is performed: the verification failure handling logic in the code (such as returning "incorrect amount format") is adapted to the enterprise's existing exception notification system interface (such as message push interface, log recording interface). Exception callback logic is added to the code (such as calling MessageService.sendAlertMessage(alertContent) when verification fails, and synchronously recording exception logs to LogService). After the interface adaptation is completed, a complete code package containing the interface adaptation logic is generated (such as adding interface client classes InventorySystemClient.java and AuthSystemClient).(Java); For example, "When task unit T002 needs to query inventory balance, it calls the inventory system REST API through InventorySystemClient.java, mapping the F003 parameter in the code to the stockQuantity field of the interface to achieve data interaction adaptation"; this adaptation process differs from the traditional design of "strong coupling between code and interface". Through "parameter mapping + middleware integration + dynamic calling", it ensures that the code is compatible with the enterprise's existing system interfaces, reduces system integration costs, and improves code scalability (e.g., when external system interfaces are updated subsequently, only the interface client class needs to be modified, without changing the core business code).

[0096] Preferably, in the specific implementation of step 53, the generated complete code package containing interface adaptation logic is used as the processing object to carry out the third stage—code integration and integration testing: First, code integration is performed: according to the enterprise's existing project architecture specifications (such as Maven project directory structure, microservice module division), the main class (such as PurchaseApplyAuditService.java), configuration class (TriggerConfig.java), utility class (ValidationUtil.java), and interface client class (InventorySystemClient.java) in the complete code package are placed into the corresponding directories (src / main / java / com / enterprise / purchase / service / , src / main / java / com / enterprise / purchase / config / , etc.), and the project dependency configuration file is updated (such as pom.xml to add external system interface client dependencies, such as Spring Cloud). OpenFeign dependency); then perform integration testing: build a test environment consistent with the enterprise production environment (e.g., the same version of JDK, middleware, and the same external system test instances), write integration test cases (designed according to business processes, such as "Purchase requisition submission → T001 preprocessing → T002 review (trigger condition within 360 seconds) → T003 budget verification (including verification logic)"), and execute the test cases to verify the code functionality: verify whether the task unit code can execute the business logic normally (e.g., T002 can correctly query the purchase requisition data and update the review status), whether the trigger condition code can be scheduled according to parameters (e.g., whether T002 is triggered within 360 seconds after T001 is completed), whether the verification logic code can accurately intercept exceptions (e.g., whether the correct prompt is returned when a non-numerical purchase amount is entered), and whether the interface adaptation can interact normally (e.g., whether T002 can succeed). (Call the inventory system interface to query data); If the test finds a problem (such as the T002 trigger delay exceeding 360 seconds), then backtrack to the code conversion or interface adaptation stage, check if the parameter conversion is incorrect (such as 360 seconds mistakenly converted to 360000 milliseconds = 6 minutes), correct it, and retest until all test cases pass, generating a test-passing executable code package; This integration and testing process solves the problems of "integration failure" or "functional incompatibility" caused by "direct deployment after code conversion" in traditional solutions. It ensures the executability and correctness of the code through "standardized integration + environment consistency testing". For example, in the manufacturing procurement scenario, "execute 10 complete procurement review process test cases, all task units, trigger conditions, and verification logic are executed normally, the interface interaction is normal, and the test-passing code package PURCHASE-FLOW-V1.0.jar is generated."

[0097] Preferably, in the specific technical implementation of step 53, the generated executable code package that has passed the test is taken as the final processing object, and the fourth stage—generating an executable process model that conforms to the enterprise's SOP—is carried out: First, an "SOP compliance identifier" is added to the code package: the "SOP number" (such as SOP-PUR-001), "version number" (V2.0), and "summary of core constraint clauses" (such as "purchase review time ≤ 360 seconds, amount must be numeric") of the corresponding process in the structured SOP model generated in step 1 are extracted and written into the metadata file of the code package (such as META-INF / SOP-INFO.MF) to clearly identify the SOP compliance information corresponding to the code package; then, the executable code package that has passed the test is adapted to the format of the enterprise's existing process deployment package (such as Docker image, WAR package) to generate a process model package that can be directly deployed (such as Docker image enterprise / purchase-flow:V1.0, which includes code package, dependency library, and configuration file); finally, the deployable process model package is subjected to "final verification of SOP compliance": by calling the verification result set in step 52 to check The interface is queried to confirm that all code components in the model package correspond to model components with "comprehensive verification result = passed", and that the SOP information in the metadata file is consistent with the structured SOP model. After verification, an "executable process model that conforms to the enterprise SOP" is officially generated. For example, "Docker image enterprise / purchase-flow:V1.0, metadata file marked with SOP number SOP-PUR-001, version V2.0, including compliance task unit code and interface adaptation logic such as T002 and T003, after verification, it is used as an executable process model that conforms to the enterprise SOP". This technology achieves a full-link design of "code conversion - interface adaptation - integration testing - SOP identification", which is different from the shortcomings of traditional solutions that "only focus on code executability and ignore SOP compliance".

[0098] Figure 2 This is a schematic diagram of a device for orchestrating and dynamically adjusting a process driven by an enterprise SOP model, as described in an embodiment of this application. Figure 2As shown, it includes: a modeling unit: used to extract elements and perform structured transformation on the original SOP document of the enterprise's business process, extracting elements including process nodes, logical relationships between nodes, approval rules, and data interaction requirements to generate a structured SOP model; an initial compilation unit: used to perform executable mapping on the process nodes, logical relationships between nodes, approval rules, and data interaction requirements in the structured SOP model to generate an initial process orchestration model; an exception unit: used to generate a process exception feature set based on the process operation data generated during the operation of the initial process orchestration model; an adjustment unit: used to generate a dynamically adjusted process orchestration model based on the process exception feature set and the original rules in the structured SOP model; and an execution unit: used to generate an executable process model that conforms to the enterprise's SOP based on the dynamically adjusted process orchestration model.

[0099] The above Figure 2 The specific implementation of each unit in the embodiment can be found in the above. Figure 1 The details of that record will not be repeated here.

[0100] The relative descriptions such as “higher,” “lower,” “more targeted,” and “more relevant” mentioned in this application should be understood objectively in conjunction with the technical background and current level of technology in laboratory threat assessment, and are not intended to describe an ideal state in which the technical effect reaches an absolute. For those skilled in the art, the core function of such statements is to objectively reflect the relative improvement in technical effect achieved by this application through specific technical designs such as "attack chain stage decomposition to generate a labeled feature vector table", "multi-dimensional profiling of detection resources to construct a technical capability matrix with correlation coefficients", "digital instruction hierarchical encoding to generate an execution and anomaly handling record table with time-series trajectory", and "two-dimensional efficiency of scheduling strategy - time delay model to generate strategy scheduling parameters adapted to the whole link"—that is, compared with the prior art, the solution of this application presents better performance in terms of the clarity of detection task stage requirements, the rationality of resource and stage requirements matching, the traceability of scheduling execution process, and the continuous optimization of scheduling parameters throughout the whole link, rather than an absolute promise of technical effect. This approach to description meets the requirements of rigor in technical solution description, enabling those skilled in the art to clearly identify the differences in technical effects between this application and existing technologies, and to accurately grasp the improvement value of the solution in the refined scheduling of the entire detection task chain in laboratory threat assessment scenarios.

Claims

1. A method for enterprise SOP model-driven process orchestration and dynamic adjustment, characterized in that, include: Step 1: Extract elements and transform the original SOP document of the enterprise business process into a structured form. Extract elements including process nodes, logical relationships between nodes, approval rules and data interaction requirements to generate a structured SOP model. Step 2: Based on the structured SOP model, perform executable mapping on the process nodes, logical relationships between nodes, approval rules, and data interaction requirements to generate an initial process orchestration model; Step 3: Generate a set of process anomaly features based on the process execution data generated during the initial process orchestration model operation; Step 4: Based on the process anomaly feature set and combined with the original rules in the structured SOP model, generate a dynamically adjusted process orchestration model. Step 5: Based on the dynamically adjusted process orchestration model, generate an executable process model that conforms to the enterprise's SOP. Specifically, step 4 includes: Step 41: Classify and label the process exception feature set according to the exception type and associated task unit, and distinguish the associated task unit identifiers corresponding to the three types of exceptions: node processing time exceeding the limit, rule verification failure, and data interaction interruption, so as to generate the classified exception feature set. Step 42: Based on the original rules in the structured SOP model, perform rule clause matching on the classified abnormal feature set to determine the process constraint clauses in the original rules corresponding to each abnormality, so as to generate an abnormal-rule association table. Step 43: Based on the preset adjustment rule base, perform adjustment strategy matching on the exception-rule association table to match the corresponding trigger condition adjustment method or verification logic modification scheme from the adjustment rule base according to the exception type and the associated original rule clause, so as to generate an exception adjustment scheme set. Step 44: Based on the set of exception adjustment schemes, update the parameters of the initial process orchestration model to modify the triggering conditions or verification logic of the corresponding task units according to the adjustment methods in the set of exception adjustment schemes. Integrate all updated task units, triggering conditions and verification logic to generate a dynamically adjusted process orchestration model.

2. The method according to claim 1, characterized in that, Step 2 specifically involves: based on the structured SOP model, performing executable mapping on the process nodes, logical relationships between nodes, approval rules, and data interaction requirements, so as to map the process nodes into system-recognizable task units, the logical relationships between nodes into triggering conditions of task units, and the approval rules into verification logic of task units, in order to generate an initial process orchestration model.

3. The method according to claim 2, characterized in that, Step 2 specifically includes: Step 21: Convert the process nodes in the structured SOP model into a system-recognizable format, and parse the operation subject, operation content and data input and output items of the process nodes to generate system-recognizable task units. Step 22: Based on the task unit, perform trigger condition mapping on the logical relationships between nodes in the structured SOP model, and convert the sequential relationship, branch relationship and merging relationship between nodes into the pre-execution conditions and post-trigger rules of the task unit to generate the trigger conditions of the task unit. Step 23: Perform validation logic mapping on the approval rules in the structured SOP model, convert the data validation items, permission validation items and condition validation items in the approval rules into automatic validation rules in the task unit execution process, integrate the task unit, the triggering conditions of the task unit and the validation logic of the task unit to generate the initial process orchestration model.

4. The method according to claim 1, characterized in that, Step 3 specifically involves: analyzing the abnormal indicators of the process operation data generated during the initial process orchestration model operation, identifying abnormal indicators including node processing time exceeding limits, rule verification failure, and data interaction interruption, in order to generate a process abnormal feature set.

5. The method according to claim 4, characterized in that, Step 3 specifically includes: Step 31: Extract metrics from the process operation data generated during the initial process orchestration model operation. Extract metrics including the processing time of each task unit, the execution result of automatic verification rules, and the data interaction status to generate a process metric dataset. Step 32: Based on the running indicator dataset, compare the processing time of each task unit with the preset time threshold, compare the execution result of the automatic verification rule with the preset success status, and compare the data interaction status with the preset normal status to identify indicators whose processing time exceeds the preset time threshold, whose automatic verification rule execution result is failure, and whose data interaction status is interrupted, so as to generate a preliminary abnormal indicator set. Step 33: Perform feature annotation on the preliminary abnormal indicator set, annotate the abnormal type and associated task unit information corresponding to each abnormal indicator, and integrate them to form a process abnormal feature set. The abnormal types include node processing time exceeding the limit, rule verification failure, and data interaction interruption.

6. The method according to claim 1, characterized in that, Step 4 specifically involves: based on the process anomaly feature set and combined with the original rules in the structured SOP model, performing rule matching and parameter updates on the initial process orchestration model, matching the anomaly indicators in the process anomaly feature set with the preset adjustment rule library, and updating the triggering conditions or verification logic of the task unit according to the matching results to generate a dynamically adjusted process orchestration model.

7. The method according to claim 1, characterized in that, Step 5 specifically involves: performing a consistency check between the dynamically adjusted process orchestration model and the structured SOP model to verify whether the adjusted task units, triggering conditions, and verification logic meet the requirements of the original SOP elements, so as to generate an executable process model that conforms to the enterprise SOP.

8. The method according to claim 7, characterized in that, Step 5 specifically includes: Step 51: Extract the task units, triggering conditions, and verification logic from the dynamically adjusted process orchestration model, as well as the process nodes, logical relationships between nodes, and approval rules from the structured SOP model, to generate a set of elements to be verified. Step 52: Based on the set of elements to be verified, perform element correspondence comparison, check the matching degree between task units and process nodes, verify the compliance of triggering conditions and logical relationships between nodes, and compare the consistency between verification logic and approval rules to generate a verification result set. Step 53: Based on the verification result set, perform executable code conversion and interface adaptation on the dynamically adjusted process orchestration model that has passed all comparison items, and integrate the converted code and adapted interface to generate an executable process model that conforms to the enterprise SOP.

Images