ERP (Enterprise Resource Planning) cross-module high-risk operation identification and grading processing method, system and device

Abstract

The invention discloses an ERP (Enterprise Resource Planning) cross-module high-risk operation identification and grading processing method, system and device, and relates to the technical field of data security. The method comprises the following steps of high-risk operation identification optimization, risk level grading optimization and grading disposal and alarm. According to the method, business logs and interface calling of each ERP module are collected and uniformly coded, adaptability evaluation is performed on business log granularity to determine whether corresponding log granularity adjustment is adopted or not, and scene recognition and risk scoring are performed on cross-module association operation through a rule engine and anomaly detection. Meanwhile, whether the risk grading threshold value is dynamically optimized or not is determined, finally, the corresponding grading disposal process is triggered according to the divided risk grades, linkage alarm and work order closed loop are carried out, the accuracy of high-risk operation identification is improved, and the efficiency is improved. The problem that in the prior art, due to the fact that the service log granularity is inconsistent, the high-risk operation recognition accuracy is lowered is solved.

Description

Technical Field

[0001] This invention relates to the field of data security technology, and in particular to a method, system, and apparatus for identifying and classifying high-risk operations across ERP modules. Background Technology

[0002] To construct a dynamic process system from risk discovery to closed-loop management, and to implement it with a typical ERP (Enterprise Resource Planning) system, a closed-loop control system was designed, encompassing risk identification, risk modeling, risk classification, risk handling, monitoring and early warning, and continuous optimization. Specifically, risk identification is used to discover "potentially high-risk operations across modules" within the ERP system; risk modeling is used to build risk analysis models to provide a basis for classification; risk classification is used to categorize risky operations based on model results and business strategies; risk handling is used to implement differentiated control measures based on risk levels. For example, if a user modifies supplier master data in the procurement module and immediately executes a payment operation in the finance module, the system automatically blocks the payment and requires approval from the finance manager; monitoring and early warning are used to continuously monitor the system's risk situation and provide real-time alerts for anomalies; and continuous optimization is used to establish a closed-loop mechanism to continuously optimize risk rules and handling strategies. Risk classification first sets classification standards (e.g., high / medium / low risk), then sets thresholds for risk scores and labels risk events, and finally outputs the results into the risk handling process. Risk handling is implemented through methods such as real-time blocking by ERP plugins or middleware risk control modules, system alerts, approval workflow suspension, and risk log archiving.

[0003] For example, a Chinese invention patent application with publication number CN119357985A describes a method and system for managing enterprise data assets, which includes: establishing virtual models of various types of enterprise data assets; initially planning data transmission paths based on the output of the virtual models; monitoring and optimizing data transmission paths in real time; assessing the risks of data assets during transmission; and dynamically adjusting the sensitivity level of the data based on the risk assessment results.

[0004] For example, the Chinese invention patent with announcement number CN117195297B discloses a data security and privacy protection system and method based on ERP, which includes: a data encryption module for encrypting sensitive data in an enterprise resource planning (ERP) system and generating encrypted data; an access control module for determining multiple data access permissions corresponding to multiple user IDs based on a preset access control mapping table; an audit trail module for recording sensitive operations in the ERP system; a data backup and recovery module for backing up data in the ERP system within a set period and recovering data in the ERP system in response to user-inputted data recovery commands; and a risk assessment module for identifying security risk information of sensitive data in the ERP system and generating risk management strategy information for the ERP system based on the security risk information.

[0005] The above-mentioned technology has at least the following technical problems: ERP systems contain a large number of operations and business processes. To identify risky operation chains across modules, a more efficient log analysis and behavior chain tracking mechanism is needed. However, existing log management and operation trajectory analysis technologies may have performance bottlenecks when facing large-scale and complex ERP applications. Specifically, if the system only records high-level operations (such as "saving documents"), it may result in missing behavior chain information. If the system log granularity is too fine (recording changes to every field), although the information is rich, the data volume will increase dramatically, which may increase the difficulty of analysis. Summary of the Invention

[0006] To address the technical problem of decreased accuracy in identifying high-risk operations due to inconsistent granularity of business logs in existing technologies, embodiments of the present invention provide a method, system, and apparatus for identifying and classifying high-risk operations across ERP modules. The technical solution is as follows: On the one hand, a method for identifying and classifying high-risk operations across ERP modules is provided. This method includes: collecting and uniformly encoding business logs and interface calls of each ERP module, while conducting an adaptability assessment of the business log granularity to determine whether to adjust the log granularity accordingly, thereby reducing the impact of log granularity on the identification of high-risk operations; identifying scenarios and scoring risks of cross-module related operations through a rule engine and anomaly detection, while deciding whether to dynamically optimize the risk classification threshold to improve the accuracy of identifying and classifying high-risk operations; triggering corresponding classification processes based on the classified risk level, and performing linked alarms and work order closure.

[0007] On the other hand, an ERP cross-module high-risk operation identification and hierarchical handling system is provided. This system includes: a high-risk operation identification optimization module for collecting and uniformly encoding business logs and interface calls of each ERP module, and simultaneously evaluating the adaptability of business log granularity to determine whether to adjust the log granularity accordingly, thereby reducing the impact of log granularity on high-risk operation identification; a risk level classification optimization module for identifying scenarios and scoring risks of cross-module related operations through a rule engine and anomaly detection, and determining whether to dynamically optimize the risk classification threshold to improve the accuracy of identifying and classifying high-risk operations; and a hierarchical handling and alarm module for triggering corresponding hierarchical handling processes based on the classified risk levels, and performing linked alarms and work order closure.

[0008] On the other hand, an ERP cross-module high-risk operation identification and classification handling device is provided. The device includes: a data acquisition layer device, a risk identification and analysis layer device, and a risk classification and handling layer device. The data acquisition layer device is used to collect user operation logs, approval logs, and system events from each ERP module in real time. The main devices include a log acquisition server, an ERP interface acquisition gateway, and a data proxy node. The risk identification and analysis layer device is used to perform rule matching and correlation analysis, support machine learning algorithms, and realize cross-module operation chain tracing. The main devices include a rule engine server, a risk control model calculation server, and a data analysis node. The risk classification and handling layer device is used to classify events according to risk scores, business rules, and threshold settings, while supporting dynamic threshold adjustment. The main devices include a risk classification engine host, an automatic handling server, and a rule management console.

[0009] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following: 1. By collecting and uniformly encoding business logs and interface calls from various ERP modules, and simultaneously evaluating the adaptability of business log granularity, the system determines whether to adjust the log granularity accordingly. This reduces the impact of log granularity on the identification of high-risk operations, thus solving the problems of inaccurate log recording and lack of cross-module correlation in existing technologies, which lead to the inability to comprehensively identify high-risk operations. This not only improves the efficiency and accuracy of log processing but also enhances the sensitivity to high-risk operations. Furthermore, through a rule engine and anomaly detection, scenario identification and risk scoring are performed on cross-module related operations. This overcomes the shortcomings of traditional rule engines, which often rely on statically configured rule sets and lack adaptability to dynamically changing business needs, resulting in untimely identification of new risk patterns. Determining whether to dynamically optimize the risk classification threshold not only improves the accuracy of identifying and classifying high-risk operations, but also avoids the problems that fixed thresholds may lead to overprotection (high false alarms) or underprotection (missed alarms), and the inability to dynamically adapt to changing risk environments. Finally, based on the classified risk level, the corresponding graded handling process is triggered, and a closed loop of linked alarms and work orders is established. This makes up for the lack of a good linkage mechanism between the generation of alarm information and the actual risk handling process in the existing technology, which leads to the operator's untimely response to high-risk events. It improves the response speed and efficiency, reduces manual intervention, and ensures timely handling of high-risk events. At the same time, it realizes the closed-loop management of alarm information, ensuring that each high-risk event can be effectively tracked and handled, and reducing the omission rate of safety events.

[0010] 2. The accumulated scores for both positive and negative log granularity adjustment are compared with the positive and negative adjustment trigger values, respectively. This reduces the current lack of an effective real-time evaluation mechanism to monitor the actual impact of log granularity adjustment on the identification and classification of high-risk operations. If the accumulated score for positive log granularity adjustment is greater than the positive adjustment trigger value, positive log granularity adjustment is performed; conversely, if the accumulated score for negative log granularity adjustment is less than the negative adjustment trigger value, negative log granularity adjustment is performed. This helps address the problem that traditional log granularity configurations are often fixed and lack adaptability to changes in system load and risk. By controlling the adjustment of log granularity, it avoids excessively high... This approach avoids the storage costs and performance burden caused by excessive log detailing, while ensuring that no critical information about high-risk operations is missed. A forward-reverse granularity adjustment risk impact assessment is then performed to reflect the degree of impact of log granularity adjustment on the identification and classification of high-risk operations. Evaluating the high-risk operation identification results after forward and reverse granularity adjustment helps quantify the impact of granularity adjustment on risk identification, confirming whether the granularity adjustment effectively improves the system's sensitivity to high-risk operations. Otherwise, a forward-reverse granularity adjustment risk impact assessment is directly performed. By dynamically evaluating granularity adjustment, the system can find the optimal balance between resource usage and risk identification, avoiding unnecessary performance overhead and missed risk reports.

[0011] 3. After normalizing the positive and negative granular control quantities, a smoothing process is performed to obtain the risk impact assessment quantity. This compensates for the inability of existing technologies to accurately assess the true impact of log granular control on risk identification, forming a measurable "risk impact index." This provides basic data for subsequent dynamic grading and strategy optimization. Then, the risk grading impact factor is obtained by projecting the risk impact assessment quantity. This not only couples the granular control effect with the risk grading system but also achieves adaptive grading optimization capabilities. Furthermore, it determines the numerical relationship between the risk grading impact factor and the risk grading impact limit. If the risk grading impact factor is greater than the preset risk grading impact limit, it is introduced into the risk grading stage for use, avoiding direct intervention of risk factors in the grading stage, which can easily lead to system instability. Through this threshold judgment and caching mechanism, a stability control layer mechanism is introduced to ensure the smooth evolution of the system. Conversely, caching the risk grading impact factor in the impact factor cache queue helps improve data utilization. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart illustrating the method for identifying and classifying high-risk operations across ERP modules provided in this embodiment of the invention. Figure 2 This is a schematic diagram of the log granularity adjustment determination process provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the log granularity positive adjustment process provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of the ERP cross-module high-risk operation identification and hierarchical handling system provided in the embodiment of the present invention. Detailed Implementation

[0014] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0015] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0016] This invention provides a method, system, and apparatus for identifying and classifying high-risk operations across ERP modules. For example... Figure 1 The diagram shown is a flowchart of the ERP cross-module high-risk operation identification and hierarchical handling method provided by an embodiment of the present invention. The processing flow of this method may include the following steps: Business logs and interface calls from each ERP module are collected and uniformly encoded. At the same time, the adaptability of business log granularity is evaluated to determine whether corresponding log granularity adjustments should be made, thereby reducing the impact of log granularity on the identification of high-risk operations.

[0017] By using a rules engine and anomaly detection, cross-module related operations are identified and risk-scored. At the same time, it is determined whether to dynamically optimize the risk classification threshold to improve the accuracy of identifying and classifying high-risk operations.

[0018] Based on the risk level classification, the corresponding graded handling process is triggered, and linked alarms and work order closure are implemented.

[0019] In this embodiment, by uniformly encoding business logs and interface calls, consistency of logs from different modules can be ensured. This enables more efficient processing and analysis of cross-module logs within the same system, improving log processing efficiency and accuracy, reducing information silos, and enhancing data correlation. Simultaneously, the log granularity of each module is dynamically adjusted based on system requirements and risk assessment, ensuring that the log recording is detailed enough to guarantee comprehensive risk identification while avoiding redundant data and resource waste. Fine-grained granularity control improves sensitivity to high-risk operations and reduces the burden of irrelevant logs on system performance. Furthermore, through rule-based... The combination of the engine and the anomaly detection model can identify cross-module related operations, especially complex operation scenarios defined by business rules, time sequence, and other conditions (e.g., the temporal relationship between financial approval and inventory changes). This helps improve the recognition rate of cross-module operations and reduce missed reports caused by "information silos" between modules. Furthermore, by analyzing real-time and historical data, the system automatically adjusts the risk classification threshold. For example, when the frequency or amount of certain operations exceeds the set range, the system automatically lowers the risk threshold to enhance alarm sensitivity. This enables the system to adjust the risk classification according to the actual situation and improves the ability to accurately identify high-risk operations.

[0020] Furthermore, the specific process for adaptability assessment of business log granularity is as follows: Log granularity adaptation evaluation indicators are obtained based on log monitoring tools. These indicators are then compared with log granularity judgment parameters extracted from a pre-set database to determine whether to count positive or negative log granularity adjustment scores. The log granularity judgment parameters are obtained from the pre-set database and are typically pre-set by technical personnel based on experience rules, historical data, and relevant business log recording specifications. These parameters are stored in the pre-set database for later retrieval.

[0021] The log positive granularity adjustment score is specifically counted under the following conditions: the log write latency is lower than the minimum value of the corresponding log write latency tolerance range, the cross-module correlation is lower than the corresponding module correlation threshold, and the high-risk operation detection accuracy is lower than the minimum limit value of high-risk operation detection. When one or more of these conditions are met, the positive counter will add up the count.

[0022] The log reverse granularity adjustment score is subject to the following technical conditions: the log write latency exceeds the maximum value of the corresponding log write latency tolerance range, the storage growth rate is greater than the corresponding maximum storage growth rate limit, the system load exceeds the corresponding system load tolerance threshold, the log loss rate is greater than the corresponding log loss rate threshold, and the log integrity is lower than the corresponding log integrity judgment threshold. When one or more of these conditions are met, the reverse counter will add up the count.

[0023] No additional processing will be performed for comparisons that do not meet the above criteria.

[0024] The evaluation metrics for log granularity adaptation include log write latency, storage growth rate, system load, log loss rate, log integrity, cross-module correlation, and accuracy of high-risk operation detection.

[0025] It's worth noting that log write latency represents the delay in writing logs for each operation. If the log write latency is too high, exceeding the tolerance range of business operations, monitoring tools (such as Prometheus and Grafana) should be used to monitor the write latency of each log in real time. Storage growth rate represents the amount of log data per unit time. If the log storage growth rate is too fast, it may lead to excessive consumption of storage space. Monitor whether the log data is growing exponentially through indicators such as log storage compression ratio and storage growth trend. System load represents the CPU and memory resource usage of log recording. Use system monitoring tools (such as top, htop, and Resource Monitor) to check the resource consumption of log collection, especially the pressure of log aggregation processing. Log loss rate represents the ratio of the number of lost log entries to the total number of recorded log entries. A high log loss rate, especially under high concurrency, may result in some important operation information not being recorded. Monitor log loss or log collection failures through a log management platform (such as ELKStack and Splunk).

[0026] Specifically, log completeness reflects the integrity of log fields, such as the number of missing fields and missing data in log entries. If logs record incomplete operation information (e.g., missing before and after values, context information), they cannot accurately reflect business behavior. Automated tools are used to check the integrity of log data and identify whether there are missing fields or erroneous records. Cross-module correlation represents the correlation information of cross-module operations and is used to evaluate whether logs can fully support cross-module event tracing. If risk operation chains cannot be traced across modules, the log granularity needs to be improved. Analyze whether the operations of multiple modules can be associated in the logs through global identifiers (such as trace_id, order_id, etc.). The number of modules associated with the operations of each module through global identifiers is the cross-module correlation. High-risk operation detection accuracy is obtained by analyzing historical operation logs to determine whether the system can accurately identify key risk operations and whether there are false positives and false negatives. The ratio of the number of risk identifications without false positives or false negatives to the total number of detections is used to calculate this value. It is mainly used to determine whether the system can automatically identify high-risk operations (such as cash flow and inventory adjustments) and trigger alarms.

[0027] Log granularity determination parameters include log write latency tolerance range, maximum storage growth rate limit, system load tolerance threshold, log loss rate threshold, log integrity determination threshold, module correlation threshold, and minimum limit for high-risk operation detection; among which, the log write latency tolerance range represents the range between the minimum and maximum allowable time delays during log writing.

[0028] In this embodiment, the counting rule for forward granularity adjustment scores is based on considerations of the accuracy of high-risk operation detection. When log granularity is too low, leading to a decrease in accuracy, the count is automatically incremented, prompting the system to increase log granularity under this condition to ensure that critical operations are fully recorded. Simultaneously, the counting conditions for reverse granularity adjustment scores consider factors such as log write latency, storage growth, and system load, all of which are key indicators affecting system performance. Furthermore, the incrementing of reverse granularity adjustment scores means that when log granularity is too high, the granularity will be automatically reduced to alleviate system burden. The counting conditions in the reverse granularity adjustment scores include a determination that the storage growth rate exceeds the maximum limit. When the system faces storage pressure, reverse granularity adjustment is triggered to reduce log storage requirements. Moreover, by setting forward and reverse granularity adjustment... The system's segmentation counting rules allow for dynamic adjustment of log granularity based on current performance and risk identification needs, avoiding the shortcomings of static configuration. Furthermore, by monitoring multiple indicators such as log write latency, correlation, and loss rate in real time and adjusting granularity accordingly, the system provides clearer log quality monitoring data. In addition, the reverse granularity adjustment mechanism helps reduce issues such as log write latency, loss rate, and log integrity, ensuring the completeness and accuracy of log records. Moreover, when the system load is too high or there are potential log loss issues, the granularity can be reduced in a timely manner to ensure that critical data is not lost due to performance problems. This helps avoid false alarms and missed alarms caused by excessively high log granularity or system performance issues, improving the stability of operational risk identification.

[0029] like Figure 2The diagram illustrates the flowchart of the log granularity adjustment determination provided in this embodiment of the invention. The specific logic is as follows: The cumulative values ​​of the read forward counter and reverse counter are recorded as the cumulative value of the log forward granularity adjustment score and the cumulative value of the log reverse granularity adjustment score, respectively. These are then compared with the forward adjustment trigger value and the reverse adjustment trigger value, respectively. If the cumulative value of the log forward granularity adjustment score is greater than the forward adjustment trigger value, forward log granularity adjustment is performed, followed by a forward-reverse granularity adjustment risk impact assessment; otherwise, a forward-reverse granularity adjustment risk impact assessment is performed directly. If the cumulative value of the log reverse granularity adjustment score is less than the reverse adjustment trigger value, reverse log granularity adjustment is performed, followed by a forward-reverse granularity adjustment risk impact assessment; otherwise, a forward-reverse granularity adjustment risk impact assessment is performed directly. This process helps improve the system's sensitivity to high-risk operations, thereby increasing the accuracy of high-risk operation identification.

[0030] Further, the specific steps to determine whether to implement corresponding log granularity adjustments are as follows: The accumulated values ​​of the forward counter and the reverse counter are recorded as the accumulated value of the log forward granularity adjustment score and the accumulated value of the log reverse granularity adjustment score, respectively, and compared with the preset forward adjustment trigger value and reverse adjustment trigger value, respectively.

[0031] Specifically, the positive adjustment trigger value and the negative adjustment trigger value are obtained from the preset database. The preset staff will average the cumulative values ​​of the log positive granularity adjustment score and the cumulative values ​​of the log negative granularity adjustment score obtained from the historical time period to obtain the corresponding positive adjustment trigger value and negative adjustment trigger value.

[0032] If the cumulative value of the log positive granularity adjustment score is greater than the positive adjustment trigger value, log granularity positive adjustment will be performed, followed by a positive-reverse granularity adjustment risk impact assessment to reflect the degree of impact of log granularity adjustment on the identification and classification of high-risk operations; otherwise, a positive-reverse granularity adjustment risk impact assessment will be performed directly.

[0033] If the cumulative score of log reverse granularity adjustment is less than the reverse adjustment trigger value, log granularity reverse adjustment will be performed, followed by a risk impact assessment of forward-reverse granularity adjustment; otherwise, a risk impact assessment of forward-reverse granularity adjustment will be performed directly.

[0034] A positive adjustment trigger value indicates that the coarseness of the business log granularity has reached the maximum threshold that requires adjustment, while a negative adjustment trigger value indicates that the fineness of the business log granularity has reached the minimum threshold that requires adjustment.

[0035] In this embodiment, by comparing the cumulative scores of forward and reverse granularity adjustment with the trigger value, the granularity of the logs can be dynamically adjusted according to changes in system load and operational behavior. When the granularity is too high or too low, timely adjustments can be made to ensure that the business logs are neither overloaded nor overly simplistic. Monitoring the scores of forward and reverse granularity adjustment helps to determine in real time when the log granularity needs to be increased or decreased, thereby optimizing the identification of high-risk operations. Furthermore, for high-risk operations, refining the log granularity can provide more information to analyze potential threats. By periodically evaluating the identification results of high-risk operations after forward and reverse granularity adjustment, it helps to quantify the impact of granularity adjustment on risk identification, and thus helps to confirm whether the adjustment of granularity has effectively improved the system's sensitivity to high-risk operations. In addition, by setting thresholds for forward and reverse granularity adjustment scores and combining them with the real-time evaluation system, the risk threshold can be adaptively adjusted according to the current log granularity. Moreover, when the traffic is high or the risk is high, the system can automatically increase the sensitivity of risk identification to ensure that no potential high-risk operations are missed.

[0036] like Figure 3 The diagram illustrates the process of positive log granularity adjustment provided in this embodiment of the invention. The specific logic is as follows: the difference between the cumulative positive log granularity adjustment score and the positive adjustment trigger value is recorded as the positive granularity adjustment amount. Based on this positive granularity adjustment amount, the increase ratio of operation environment parameter records is obtained. The initial number of operation environment parameter types for business log records is increased by this increase ratio, resulting in an optimized number of operation environment parameter types. If the optimized number of operation environment parameter types exceeds the limit for operation environment parameter types, business log recording is performed based on the limit; otherwise, business log recording continues based on the optimized number of operation environment parameter types. Simultaneously, the inter-module log association recording function is enabled to improve cross-module risk identification capabilities. Through the above process, not only is the risk identification capability for cross-module operations improved, but the accuracy of identifying high-risk operations is also enhanced.

[0037] As a further embodiment, the specific process of positive log granularity adjustment is as follows: The difference between the cumulative value of the log positive granularity adjustment score and the positive adjustment trigger value is the positive granularity adjustment amount. This means that the positive granularity adjustment amount is obtained by performing a difference calculation between the cumulative value of the log positive granularity adjustment score and the positive adjustment trigger value. Based on the positive granularity adjustment amount, the corresponding operating environment parameter record increase ratio is obtained by matching in the positive granularity adjustment mapping table. This indicates the proportion of data types of operating environment parameters that need to be added to the records.

[0038] It should be added that the positive granularity adjustment mapping table is a data table used to reflect the mapping relationship between the positive granularity adjustment amount and the increase ratio of the recorded operating environment parameters. It is trained by the positive granularity adjustment training data, which includes the positive granularity adjustment amount obtained in the historical time period, as well as the increase ratio of the recorded operating environment parameters set by the staff based on experience rules and historical data.

[0039] The number of optimized operation environment parameter types is obtained by increasing the initial number of operation environment parameter types in the business log records by a certain percentage. This is achieved by multiplying the initial number of operation environment parameter types in the business log records by the percentage increase in operation environment parameter records. Operation environment parameter types include, but are not limited to, user ID, role, IP, terminal, time, and call source.

[0040] If the number of optimized operating environment parameter types exceeds the set limit for the number of operating environment parameter types, business logs will be recorded based on the limit for the number of operating environment parameter types; otherwise, business logs will continue to be recorded based on the number of optimized operating environment parameter types. The limit for the number of operating environment parameter types indicates the maximum number of types that can be tolerated without affecting data analysis resources. Simultaneously, the inter-module log association recording function is enabled to improve the cross-module risk identification capability. The inter-module log association recording function refers to the automatic association and unified recording of log data generated by multiple modules in a system composed of multiple functional modules (such as authentication module, transaction module, risk control module, interface module, etc.) through a unique association identifier or context information, so as to realize the complete tracking and analysis of cross-module event links.

[0041] In this embodiment, by dynamically adjusting the log granularity, the accuracy of identifying high-risk operations is improved while avoiding excessive consumption of system resources. Furthermore, by dynamically optimizing the number of environmental parameter types recorded in the logs, both the accuracy of the logs and unnecessary resource consumption are ensured. At the same time, by setting a maximum tolerable number of parameter types, the richness of log recordings and resource consumption are balanced, which not only improves system performance but also enhances the risk identification capability of cross-module operations. This is beneficial for capturing potential risky behaviors across modules and solves the problem of high-risk cross-module operations not being identified in the prior art.

[0042] Furthermore, the specific process for reverse adjustment of log granularity is as follows: The difference between the cumulative value of the log reverse granularity adjustment score and the reverse adjustment trigger value is called the reverse granularity control amount. This means that the reverse granularity control amount is obtained by performing a difference operation on the cumulative value of the log reverse granularity adjustment score and the reverse adjustment trigger value. The reverse granularity control amount is substituted into the fitted reverse granularity adjustment dataset to output the corresponding business log reverse control parameters. These parameters are then processed with the business log recording frequency and the business log compression rate to obtain the adjusted log recording frequency and the adjusted log compression rate. Specifically, the adjusted log recording frequency is obtained by multiplying the business log recording frequency reduction rate by the business log recording frequency, and the adjusted log compression rate is obtained by multiplying the business log compression increase rate by the business log compression rate. The business log reverse control parameters include the business log recording frequency reduction rate and the business log compression increase rate.

[0043] It should be explained that the reverse granularity adjustment fitting dataset represents a set of mapping relationships between the fitted reverse granularity adjustment amount and the reverse adjustment parameters of the business log. It is constructed based on the logistic regression algorithm, uses the cross-entropy loss function as the optimization criterion, and is trained using the scikit-learn framework. It is obtained by training with the reverse granularity adjustment fitting data, which includes the reverse granularity adjustment amount obtained within the historical time period, as well as the business log reverse adjustment parameters set by the staff based on experience rules and historical data.

[0044] If both the adjusted log recording frequency and the adjusted log compression rate are within the limits set by the business log reverse control data, then subsequent business log recording will continue based on the adjusted log recording frequency and the adjusted log compression rate. The business log reverse control data includes the minimum log recording frequency used to limit the minimum adjustment frequency, and the maximum log compression rate used to limit the maximum adjustment compression rate.

[0045] It should be added that the data for reverse control of business logs is extracted from the preset database. This is usually set in advance by professional technicians based on historical data and experience rules, and stored in the preset database in advance.

[0046] If adjusting the log recording frequency meets the set limit for reverse control of business log data, but adjusting the log compression rate does not meet the set limit for reverse control of business log data, then subsequent business log recording will continue based on the highest value of the adjusted log recording frequency and log compression rate.

[0047] If adjusting the log recording frequency does not meet the set limits for reverse control of business log data, but adjusting the log compression rate does meet the set limits for reverse control of business log data, then subsequent business log recording will continue based on the minimum log recording frequency and the adjusted log compression rate.

[0048] If the above conditions are not met, i.e., adjusting the log recording frequency and adjusting the log compression rate do not meet the limits set for the reverse control data of the business log, then the subsequent business log recording will continue according to the reverse control data of the business log.

[0049] In this embodiment, the calculation of the fitted dataset helps to more accurately determine the log recording frequency and compression ratio, avoiding excessive or insufficient adjustment. Simultaneously, based on the reverse granularity adjustment amount, the log recording and compression strategies are dynamically adjusted to adapt to different system loads and risk requirements. Dynamic adjustment not only avoids excessive system consumption of storage and bandwidth but also helps improve system performance. Furthermore, reasonable adjustment of log recording frequency and compression ratio ensures the integrity of critical log information while reducing unnecessary data storage pressure. More precise control of log recording frequency and compression ratio helps to flexibly respond to different load conditions, avoid resource waste, and dynamically adjust the frequency and compression ratio while ensuring log integrity. Moreover, by setting reasonable limits, the stability and reliability of log recording are ensured, avoiding over-adjustment.

[0050] Furthermore, the specific process for assessing the risk impact of forward-reverse granularity adjustment is as follows: After normalizing the data of the positive and negative granularity control quantities, smoothing is then performed to obtain the risk impact assessment quantity. The smoothing process involves adding the obtained positive and negative granularity control quantities and then averaging them.

[0051] Risk grading impact factors are obtained by projecting risk impact assessment quantities, and the numerical relationship between risk grading impact factors and preset risk grading impact limits is determined. Specifically, if the risk grading impact factor is greater than the preset risk grading impact limit, it is introduced into the risk grading stage for use; otherwise, the risk grading impact factor is cached in the impact factor cache queue.

[0052] Specifically, the risk impact assessment quantity is input into the risk classification and grading projection sequence, and the corresponding risk classification and grading impact factor is output. The risk classification and grading projection sequence is used to reflect the mapping relationship between the risk impact assessment quantity and the risk classification and grading impact factor. It is obtained after training based on the risk classification and grading training data, which includes the risk impact assessment quantity obtained in the historical time period and the risk classification and grading impact factor set by professional and technical personnel based on experience rules.

[0053] The risk classification impact limit indicates the maximum tolerance value for the impact of log granularity adjustment on risk classification. It is usually read from a preset database and set by professional technicians.

[0054] In this embodiment, normalization processing enables forward and reverse granular control quantities to be assessed at the same scale, improving the fairness and consistency of the assessment. Smoothing processing stabilizes the risk assessment trend, avoids misjudgments caused by short-term anomalies, and enhances sensitivity to long-term trend changes. Furthermore, the generation of risk impact assessment quantities helps to form measurable "risk impact indicators," providing basic data for subsequent dynamic classification and strategy optimization. Simultaneously, the projection generation of risk classification impact factors couples the granular control effect with the risk classification system, achieving adaptive classification optimization capabilities. Through threshold judgment and caching mechanisms, a "stability control layer" is introduced to ensure the smooth evolution of the system and to manage low-impact data in the cache queue for subsequent analysis, while also improving data utilization.

[0055] Furthermore, the specific process for deciding whether to dynamically optimize the risk grading threshold is as follows: The risk grading factors are input into the risk threshold dynamic adjustment algorithm to regulate the risk level obtained from the risk grading. The risk threshold dynamic adjustment algorithm is used to automatically adjust the risk threshold according to the real-time system status or risk situation in order to more accurately identify and respond to potential risks. Examples of dynamic adjustment algorithms include statistical algorithms (moving average algorithm, weighted moving average algorithm, etc.), machine learning algorithms (reinforcement learning algorithm, supervised learning algorithm, etc.), and feedback control algorithms (PID controller, Proportional-Integral-Derivative Control).

[0056] The frequency of risk level classification and control is obtained by monitoring the frequency of risk level classification and control within a preset time period; where the preset time period is a fixed time length.

[0057] If the risk level classification control frequency is higher than the set maximum control frequency, the difference between the risk level classification control frequency and the maximum control frequency is obtained. That is, the risk level classification control frequency is subtracted from the maximum control frequency and recorded as the abnormal control frequency difference value. Otherwise, no additional processing is performed.

[0058] The abnormal control frequency difference values ​​are compared with the extracted review grading intervals. The specific comparison process is as follows: If the abnormal adjustment frequency difference value falls within the first-level review range, a review request will be submitted to the manual terminal based on the set first-level review frequency.

[0059] If the abnormal adjustment frequency difference value falls within the secondary review range, a review request will be submitted to the manual terminal based on the set secondary review frequency.

[0060] If the abnormal adjustment frequency difference value falls within the Level 3 review range, a review request will be submitted to the manual terminal based on the set Level 3 review frequency.

[0061] If the abnormal control frequency difference value does not fall within the review and grading interval, that is, the abnormal control frequency difference value is not within the range corresponding to any review and grading interval, then a graded handling shall be carried out.

[0062] The review grading intervals include Level 1, Level 2, and Level 3 review intervals, which are ranked in descending order of urgency for manual review. The urgency of manual review is triggered by the abnormal degree of control frequency based on the current risk level.

[0063] In summary, the frequency of first-level review, second-level review, third-level review, and review grading intervals are all extracted from the preset database. These are generally set in advance by professional technicians and stored in the preset database for future use.

[0064] The decision on whether to dynamically optimize the risk classification threshold includes: detecting whether there is a situation where the risk classification threshold is continuously dynamically optimized through a sliding window; if so, requesting manual terminal intervention for review; otherwise, continuing the classification process.

[0065] In this embodiment, inputting risk grading and influencing factors into the risk threshold dynamic adjustment algorithm helps adjust risk levels based on real-time monitored risk indicators. Furthermore, dynamically adjusting risk levels based on influencing factors helps reduce frequent ineffective adjustments and avoids over-optimization. The algorithm's dynamic adjustment allows for rapid response to changes in the short term, while avoiding unnecessary multiple adjustments. It also enables more accurate risk grading based on actual influencing factors, ensuring timely handling of high-risk operations. Monitoring and adjusting frequency prevents the system from disrupting normal business processes due to frequent adjustments. If frequent risk level adjustments do not match expectations, more refined manual review can be conducted based on the discrepancy value, helping to ensure the rationality of system adjustments. In addition, tiered review allows for timely adjustment of review resources based on the severity or frequency of the review, ensuring timely handling of critical issues. Dividing reviews into multiple levels also avoids excessively frequent or untimely manual reviews, ensuring the rational allocation of review resources.

[0066] Furthermore, the risk grading and classification influencing factors are obtained, which then include: If the accuracy rate of the risk level classification determined based on feedback is lower than the preset minimum accuracy rate, the risk level classification influence factors cached in the influence factor cache queue are obtained, and the mean is calculated to obtain the representative quantity of risk level classification. Otherwise, the identification of high-risk operations continues. The preset minimum accuracy rate is set in advance by professional technicians and stored in a preset database for future use.

[0067] It should be added that the number of high-risk operations with incorrect classification is obtained through a manual terminal, and the error rate is calculated by comparing the number of high-risk operations with the total number of high-risk operations in the risk classification. Then, the classification accuracy rate is obtained by subtracting the error rate from the value 1.

[0068] The risk classification adjustment value is obtained by quantifying the difference between the representative value of risk classification and the preset risk classification influence limit. In other words, the risk classification adjustment value is obtained by calculating the difference between the representative value of risk classification and the preset risk classification influence limit.

[0069] If the risk classification adjustment value is less than the set risk classification adjustment limit value, the risk classification impact factor in the impact factor cache queue will be cleared. The risk classification adjustment limit value is the maximum value used to limit the degree of closeness between the fluctuation of the risk classification impact factor and the risk classification impact limit value.

[0070] If the risk classification adjustment value is not less than the set risk classification adjustment limit value, the difference between the risk classification adjustment value and the risk classification adjustment limit value is compared in the risk classification limit value data table to obtain the corresponding risk classification impact limit adjustment amount, so as to dynamically correct the risk classification impact limit value, that is, to perform a multiplication operation with the risk classification impact limit value.

[0071] It should be added that the difference between the risk classification adjustment value and the risk classification adjustment limit value is called the risk adjustment difference. The risk adjustment difference is input into the risk classification limit data table, and the corresponding risk classification impact limit adjustment amount is output. The risk classification limit data table is a data table that reflects the mapping relationship between the risk adjustment difference and the risk classification impact limit adjustment amount. It is obtained after training based on the risk adjustment training data. The risk adjustment training data includes the risk adjustment difference within the historical time period, as well as the risk classification impact limit adjustment amount set by professional and technical personnel based on experience rules.

[0072] In this embodiment, adjusting risk classification through feedback helps reduce misjudgments and improve the accuracy of risk grading, while also ensuring that the system responds promptly to high-risk operations. Moreover, by eliminating invalid influencing factors, it is beneficial to improve system performance and data validity, avoiding resource waste. At the same time, by dynamically adjusting the risk classification limits based on real-time data and risk feedback, the flexibility and accuracy of risk identification standards are ensured, and the accuracy of risk identification is maintained by correcting the risk classification limits based on real-time feedback and adjustment values.

[0073] like Figure 4 The diagram shown is a structural schematic of the ERP cross-module high-risk operation identification and hierarchical handling system provided in an embodiment of the present invention. The system includes: The high-risk operation identification and optimization module is used to collect and uniformly encode the business logs and interface calls of each ERP module. At the same time, it performs an adaptability assessment of the business log granularity to determine whether to take corresponding log granularity adjustments, thereby reducing the impact of log granularity on high-risk operation identification.

[0074] The risk level classification optimization module is used to identify scenarios and score risks for cross-module related operations through a rule engine and anomaly detection. It also determines whether to dynamically optimize the risk classification threshold to improve the accuracy of identifying and classifying high-risk operations.

[0075] The tiered handling and alarm module is used to trigger the corresponding tiered handling process based on the classified risk level, and to perform linked alarms and work order closure.

[0076] This invention also provides an ERP cross-module high-risk operation identification and classification handling device. The device is used to implement the ERP cross-module high-risk operation identification and classification handling method. The device includes: a data acquisition layer device, a risk identification and analysis layer device, and a risk classification and handling layer device.

[0077] The data acquisition layer equipment is used to collect user operation logs, approval logs and system events from various ERP modules in real time. The main equipment includes log acquisition servers, ERP interface acquisition gateways and data proxy nodes.

[0078] The risk identification and analysis layer equipment is used to perform rule matching and correlation analysis, support machine learning algorithms, and realize cross-module operation chain tracing. The main equipment includes rule engine server, risk control model calculation server, and data analysis node.

[0079] The risk classification and handling layer equipment is used to classify events based on risk scores, business rules, and threshold settings, while also supporting dynamic threshold adjustment. The main equipment includes the risk classification engine host, the automatic handling server, and the rule management console.

[0080] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the flow or function according to the embodiments of the present invention is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. A computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. Available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media. Semiconductor media can be solid-state drives.

[0081] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0082] In this invention, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be a single item or multiple items.

[0083] It should be understood that, in various embodiments of the present invention, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0084] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0085] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the devices, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0086] In the embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0087] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0088] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0089] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0090] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for identifying and classifying high-risk cross-module operations in ERP systems, characterized in that... The method includes: Business logs and interface calls of each ERP module are collected and uniformly encoded. At the same time, the adaptability of business log granularity is evaluated to determine whether corresponding log granularity adjustment should be adopted, thereby reducing the impact of log granularity on the identification of high-risk operations. By using a rule engine and anomaly detection, cross-module related operations are identified and risk-scored, and it is determined whether to dynamically optimize the risk classification threshold to improve the accuracy of identifying and classifying high-risk operations. Based on the risk level classification, the corresponding graded handling process is triggered, and linked alarms and work order closure are implemented.

2. The method for identifying and classifying high-risk cross-module operations in ERP according to claim 1, characterized in that, The specific process for evaluating the adaptability of business log granularity is as follows: Log granularity adaptation evaluation metrics are obtained based on log monitoring tools. These metrics are then compared with extracted log granularity judgment parameters to determine whether to count positive or negative log granularity adjustment scores. The specific counting rules are as follows: The log positive granularity adjustment score is specifically counted under the following conditions: the log write latency is lower than the minimum value of the corresponding log write latency tolerance range, the cross-module correlation is lower than the corresponding module correlation threshold, and the high-risk operation detection accuracy is lower than the minimum limit value of high-risk operation detection. When one or more of these conditions are met, the positive counter will be used to count them cumulatively. The specific technical conditions for the log reverse granularity adjustment score are as follows: the log write latency exceeds the maximum value of the corresponding log write latency tolerance range, the storage growth rate is greater than the corresponding maximum storage growth rate limit, the system load exceeds the corresponding system load tolerance threshold, the log loss rate is greater than the corresponding log loss rate threshold, and the log integrity is lower than the corresponding log integrity judgment threshold. When one or more of these conditions are met, the reverse counter will perform cumulative counting. No additional processing will be performed for comparisons that do not meet the above criteria. The log granularity adaptation evaluation metrics include log write latency, storage growth rate, system load, log loss rate, log integrity, cross-module correlation, and high-risk operation detection accuracy. The log granularity determination parameters include the log write latency tolerance range, the maximum storage growth rate limit, the system load tolerance threshold, the log loss rate threshold, the log integrity determination threshold, the module correlation threshold, and the minimum limit for high-risk operation detection.

3. The method for identifying and classifying high-risk cross-module operations in ERP according to claim 1, characterized in that, The specific steps for determining whether to implement corresponding log granularity adjustment are as follows: The accumulated values ​​of the forward and reverse counters are recorded as the accumulated value of the log forward granularity adjustment score and the accumulated value of the log reverse granularity adjustment score, respectively, and compared with the preset forward adjustment trigger value and reverse adjustment trigger value, as follows: If the cumulative value of the log positive granularity adjustment score is greater than the positive adjustment trigger value, log granularity positive adjustment will be performed, followed by a positive-reverse granularity adjustment risk impact assessment to reflect the degree of impact of log granularity adjustment on the identification and classification of high-risk operations; otherwise, a positive-reverse granularity adjustment risk impact assessment will be performed directly. If the cumulative value of the log reverse granularity adjustment score is less than the reverse adjustment trigger value, log granularity reverse adjustment will be performed, followed by a forward-reverse granularity adjustment risk impact assessment; otherwise, a forward-reverse granularity adjustment risk impact assessment will be performed directly. The positive adjustment trigger value indicates that the coarseness of the business log granularity has reached the maximum threshold for triggering adjustment, while the negative adjustment trigger value indicates that the fineness of the business log granularity has reached the minimum threshold for triggering adjustment.

4. The method for identifying and classifying high-risk cross-module operations in ERP according to claim 3, characterized in that, The specific process for positive adjustment of log granularity is as follows: The difference between the cumulative value of the positive granularity adjustment score and the positive adjustment trigger value is the positive granularity adjustment amount. Based on the positive granularity adjustment amount, the corresponding operating environment parameter record increase ratio is obtained by matching in the positive granularity adjustment mapping table. The number of initial operation environment parameter types recorded in the business log is increased by increasing the proportion of operation environment parameter records, thereby obtaining an optimized number of operation environment parameter types. The operation environment parameter types include user ID, role, IP, terminal, time, and call source. If the number of optimized operating environment parameter types exceeds the set limit for the number of operating environment parameter types, business logs will be recorded based on the limit for the number of operating environment parameter types; otherwise, business logs will continue to be recorded based on the number of optimized operating environment parameter types. The limit for the number of operating environment parameter types indicates the maximum number of types that can be tolerated without affecting data analysis resources. At the same time, enable the function of logging association between modules to improve the ability to identify risks across modules.

5. The method for identifying and classifying high-risk cross-module operations in ERP according to claim 3, characterized in that, The specific process for reverse adjustment of log granularity is as follows: The difference between the cumulative value of the log reverse granularity adjustment score and the reverse adjustment trigger value is recorded as the reverse granularity adjustment amount. The reverse granularity adjustment amount is substituted into the fitted reverse granularity adjustment dataset to output the corresponding business log reverse adjustment parameters. These parameters are then processed with the business log recording frequency and the business log compression rate to obtain the adjusted log recording frequency and the adjusted log compression rate. The business log reverse adjustment parameters include the business log recording frequency reduction rate and the business log compression increase rate. If both the adjustment of the log recording frequency and the adjustment of the log compression rate are within the limits set by the business log reverse control limit data, then the subsequent business log recording will continue according to the adjustment of the log recording frequency and the adjustment of the log compression rate. The business log reverse control limit data includes the minimum value of the log recording frequency used to limit the minimum control frequency of the log recording frequency, and the maximum value of the log compression rate used to limit the maximum control compression rate of the log compression rate. If adjusting the log recording frequency meets the set limit range for reverse control of business log data, but adjusting the log compression rate does not meet the set limit range for reverse control of business log data, then continue to record subsequent business logs based on the highest value of the adjusted log recording frequency and log compression rate. If adjusting the log recording frequency does not meet the set limit range for reverse control of business log data, and adjusting the log compression rate does meet the set limit range for reverse control of business log data, then continue to record subsequent business logs based on the minimum log recording frequency and the adjusted log compression rate. If the above conditions are not met, the data will be restricted from being recorded in subsequent business logs based on the reverse control of the business logs.

6. The method for identifying and classifying high-risk cross-module operations in ERP according to claim 3, characterized in that, The specific process for assessing the risk impact of the forward-reverse granularity adjustment is as follows: After normalizing the positive and negative granularity control quantities, smoothing is then performed to obtain the risk impact assessment quantity. Risk grading impact factors are obtained by projecting risk impact assessment quantities, and the numerical relationship between risk grading impact factors and preset risk grading impact limits is determined. Specifically, if the risk grading impact factor is greater than the preset risk grading impact limit, it is introduced into the risk grading stage for use; otherwise, the risk grading impact factor is cached in the impact factor cache queue. The risk classification impact limit represents the maximum tolerance value for the impact of log granularity adjustment on risk classification.

7. The method for identifying and classifying high-risk cross-module operations in ERP according to claim 1, characterized in that, The specific process for determining whether to dynamically optimize the risk classification threshold is as follows: The risk classification influencing factors are input into the risk threshold dynamic adjustment algorithm to regulate the risk level obtained from the risk classification. The frequency of risk-level classification and control within a preset time period is monitored to obtain the corresponding risk-level classification and control frequency. If the risk level classification control frequency is higher than the set maximum control frequency, the difference between the risk level classification control frequency and the maximum control frequency is obtained and recorded as the abnormal control frequency difference value. The abnormal control frequency difference values ​​are compared with the extracted review grading intervals. The specific comparison process is as follows: If the abnormal adjustment frequency difference value falls within the first-level review range, a review request will be submitted to the manual terminal based on the set first-level review frequency. If the abnormal adjustment frequency difference value falls within the secondary review range, a review request will be submitted to the manual terminal based on the set secondary review frequency; If the abnormal adjustment frequency difference value falls within the third-level review range, a review request will be submitted to the manual terminal based on the set third-level review frequency; If the abnormal adjustment frequency difference value does not fall within the review and grading range, then grading measures will be taken. The review grading intervals include a first-level review interval, a second-level review interval, and a third-level review interval, which are ranked in descending order of the urgency of manual review. The urgency of manual review is triggered based on the degree of abnormality in the control frequency classified by the current risk level. The decision on whether to dynamically optimize the risk classification threshold also includes: detecting whether there is a situation where the risk classification threshold is continuously dynamically optimized through a sliding window; if so, requesting manual terminal intervention for review; otherwise, continuing the classification process.

8. The method for identifying and classifying high-risk cross-module operations in ERP according to claim 6, characterized in that, The process of obtaining risk classification influencing factors then includes: If the accuracy rate of the risk level classification determined based on feedback is lower than the preset minimum accuracy rate, then the risk level classification influence factors cached in the influence factor cache queue are obtained, and the mean is calculated to obtain the representative quantity of risk level classification. The risk classification adjustment value is obtained by quantifying the difference between the representative value of the risk classification and the preset risk classification impact limit. If the risk classification adjustment value is less than the set risk classification adjustment limit value, the risk classification impact factors in the impact factor cache queue will be cleared. If the risk classification adjustment value is not less than the set risk classification adjustment limit value, the difference between the risk classification adjustment value and the risk classification adjustment limit value is compared in the risk classification limit value data table to obtain the corresponding risk classification impact limit adjustment amount, so as to dynamically correct the risk classification impact limit value.

9. An ERP cross-module high-risk operation identification and hierarchical handling system, employing the ERP cross-module high-risk operation identification and hierarchical handling method as described in any one of claims 1-8, characterized in that, The system include: Among them, the high-risk operation identification and optimization module is used to collect and uniformly encode the business logs and interface calls of each ERP module, and at the same time, to conduct an adaptability assessment of the business log granularity to determine whether to take corresponding log granularity adjustment, thereby reducing the impact of log granularity on high-risk operation identification. The risk level classification optimization module is used to identify scenarios and score risks of cross-module related operations through rule engine and anomaly detection, and at the same time decide whether to dynamically optimize the risk classification threshold to improve the accuracy of identifying and classifying high-risk operations. The tiered handling and alarm module is used to trigger the corresponding tiered handling process based on the classified risk level, and to perform linked alarms and work order closure.

10. An ERP cross-module high-risk operation identification and classification handling device, the device being used to implement the ERP cross-module high-risk operation identification and classification handling method as described in any one of claims 1-8, characterized in that, The device includes: a data acquisition layer device, a risk identification and analysis layer device, and a risk classification and handling layer device; The data acquisition layer device is used to collect user operation logs, approval logs and system events from each ERP module in real time. The main devices include a log acquisition server, an ERP interface acquisition gateway and a data proxy node. The risk identification and analysis layer equipment is used to perform rule matching and correlation analysis, support machine learning algorithms, and realize cross-module operation chain tracking. The main equipment includes a rule engine server, a risk control model calculation server, and data analysis nodes. The risk classification and handling layer equipment is used to classify events according to risk scores, business rules, and threshold settings, and supports dynamic threshold adjustment. The main equipment includes a risk classification engine host, an automatic handling server, and a rule management console.

Images