Full-process performance data management method based on big data

Abstract

The invention relates to the technical field of big data management, in particular to a whole-process performance data management method based on big data. The specific implementation process comprises the steps of obtaining heterogeneous behavior traces, deconstructing and packaging the heterogeneous behavior traces into space-time cross-domain data streams, and inputting the space-time cross-domain data streams into a distributed cooperative monitoring model; an asynchronous pause frequency and a cross-domain retrieval track are extracted, a cooperative friction coefficient is calculated, and a cooperative retardation degree is generated; inputting the collaborative friction coefficient and the collaborative retardation degree into a performance evolution engine, generating a targeted dynamic weight, and outputting a targeted collaborative performance report; and outputting a resource intervention instruction when the cooperative retardation degree change slope exceeds a preset warning threshold. According to the method, real-time unified access of multi-source heterogeneous process data, continuous association modeling of cross-system behavior tracks, detection of flow blocking nodes and online dynamic updating of evaluation weights are realized by utilizing a distributed collaborative monitoring model and a performance evolution engine, so that the association processing delay of the cross-system data is reduced; and the timeliness and accuracy of flow anomaly detection are improved.

Description

Technical Field

[0001] This invention relates to the field of big data management technology, specifically a method for full-process performance data management based on big data. Background Technology

[0002] With the deepening of digital transformation across industries, the daily operations and personnel supervision of enterprises and large organizations have become highly dependent on various information systems. Performance data management, as a crucial branch of data processing technology specifically designed for management and supervision purposes, directly determines an organization's resource allocation, process optimization, and operational efficiency. In existing performance data processing and evaluation systems, the commonly used technical solution involves: collecting underlying data through various independent business workflow systems (such as attendance management systems, business approval systems, and financial settlement systems), periodically exporting node-specific and result-specific structured data at the end of each cycle; subsequently, based on static performance indicators and fixed weight ratios, periodically calculating and summarizing the extracted single-dimensional result data, ultimately generating static data reports for administrative management and supervision.

[0003] However, existing technologies have inherent limitations in practical applications. Data acquisition typically focuses on the discrete capture of the final business outcome, fragmenting continuous process data such as the timeliness of task flow, collaborative response speed, and anomaly handling trajectories throughout the entire lifecycle. The entire business lifecycle inevitably generates massive amounts of semi-structured or unstructured multimodal data, such as system interaction logs and process records. Due to a lack of deep big data processing architecture and heterogeneous data fusion mechanisms, existing technologies can only rely on easily extracted surface-level structured values, resulting in a large amount of implicit feature data with management value being idle and wasted. The static weight allocation strategy cannot perceive and adaptively adjust to business variables such as sudden changes in the external environment and fluctuations in task complexity in real time. This passive and lagging data processing and post-event statistical model prevents the system from providing timely risk warnings and dynamic scheduling during the business flow process.

[0004] In summary, existing technologies suffer from the following technical bottlenecks at the data processing level: each independent business system uses heterogeneous data protocols and field formats, lacking a unified access and cross-system entity association mechanism, resulting in the inability to continuously model cross-system behavioral trajectories; the existing batch processing architecture has a periodic lag in collecting response time differences between process nodes, making it impossible to achieve real-time detection and accurate location of process blockage events; and the weight parameters used for evaluation calculation cannot be updated online based on real-time system monitoring data during runtime, resulting in evaluation calculation results that do not reflect the current process status.

[0005] To address this, a big data-based end-to-end performance data management method is proposed. Summary of the Invention

[0006] The purpose of this invention is to provide a big data-based end-to-end performance data management method for managing performance data throughout the entire process.

[0007] To achieve the above objectives, the present invention provides the following technical solution: A big data-based end-to-end performance data management approach includes: Obtain heterogeneous behavioral traces from R&D workstations, cleanroom sensor terminals, and performance approval networks; deconstruct and encapsulate the heterogeneous behavioral traces into a spatiotemporal cross-domain data stream and input it into a distributed collaborative monitoring model. The distributed collaborative monitoring model extracts the frequency of asynchronous pauses and the cross-domain retrieval trajectory during the cross-departmental iteration process based on the spatiotemporal cross-domain data stream; it calculates the collaborative friction coefficient, which characterizes the data processing overhead of inter-departmental collaboration, based on the frequency of asynchronous pauses and the cross-domain retrieval trajectory; and generates a collaborative obstruction degree based on the cascading delay data caused by process obstruction nodes. The collaborative friction coefficient and collaborative hindrance are input into the performance evolution engine. Based on the real-time quantified friction resistance and collaborative consumption, a targeted dynamic weight for performance evaluation correction is adaptively generated. The targeted dynamic weight is received and multi-dimensionally fused with the achievement rate of explicit nodes in the spatiotemporal cross-domain data stream to output a targeted collaborative performance report. When it is determined that the slope of the change in the collaborative obstruction exceeds a preset warning threshold, a resource intervention command pointing to the process obstruction node is output to the management terminal.

[0008] Preferably, the specific implementation process of acquiring heterogeneous behavioral traces output from R&D workstations, cleanroom sensor terminals, and performance approval networks, deconstructing and encapsulating these heterogeneous behavioral traces into a spatiotemporal cross-domain data stream, and inputting it into a distributed collaborative monitoring model includes: An initial behavior trace set is constructed by collecting the interaction logs of the R&D workstation, the positioning trajectory of the cleanroom sensor terminal, and the flow records of the performance approval network. A protocol parsing operator is invoked to strip data from the initial behavior trace set, extracting metadata features containing timestamps and operation types. A cross-domain mapping space is established to standardize and transform the metadata features to eliminate modal differences. A graph network is used to link and encapsulate the transformed metadata features according to temporal associations, forming a spatiotemporal cross-domain data stream containing context nodes. A secure channel is established to encrypt and slice the spatiotemporal cross-domain data stream and inject it into the distributed collaborative monitoring model for real-time analysis via streaming.

[0009] Preferably, the specific implementation process of the distributed collaborative monitoring model extracting the asynchronous pause frequency and cross-domain retrieval trajectory during the cross-departmental iteration process based on the spatiotemporal cross-domain data stream includes: The time-series parsing operator within the distributed collaborative monitoring model is activated. This model is deployed based on a streaming computing framework and employs a master-slave architecture with a master node and worker nodes. The master node is responsible for receiving and distributing spatiotemporal cross-domain data streams, while each worker node receives and processes corresponding data shards in parallel according to their source from the business system. The time-series parsing operator is implemented as a state machine, internally maintaining a hash table with task numbers as keys and ordered event queues as values. It performs a sliding window of a preset time length to capture the received spatiotemporal cross-domain data stream, identifying cross-departmental flow nodes within the window. The response time difference is compared with a preset flow threshold. Delayed events exceeding the preset flow threshold are marked as asynchronous pauses and globally accumulated to generate the asynchronous pause frequency, which represents the waiting time. The cross-domain addressing tracking operator is activated synchronously, and the query node with cross-department attributes in the spatiotemporal cross-domain data stream is identified by parsing the database access identifier field in the metadata features. The access path of the query node between different databases is tracked and concatenated in the order of occurrence to form the cross-domain retrieval trajectory. The asynchronous pause frequency and the cross-domain retrieval trajectory are stored in the memory analysis pool as basic features.

[0010] Preferably, the specific implementation process of calculating the collaboration friction coefficient, which characterizes the data processing overhead of inter-departmental collaboration, based on the asynchronous pause frequency and cross-domain retrieval trajectory, and generating the collaboration obstruction degree based on the cascading delay data caused by process blockage nodes, includes: The asynchronous pause frequency is extracted from the memory analysis pool. The asynchronous pause frequency and the number of hops in the cross-domain retrieval trajectory are compressed and then weighted and fused according to a preset weight coefficient to obtain the initial friction coefficient. The proportion of each department that completes the handover task on time in the statistical period is used as the historical collaboration smoothness. The initial friction coefficient is divided by the historical collaboration smoothness to obtain the environment-corrected collaboration friction coefficient. The business topology map of the spatiotemporal cross-domain data flow is scanned to locate the process blockage node that causes continuous stagnation downstream. The cumulative downstream delay time and the number of affected nodes triggered by the process blockage node are collected in real time to form the cascaded delay data. The standard deviation of the delay time of each affected node in the cascaded delay data is calculated, and the standard deviation is used as the collaborative blockage degree to characterize the degree of dispersion of the overall process delay.

[0011] Preferably, the specific implementation process of inputting the cooperative friction coefficient and cooperative resistance degree into the performance evolution engine, and adaptively generating targeted dynamic weights for performance evaluation correction based on real-time quantified friction resistance and cooperative consumption includes: The data receiving interface of the performance evolution engine is constructed to extract the synchronously transmitted collaboration friction coefficient and collaboration stagnation degree. Using the built-in collaboration state mapping matrix, the collaboration friction coefficient is mapped to a friction resistance level value and the collaboration stagnation degree is mapped to a collaboration consumption level value according to a pre-defined piecewise linear mapping rule. The level values ​​are specifically divided into three intervals: low, medium, and high. The boundary thresholds of each interval are determined based on the quantiles of historical business data. Based on the friction resistance level value and the collaboration consumption level value, the adaptive weight allocation algorithm within the engine is activated. When the friction resistance level value and the collaboration consumption level value exceed the preset benchmark level, the weight decay compensation logic is triggered, reducing the result assessment weight by a preset reduction and increasing the process collaboration compensation weight by an equal amount, with the sum of the two always being 1. Based on the processing result, the targeted dynamic weight matching the current environment is output and pushed into the weight update queue.

[0012] Preferably, the specific implementation process of receiving the targeted dynamic weights and performing multi-dimensional fusion processing with the achievement rate of explicit nodes in the spatiotemporal cross-domain data stream to output a targeted collaborative performance report includes: The targeted dynamic weights are extracted from the weight update queue, and the explicit node achievement rates, which represent the business processing results, are structurally extracted from the spatiotemporal cross-domain data stream. A multi-dimensional fusion model is constructed, and the targeted dynamic weights are transformed into an adjustment coefficient matrix. This matrix is ​​then multiplied with the feature vector formed by the explicit node achievement rates to offset the assessment bias caused by a single result-oriented approach. Based on the calculation results, a collaborative performance evaluation score that comprehensively reflects efficiency and the collaborative environment is obtained. According to the management hierarchy, a cross-departmental classification and aggregation operation is performed on the collaborative performance evaluation score. Based on the aggregation results, the front-end rendering component is invoked to generate the targeted collaborative performance report, which includes a time-series evolution curve, a map of obstructing node distribution, and an efficiency ranking.

[0013] Preferably, the specific implementation process of outputting a resource intervention command pointing to the process blockage node to the management terminal when it is determined that the slope of the change in the collaborative obstruction degree exceeds a preset warning threshold includes: A real-time evolution monitoring sequence of the collaborative bottleneck is established and continuously written into a time-series database according to a preset sampling period. A first-order difference algorithm is used to calculate the slope of the collaborative bottleneck in adjacent time periods. When the obtained slope exceeds a preset warning threshold, it is determined that the collaborative bottleneck has increased in the business system. The process bottleneck node that caused the increase is traced upwards, and the resource bottleneck attribute of the process bottleneck node is extracted, which includes the resource utilization rate and personnel load status. Based on the resource bottleneck attribute, a suitable resource tilt allocation and personnel scheduling expansion scheme is matched from a preset strategy library. The matched scheduling scheme is encapsulated into a resource intervention instruction with a standard protocol format and sent to the management terminal through a secure interface to perform resource reallocation scheduling.

[0014] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. By collecting multi-source heterogeneous behavioral traces such as R & D workstation interaction logs, dust-free workshop sensor terminal positioning trajectories, and performance approval network transfer records, and deconstructing and encapsulating them into a unified spatio-temporal cross-domain data stream, the present invention realizes the cross-system, cross-department, and cross-business process data贯通 processing. By introducing a graph network association and standardization conversion mechanism, the process data originally scattered in business systems with different protocol formats is uniformly constructed into a data structure with time series indexing and node association relationships, enabling continuous query and association calculation of cross-system behavior records within the same data model, reducing the processing overhead of cross-system data access and format conversion, and enhancing the unified access ability and data processing efficiency of multi-source heterogeneous data.

[0015] 2. By constructing a distributed collaborative monitoring model, the present invention real-time analyzes the cross-department transfer behaviors in the spatio-temporal cross-domain data stream, extracts collaborative process features such as asynchronous pause frequencies and cross-domain retrieval trajectories, and further generates collaborative friction coefficients and collaborative blockage degree indicators for characterizing department collaboration states. By real-time calculating the cross-department response time difference and cross-database access paths in the streaming data, the process stagnation and information retrieval behaviors are quantified into storable and comparable numerical features, shortening the detection delay of process bottleneck nodes and enhancing the detection ability and positioning ability of process exception events.

[0016] 3. By introducing an adaptive weight allocation mechanism into the performance evolution engine, the present invention converts the collaborative friction coefficient and collaborative blockage degree into frictional resistance and collaborative consumption, and accordingly dynamically generates targeted dynamic weights to real-time adjust the result weights and process weights in performance evaluation. At the same time, when detecting an abnormal jump in the collaborative blockage degree, it automatically triggers a resource intervention instruction to achieve the linkage optimization of resource scheduling and performance data. Through this mechanism, the resource occupancy rate is real-time detected during the operation of the business process and a resource scheduling instruction is automatically triggered, reducing the response delay of resource bottlenecks compared with the periodic batch processing method and enhancing the real-time scheduling ability and data processing accuracy. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 is a flowchart of a full-process performance data management method based on big data proposed by the present invention; Figure 2 is a schematic diagram of a distributed collaborative monitoring model proposed by the present invention; Figure 3 is a schematic diagram of a performance evolution engine proposed by the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0018] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be described in detail below with reference to the accompanying drawings and specific embodiments. It must be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to constitute any limitation on the scope of protection of this invention. Therefore, all equivalent changes or modifications conceived by those skilled in the art based on the content disclosed in this invention without inventive effort should fall within the scope of protection claimed by this invention.

[0019] Reference Figures 1 to 3 This invention provides a method for full-process performance data management based on big data, and the technical solution is as follows:

[0020] Example 1: Reference Figure 1 This embodiment proposes a full-process performance data management method based on big data, including: Obtain heterogeneous behavioral traces from R&D workstations, cleanroom sensor terminals, and performance approval networks; deconstruct and encapsulate the heterogeneous behavioral traces into a spatiotemporal cross-domain data stream and input it into a distributed collaborative monitoring model. The distributed collaborative monitoring model extracts the frequency of asynchronous pauses and the cross-domain retrieval trajectory during the cross-departmental iteration process based on the spatiotemporal cross-domain data stream; it calculates the collaborative friction coefficient, which characterizes the data processing overhead of inter-departmental collaboration, based on the frequency of asynchronous pauses and the cross-domain retrieval trajectory; and generates a collaborative obstruction degree based on the cascading delay data caused by process obstruction nodes. The collaborative friction coefficient and collaborative hindrance are input into the performance evolution engine. Based on the real-time quantified friction resistance and collaborative consumption, a targeted dynamic weight for performance evaluation correction is adaptively generated. The targeted dynamic weight is received and multi-dimensionally fused with the achievement rate of explicit nodes in the spatiotemporal cross-domain data stream to output a targeted collaborative performance report. When it is determined that the slope of the change in the collaborative obstruction exceeds a preset warning threshold, a resource intervention command pointing to the process obstruction node is output to the management terminal.

[0021] Furthermore, the specific implementation process of acquiring heterogeneous behavioral traces output from R&D workstations, cleanroom sensor terminals, and performance approval networks, deconstructing and encapsulating these heterogeneous behavioral traces into a spatiotemporal cross-domain data stream, and inputting it into the distributed collaborative monitoring model includes: An initial behavior trace set is constructed by collecting the interaction logs of the R&D workstation, the positioning trajectory of the cleanroom sensor terminal, and the flow records of the performance approval network. A protocol parsing operator is invoked to strip data from the initial behavior trace set, extracting metadata features containing timestamps and operation types. A cross-domain mapping space is established to standardize and transform the metadata features to eliminate modal differences. A graph network is used to link and encapsulate the transformed metadata features according to temporal associations, forming a spatiotemporal cross-domain data stream containing context nodes. A secure channel is established to encrypt and slice the spatiotemporal cross-domain data stream and inject it into the distributed collaborative monitoring model for real-time analysis via streaming.

[0022] Specifically, a unified data acquisition interface is deployed within the enterprise information environment, connecting to the R&D workstation system, the cleanroom sensor terminal system, and the performance approval network system to continuously collect behavioral data generated during the operation of each system. The R&D workstation records the operational behaviors of R&D personnel in design software, code repositories, and document management systems. Its interaction logs mainly include user identification, software operation type, file read / write behavior, and corresponding timestamps. The cleanroom sensor terminal records the movement trajectories of production personnel between different workstations and their equipment operation behaviors through indoor positioning tags and production equipment status acquisition modules. Its positioning trajectory data includes workstation number, personnel tag number, equipment trigger event, and collection time stamp. The performance approval network records the status changes of process nodes such as task approval, work order circulation, and performance confirmation within the organization. Its circulation records include approval node identifier, task number, approval action, and node completion time. By using a unified data collection agent, the above data is fed into the data access layer in real time. In a preferred embodiment, each R&D workstation generates an average of about 10,000 interaction log records per day, each cleanroom positioning terminal generates about 50,000 personnel trajectory records per day, and the performance approval network generates about 3,000 process node records per day, thereby forming an initial behavioral trace set containing multi-source behavioral data.

[0023] After obtaining the initial set of behavioral traces, a protocol parsing operator is invoked to perform structural stripping on the data. The protocol parsing operator identifies data formats from different sources using a predefined log parsing rule base and extracts unified metadata features from the original log text, sensor terminal messages, and approval system records. These metadata features include at least a timestamp field, an operation subject identifier, an operation behavior type, and an action source system identifier, thereby transforming the originally structurally diverse multimodal data into a metadata set with a unified semantic structure. For example, when a developer submits code in the design system at 9:35 AM, the system extracts the time stamp, user identifier, and operation type from the log; when the same person enters the packaging and testing station in the cleanroom at 9:45 AM, the system extracts the personnel tag number, station number, and time information from the positioning terminal data; when the person completes the work order approval at 10:05 AM, the system extracts the approval node identifier and approval action from the approval network records. Through the processing of the protocol parsing operator, the above three types of data are uniformly converted into metadata feature records with time and behavioral attributes.

[0024] Subsequently, a cross-domain mapping space is established to standardize and transform the metadata features, eliminating data modal differences between different systems. This cross-domain mapping space establishes unified field semantic mapping relationships at the data structure level. For example, user IDs, workshop location tag numbers, and account numbers in the R&D system are uniformly mapped to personnel entity identifiers, and software operation behaviors, equipment operation behaviors, and approval behaviors are uniformly categorized as operation event types. Through this mapping mechanism, data from different systems can be aligned within the same data semantic framework.

[0025] After standardization, a graph network is used to construct temporal associations for the transformed metadata features, linking and encapsulating each behavioral event in chronological order to form a spatiotemporal cross-domain data stream containing contextual relationships. The graph network establishes association edges between behavioral nodes, enabling the continuous recording of the behavioral trajectories of the same person across different business systems. For example, R&D operation nodes and workshop operation nodes are associated through personnel identifiers, while approval operation nodes are associated through task numbers. This method generates dynamic data links containing behavioral context information, transforming business processes from discrete system records into continuous process trajectories. In a preferred embodiment, the system can connect the entire process of a single R&D task, from R&D design and production operation to performance approval, into a complete business trajectory chain. On average, each business trajectory contains twenty to thirty consecutive behavioral nodes, thereby improving the traceability of process behavior.

[0026] After generating the spatiotemporal cross-domain data stream, a secure data transmission channel is further established. The data stream is encrypted and sliced, and then transmitted in a streaming manner to the distributed collaborative monitoring model. The secure channel employs a distributed message queue architecture to segment the data stream. Each data slice contains several consecutive behavioral nodes, which are securely encapsulated using an encryption algorithm before being sent to the monitoring model nodes for real-time parsing. In a real-world deployment environment, approximately one to two thousand behavioral data records can be processed per second, continuously providing real-time data input to the distributed collaborative monitoring model through streaming transmission, enabling the model to continuously monitor and analyze collaborative behaviors within the organization.

[0027] This embodiment unifies isolated data that were originally scattered across the R&D, production, and approval systems into a continuous spatiotemporal cross-domain data stream. It can capture personnel behavior trajectories and business process evolution status in real time, thereby accurately identifying delayed links and collaboration paths in the task execution process. This allows cross-system behavior records to be continuously queried and correlated within the same data model, and effectively improves the problems of difficulty in unifying and integrating multi-source heterogeneous data and difficulty in completely recording business process data.

[0028] Furthermore, the specific implementation process of the distributed collaborative monitoring model, based on the spatiotemporal cross-domain data stream, to extract the asynchronous pause frequency and cross-domain retrieval trajectory during the cross-departmental iteration process includes: The time-series parsing operator within the distributed collaborative monitoring model is activated. This model is deployed based on a streaming computing framework and employs a master-slave architecture with a master node and worker nodes. The master node is responsible for receiving and distributing spatiotemporal cross-domain data streams, while each worker node receives and processes corresponding data shards in parallel according to their source from the business system. The time-series parsing operator is implemented as a state machine, internally maintaining a hash table with task numbers as keys and ordered event queues as values. It performs a sliding window of a preset time length to capture the received spatiotemporal cross-domain data stream, identifying cross-departmental flow nodes within the window. The response time difference is compared with a preset flow threshold. Delayed events exceeding the preset flow threshold are marked as asynchronous pauses and globally accumulated to generate the asynchronous pause frequency, which represents the waiting time. The cross-domain addressing tracking operator is activated synchronously, and the query node with cross-department attributes in the spatiotemporal cross-domain data stream is identified by parsing the database access identifier field in the metadata features. The access path of the query node between different databases is tracked and concatenated in the order of occurrence to form the cross-domain retrieval trajectory. The asynchronous pause frequency and the cross-domain retrieval trajectory are stored in the memory analysis pool as basic features.

[0029] Reference Figure 2Specifically, the distributed collaborative monitoring model uses the core computing server of the enterprise data center as the master control node, and configures two worker node servers each in the R&D collaboration domain, production execution domain, and administrative approval domain, forming a seven-node master-slave architecture with one master and six slaves. The master control node continuously monitors the spatiotemporal cross-domain data stream pushed by the upstream secure channel through its built-in data routing module. Based on the source system identifier field carried in each data record, it distributes data fragments from the R&D workstation to the R&D domain worker node queue, data fragments from the cleanroom sensor terminal to the production execution domain worker node queue, and data fragments from the performance approval network to the administrative approval domain worker node queue. Each worker node independently and in parallel processes the data fragments it receives and then reports the intermediate calculation results to the master control node for unified aggregation. In the enterprise deployment environment, the system receives approximately 1,800 behavioral event records per second during peak business hours. Compared to a single-node serial processing architecture, the master-slave distributed architecture reduces the processing time for a single full data scan from approximately 900 milliseconds to approximately 150 milliseconds, increasing data processing throughput by about six times, thereby meeting the latency requirements for real-time detection of cross-departmental workflow behavior.

[0030] The time-series parsing operator runs independently on each worker node in the form of a finite state machine. Internally, it maintains an in-memory hash table with task number as the hash key and ordered event queues arranged in ascending order of timestamps as the hash values. This hash table continuously receives behavioral events associated with the task number from the data stream throughout the task's lifecycle and inserts newly arriving events into the correct position in the corresponding queue according to the event's timestamp, ensuring that events in the queue always maintain a strict chronological order. The time-series parsing operator dynamically captures the input data stream using a sliding window with a time span of thirty minutes. The window step is set to five minutes, meaning the window scrolls forward once every five minutes, scanning all event pairs involving cross-departmental transfers within the current window. It identifies the absolute time interval between the preceding department's submission of an operation event and the subsequent department's first response operation event under the same task number, and records this time interval as the cross-departmental transfer response time difference. In the actual operating parameters of the enterprise, the preset flow thresholds are determined based on the 85th percentile of the historical response times of each flow link over the past six months. The flow threshold from the R&D department to the testing department is set at 45 minutes, from the testing department to the quality approval department at 60 minutes, and from the quality approval department to the shipping department at 30 minutes. The timing parsing operator marks flow events where the actual response time difference exceeds the preset flow threshold of the corresponding link as an asynchronous pause, and performs an atomic increment operation in the global accumulator counter maintained on the master node to ensure that no data race occurs when multiple working nodes perform concurrent statistics. During a complete 90-day operating cycle in a certain quarter, the system identified and marked a total of 214 asynchronous pause events across three main cross-departmental workflows. Approximately 53% of these events occurred in the R&D to testing workflow, approximately 31% in the testing to quality approval workflow, and approximately 16% in the quality approval to shipment workflow. The resulting asynchronous pause frequency of 214 events, representing the severity of cross-departmental waiting time during the current statistical period, was written to the memory analysis pool as a real-time streaming computation result with a millisecond delay for subsequent use.

[0031] While the timing parsing operator completes the above processing, the cross-domain addressing tracing operator is simultaneously activated and runs on the same group of working nodes. The cross-domain addressing tracing operator continuously identifies query nodes with cross-departmental attributes by parsing the database access identifier field in each data stream record. The database access identifier field contains three core pieces of information: the target database system name, the database department identifier, and the query initiation timestamp. When the cross-domain addressing tracing operator detects consecutive query records with inconsistent target database department identifiers within a ten-minute sliding time window under the same user identifier, it identifies the relevant query nodes as cross-domain query nodes and marks them. The cross-domain addressing tracing operator then tracks the network access jump paths of the marked cross-domain query nodes between different database systems, concatenating them into a directed path sequence based on the order of their occurrence timestamps. This sequence is the cross-domain retrieval trajectory, and the number of database system switches occurring in this trajectory is counted as the hop count and appended to the trajectory record. In a preferred embodiment, during a 90-day monitoring period, when the system tracks cross-domain retrieval behavior between R&D personnel and testing personnel, the target databases involved are mainly concentrated in four types of business databases: material specification database, testing standard database, supplier qualification database, and cost accounting database. The average number of hops for a single cross-domain retrieval trajectory is 3.2, and the peak number of hops for the entire system within a single statistical day reaches 108, with the peak occurring during the task handover peak period from 9:00 AM to 11:00 AM. After completing the above trajectory concatenation, the cross-domain addressing tracking operator synchronously writes the asynchronous pause frequency generated within the current statistical period and the cross-domain retrieval trajectory into a high-speed analysis pool deployed in the memory of the master control node in a key-value pair structure.

[0032] This embodiment utilizes a distributed master-slave architecture with parallel computing mechanisms and a sliding window state machine for streaming processing logic, enabling abnormal process pauses to be captured and quantified within a single sampling window period after they occur. Simultaneously, by employing a cross-domain addressing tracing operator to fully reconstruct the cross-database retrieval path, it transforms information retrieval behaviors, originally scattered across access logs of various business databases, into computable features with a topological structure, providing a data foundation for subsequent collaborative friction quantification.

[0033] Furthermore, the collaboration friction coefficient, which characterizes the data processing overhead of inter-departmental collaboration, is calculated based on the frequency of asynchronous pauses and the cross-domain retrieval trajectory. Simultaneously, the specific implementation process for generating the collaboration obstruction degree based on the cascading delay data caused by process bottleneck nodes includes: The asynchronous pause frequency is extracted from the memory analysis pool. The asynchronous pause frequency and the number of hops in the cross-domain retrieval trajectory are compressed and then weighted and fused according to a preset weight coefficient to obtain the initial friction coefficient. The proportion of each department that completes the handover task on time in the statistical period is used as the historical collaboration smoothness. The initial friction coefficient is divided by the historical collaboration smoothness to obtain the environment-corrected collaboration friction coefficient. The business topology map of the spatiotemporal cross-domain data flow is scanned to locate the process blockage node that causes continuous stagnation downstream. The cumulative downstream delay time and the number of affected nodes triggered by the process blockage node are collected in real time to form the cascaded delay data. The standard deviation of the delay time of each affected node in the cascaded delay data is calculated, and the standard deviation is used as the collaborative blockage degree to characterize the degree of dispersion of the overall process delay.

[0034] Specifically, the asynchronous pause frequencies accumulated within the current statistical period are extracted from the memory analysis pool, and the total number of hops statistically obtained from the cross-domain retrieval trajectory records is read synchronously. Due to the significant differences in the magnitude of the original numerical values ​​generated by statistical periods of different department sizes and task densities, directly weighting and fusing the original values ​​would cause excessive interference from extremely high-frequency abnormal data, leading to drastic fluctuations in the collaboration friction coefficient during normal business cycles. Therefore, logarithmic compression is performed on the asynchronous pause frequencies and the total number of hops respectively. This involves adding one to each value and taking the logarithm to the base of the natural constant to obtain the pause compression value and the retrieval compression value. The addition operation prevents the logarithmic operation from being meaningless when the original value is zero. The preset weighting coefficient sets the fusion weight of the pause compression value to 0.6 and the fusion weight of the retrieval compression value to 0.4. The two compression values ​​are then weighted and summed according to this ratio, and the result is the initial friction coefficient. In a preferred embodiment, the asynchronous pause frequency of the day is read from the memory analysis pool as seven times and the total number of cross-domain retrieval trajectory jumps is nineteen times. The pause compression value is approximately 2.08 after adding one to the pause frequency and taking the natural logarithm of the total number of jumps. The retrieval compression value is approximately 2.99 after adding one to the total number of jumps and taking the natural logarithm of the total number of jumps. The initial friction coefficient is approximately 2.45 after being fused with weights of 0.6 and 0.4.

[0035] After obtaining the initial friction coefficient, it is necessary to eliminate the bias in the current friction coefficient assessment caused by differences in historical collaboration foundations among different departments. The historical collaboration smoothness is defined as the ratio of the number of times each department completes cross-departmental handover tasks on time within a past complete statistical period to the total number of handover tasks that should be completed. The value ranges from greater than zero to one, and this ratio is automatically updated by the system at the beginning of each new statistical period. The initial friction coefficient is divided by the historical collaboration smoothness of the corresponding department to obtain the collaboration friction coefficient after historical collaboration environment correction. When the historical collaboration smoothness of any department falls below 0.1 in an extreme case within a certain statistical period, 0.1 is automatically used as a substitute value in the division operation, thereby controlling the upper limit of the collaboration friction coefficient to within ten times the initial friction coefficient, preventing the divisor from approaching zero and causing numerical overflow or system calculation anomalies, and ensuring that the collaboration friction coefficient is within a stable range that can be stored and compared under any business scenario.

[0036] Simultaneously with the generation of the cooperative friction coefficient, a real-time location process for process bottleneck nodes is initiated. The business topology graph, continuously mapped and maintained by the spatiotemporal cross-domain data flow, is scanned. This topology graph uses each business operation node as a vertex and the transit dependencies between nodes as directed edges, reflecting the current topology state of the business flow network in real time. The real-time status markers of all nodes in the business topology graph are traversed. When a node is in an incomplete state and two or more directly downstream nodes are continuously in a stagnant waiting state due to waiting for the node's output, that node is marked as the process bottleneck node for the current period. In a preferred embodiment, after scanning the business topology graph, if an incoming material inspection node is detected to be in an incomplete state for a long time, and its directly downstream welding process node, packaging process node, and aging test process node are simultaneously in a stagnant waiting state, and the stagnant duration exceeds the preset flow threshold of their respective links, the incoming material inspection node is marked as the process bottleneck node for the current period. The processing time from the start of topology graph traversal to the completion of marking is approximately twenty-three milliseconds.

[0037] After locating the process bottleneck node, real-time collection of downstream cascading delay data caused by that node is immediately initiated. All directed paths originating from the process bottleneck node in the business topology are traced downstream layer by layer. The difference between the planned completion time of each affected node and the actual current time is recorded as the delay duration of that node. Simultaneously, the total number of affected nodes is counted. The above delay duration sequence and the total number of affected nodes together constitute the cascading delay data and are written into the cache. In the aforementioned incoming material inspection node bottleneck event, tracing down the topology reveals that a total of eighteen downstream process nodes are affected, including five welding process nodes, seven packaging process nodes, four aging test process nodes, and two appearance inspection process nodes that directly depend on the incoming material inspection results. The delay duration values ​​of these eighteen affected nodes are collected in real time. The delay duration of each node ranges from 1.2 hours to 7.8 hours, with an average delay duration of approximately 4.3 hours.

[0038] After acquiring the cascaded delay data, a numerical sequence of delay durations for each affected node is extracted. The arithmetic mean of the sum of squares of the deviations of all elements in the sequence from the sequence mean is calculated. The square root of this mean is then taken to obtain the standard deviation of the delay duration in hours. This standard deviation is used as the output of the collaborative obstruction degree, characterizing the overall dispersion of delays in the process within the current statistical period. In the aforementioned incoming material inspection node obstruction scenario, the calculated standard deviation of the delay duration sequence for the eighteen affected nodes is approximately 1.87 hours, meaning the collaborative obstruction degree at the current statistical moment is 1.87. The collaborative obstruction degree measures the process obstruction state by the dispersion of delay durations rather than the total delay, distinguishing between two distinct obstruction patterns: uniform delay distribution and high concentration of delays at a few nodes. When the number of affected nodes is less than three, the standard deviation may have a large statistical error due to insufficient sample size. In this case, the product of the number of affected nodes and the average delay time of each node is used as the alternative calculation result of the cooperative hindering degree to ensure that the indicator is still calculable and numerically stable under small-scale hindering events. After the cooperative hindering degree is calculated, it is stored in a dedicated cache channel along with the cooperative friction coefficient in the form of key-value pairs for subsequent synchronous reading by the performance evolution engine.

[0039] This embodiment employs a dual processing mechanism of logarithmic compression and historical smoothness correction to transform the original asynchronous pause frequency and cross-domain retrieval hop count into a collaborative friction coefficient capable of horizontal comparison across statistical periods and departmental scales, eliminating evaluation distortions caused by differences in data volume between departments with different business volumes. Through real-time topology localization of process bottleneck nodes and quantification of the standard deviation of cascading delays, the process stagnation state is transformed into a collaborative bottleneck index with clearly defined numerical boundaries, achieving continuous real-time perception of the business process's operational status.

[0040] Furthermore, the specific implementation process of inputting the cooperative friction coefficient and cooperative resistance into the performance evolution engine, and adaptively generating targeted dynamic weights for performance evaluation correction based on the real-time quantified frictional resistance and cooperative consumption, includes: The data receiving interface of the performance evolution engine is constructed to extract the synchronously transmitted collaboration friction coefficient and collaboration stagnation degree. Using the built-in collaboration state mapping matrix, the collaboration friction coefficient is mapped to a friction resistance level value and the collaboration stagnation degree is mapped to a collaboration consumption level value according to a pre-defined piecewise linear mapping rule. The level values ​​are specifically divided into three intervals: low, medium, and high. The boundary thresholds of each interval are determined based on the quantiles of historical business data. Based on the friction resistance level value and the collaboration consumption level value, the adaptive weight allocation algorithm within the engine is activated. When the friction resistance level value and the collaboration consumption level value exceed the preset benchmark level, the weight decay compensation logic is triggered, reducing the result assessment weight by a preset reduction and increasing the process collaboration compensation weight by an equal amount, with the sum of the two always being 1. Based on the processing result, the targeted dynamic weight matching the current environment is output and pushed into the weight update queue.

[0041] Reference Figure 3 Specifically, the performance evolution engine establishes a persistent subscription connection with the upstream cache channel through a dedicated data receiving interface, continuously monitoring the cache channel for newly written indicator data at a polling interval of no more than 500 milliseconds. Whenever the collaboration friction coefficient and collaboration resistance coefficient are updated and written to the cache channel, the performance evolution engine's data receiving interface immediately triggers a read operation, extracting the two indicator values ​​into the engine's internal working memory and attaching a corresponding sampling timestamp to this extraction operation. This ensures that subsequent weight generation results correspond one-to-one with the sampling time, avoiding the mixing of indicator values ​​from different times in the same weight calculation due to asynchronous delays.

[0042] After extracting the indicators, the performance evolution engine calls the built-in collaborative state mapping matrix to perform independent piecewise linear mapping operations on the collaborative friction coefficient and the collaborative hindrance, converting the two continuous values ​​into corresponding discrete level identifiers. The collaborative state mapping matrix is ​​a pre-calibrated two-dimensional mapping rule table. The mapping rules for the collaborative friction coefficient dimension divide the numerical space into three level intervals: low, medium, and high. The collaborative hindrance dimension is independently mapped to the collaborative consumption level according to the same three-level structure. The boundary thresholds for each level are determined based on the percentile statistics of the enterprise's historical business data for the most recent three complete natural months. The boundary between the low and medium levels is taken as the 25th percentile of the historical data, and the boundary between the medium and high levels is taken as the 75th percentile of the historical data. At the beginning of each month, the system automatically recalculates the boundary thresholds with the continuously updated historical data to ensure that the mapping rules are always dynamically adapted to the enterprise's current business scale and collaborative state benchmark. In a preferred embodiment, the low-to-medium boundary threshold of the cooperative friction coefficient is determined to be 1.8 after three months of historical data statistics, and the medium-to-high boundary threshold is determined to be 3.0; the low-to-medium boundary threshold of the cooperative resistance is determined to be 1.2 hours, and the medium-to-high boundary threshold is determined to be 2.5 hours. Taking the cooperative friction coefficient of 3.14 on the 47th statistical day as an example, this value exceeds the medium-to-high boundary threshold of 3.0, and is mapped to high-level frictional resistance; the cooperative resistance of 1.87 hours is between the low-to-medium boundary of 1.2 and the medium-to-high boundary of 2.5, and is mapped to medium-level cooperative consumption.

[0043] After completing the level mapping, the performance evolution engine activates the internal adaptive weight allocation algorithm based on the obtained friction resistance level value and collaborative consumption level value, entering the weight calculation process. The adaptive weight allocation algorithm uses result assessment weight and process collaboration compensation weight as a pair of complementary adjustment targets, always forcibly ensuring that their sum equals one during operation to ensure complete coverage of performance evaluation dimensions. The initial result assessment weight is set to 0.7 and the process collaboration compensation weight to 0.3. This initial ratio is determined based on the company's historical performance evaluation practices and represents the standard weight configuration under conditions of completely smooth business flow and no external resistance interference.

[0044] The weight attenuation compensation logic is triggered immediately when the friction resistance level or collaborative consumption level exceeds the preset benchmark level (i.e., low level). It reduces the result assessment weight according to a pre-set stepped reduction, and then adds an equal reduction to the process collaboration compensation weight. The specific reduction rules are as follows: when the friction resistance level is medium, the result assessment weight is reduced by 0.1 from the current value; when the friction resistance level is high, the result assessment weight is reduced by 0.2 from the current value. The impact of the collaborative consumption level is calculated independently in an additive manner. When the collaborative consumption level is medium, the result assessment weight is additionally reduced by 0.05; when the collaborative consumption level is high, it is additionally reduced by 0.1. After the reductions in both dimensions are superimposed, the system performs a lower limit protection check. If the superimposed result assessment weight is lower than 0.3, the result assessment weight is forcibly fixed at 0.3, and the process collaboration compensation weight is calculated accordingly to 0.7, to prevent the assessment weight of the result dimension from being excessively compressed to the point of losing its reference value in extreme obstruction scenarios. Taking the combination of advanced frictional resistance and intermediate collaborative consumption on the 47th statistical day above as an example, based on the initial result assessment weight of 0.7, the weight is reduced by 0.2 due to the advanced frictional resistance trigger and by 0.05 due to the additional trigger of intermediate collaborative consumption, for a total reduction of 0.25. The adjusted result assessment weight is 0.45, and the process collaboration compensation weight is adjusted accordingly to 0.55. After verification by the lower limit protection, 0.45 is confirmed to be higher than the lower limit of 0.3, and the adjustment result is valid. If, during the same period, a department experiences an extreme scenario where advanced frictional resistance is superimposed with advanced collaborative consumption, the total reduction of the two weights reaches 0.3. The adjusted result assessment weight will then reach the lower limit of 0.3, and will be forcibly fixed at 0.3, with the output process collaboration compensation weight at 0.7, preventing weight inversion from causing confusion in the assessment logic. This rule reduces the update frequency of the weight update queue to once per sampling period, instead of once per statistical period in batch processing mode, thereby reducing the computational overhead of online updates to assessment parameters.

[0045] After the adaptive weight allocation algorithm completes the calculation, the resulting assessment weight and the process collaboration compensation weight are combined and encapsulated into a single targeted dynamic weight record. This record, along with a sampling timestamp and corresponding department identifier, is then pushed into the weight update queue in a first-in, first-out (FIFO) order. The weight update queue is deployed in memory using a circular buffer structure. The queue capacity is set to the weight records for the most recent one hundred statistical periods. When a new record is added, if the queue is full, the oldest record is automatically overwritten. This ensures that the latest weights are available promptly while maintaining limited historical weight traceability.

[0046] This embodiment utilizes the synergistic effect of a piecewise linear mapping matrix and a step-wise weight decay compensation logic to transform continuously changing collaboration friction coefficients and collaboration hindrance degrees into discrete levels with clear business semantics. These levels are then mapped to precise and reproducible weight adjustment quantities, enabling the weight parameters to be dynamically adjusted online with each sampling period as the smallest update granularity. Simultaneously, a lower limit protection mechanism ensures that the weight adjustment always remains within reasonable boundaries, preventing extreme data from distorting the evaluation results. This achieves automatic linkage between performance evaluation parameters and real-time business flow data.

[0047] Furthermore, the specific implementation process of receiving the targeted dynamic weights and performing multi-dimensional fusion processing with the achievement rate of explicit nodes in the spatiotemporal cross-domain data stream to output a targeted collaborative performance report includes: The targeted dynamic weights are extracted from the weight update queue, and the explicit node achievement rates, which represent the business processing results, are structurally extracted from the spatiotemporal cross-domain data stream. A multi-dimensional fusion model is constructed, and the targeted dynamic weights are transformed into an adjustment coefficient matrix. This matrix is ​​then multiplied with the feature vector formed by the explicit node achievement rates to offset the assessment bias caused by a single result-oriented approach. Based on the calculation results, a collaborative performance evaluation score that comprehensively reflects efficiency and the collaborative environment is obtained. According to the management hierarchy, a cross-departmental classification and aggregation operation is performed on the collaborative performance evaluation score. Based on the aggregation results, the front-end rendering component is invoked to generate the targeted collaborative performance report, which includes a time-series evolution curve, a map of obstructing node distribution, and an efficiency ranking.

[0048] Specifically, the currently valid target dynamic weight record is extracted from the head of the weight update queue in a first-in-first-out order. The result assessment weight and process collaboration compensation weight values ​​and the corresponding sampling timestamp are read from the record. The interval between the timestamp and the current time is checked to see if it is within two sampling periods. If it is, the weight record is determined to be expired, and the record is automatically skipped and the next valid record in the queue is read. This ensures that the target dynamic weight participating in the fusion calculation is always matched with the current business flow status.

[0049] While extracting the targeted dynamic weights, a structured stripping operation is performed on the spatiotemporal cross-domain data stream to extract the explicit node achievement rate, which represents the business processing results of each personnel entity within the current evaluation period. The explicit node achievement rate is calculated by weighted average of the following three sub-scores: The first sub-score is the timeliness achievement sub-score, which is based on the ratio of the actual task completion time to the corresponding task's specified time limit. When the actual completion time does not exceed the specified time limit, the timeliness sub-score is set to a full score of 1.0. Thereafter, for every 10% exceeding the specified time limit, the sub-score is reduced by 0.1, with a lower limit of 0.0 for the timeliness sub-score; The second sub-score is the quality score sub-score, which is the normalized result of the ratio of the task quality score recorded by the acceptance party in the business system to the full score of that type of task; The third sub-score is the task pass rate sub-score, which is the ratio of the number of business nodes that actually pass acceptance within the current evaluation period to the total number of business nodes that should have been accepted. The explicit node achievement rate is weighted and averaged at fixed ratios of 0.4, 0.3, and 0.3 for the timeliness achievement sub-score, quality score sub-score, and task pass rate sub-score, respectively. These weighting ratios are determined based on the correlation between the three sub-indicators and the final business output quality in the company's historical data. In a preferred embodiment, the task completion data of a certain engineer in the R&D department for the current month is structurally extracted from the spatiotemporal cross-domain data stream: of the twelve tasks undertaken, nine were completed within the specified time limit, one exceeded the time limit by 20%, and two exceeded the time limit by 10%. The timeliness achievement sub-score is calculated as the full score for nine tasks plus 0.8 for one task plus 0.9 for two tasks, divided by twelve, resulting in a timeliness achievement sub-score of approximately 0.95. The quality score sub-score is normalized to 0.89 after being recorded and summarized by the business system. The task pass rate sub-score is approximately 0.92, calculated by dividing the eleven tasks that passed acceptance by the twelve tasks that should have been completed. After weighting and averaging the three sub-scores at 0.4, 0.3, and 0.3, the explicit node achievement rate is approximately 0.91.

[0050] After obtaining the targeted dynamic weights and the explicit node achievement rates, the multi-dimensional fusion model is constructed to perform weight correction calculations. The multi-dimensional fusion model extends the targeted dynamic weights into an adjustment coefficient matrix, which includes two columns: result assessment dimension adjustment coefficients and process collaboration compensation dimension adjustment coefficients. The corresponding values ​​are taken from the result assessment weights and process collaboration compensation weights in the targeted dynamic weights, respectively. Simultaneously, the explicit node achievement rate is split into result dimension achievement rate and process collaboration dimension achievement rate based on its business origin, forming a two-dimensional feature vector. The result dimension achievement rate is directly taken from the explicit node achievement rate value, while the process collaboration dimension achievement rate is taken as the ratio of the number of times the individual responded on time to the total number of responses at cross-departmental workflow nodes within the current evaluation period, serving as a measure of process collaboration participation. The multi-dimensional fusion model multiplies each column of the adjustment coefficient matrix with the corresponding dimension value of the feature vector and then sums the results to obtain the fused collaborative performance evaluation score. Taking the aforementioned engineer as an example, their achievement rate in the result dimension is 0.91, and the achievement rate in the process collaboration dimension is statistically 0.83. In the adjustment coefficient matrix, the coefficient for the result assessment dimension is 0.45, and the coefficient for the process collaboration compensation dimension is 0.55. The products of these two are 0.45 multiplied by 0.91 equaling 0.41, and 0.55 multiplied by 0.83 equaling 0.46. The summed collaborative performance evaluation score is approximately 0.87, which translates to approximately 87.0 points on a percentage scale. If a fixed-weight scheme (result assessment weight 0.7, process collaboration weight 0.3) is used to calculate the same engineer's score during the same period, the obtained score would be approximately 0.88, or 88.0 points. The difference between the two is about one point, which is not significant. However, this difference was fully demonstrated in another engineer in the same department: this engineer's achievement rate in the result dimension was only 0.74% in the same statistical period, but the achievement rate in the process collaboration dimension was as high as 0.96%. This indicates that he actively participated in collaborative response under a highly externally resistant environment, but the final task result was dragged down by objective obstacles. Under the fixed weight scheme, his percentage score was about 74.6 points, while under the fusion calculation after the target dynamic weight correction, his score was about 86.1 points, a difference of about 11.5 points. This fully demonstrates the effective offsetting effect of the multi-dimensional fusion model on the resistance of the external collaborative environment.

[0051] After calculating the individual collaborative performance evaluation scores for each employee, the system performs cross-departmental categorized aggregation calculations on the scores of all employees based on the company's pre-configured management hierarchy. This management hierarchy is stored in a system configuration table using department numbers and hierarchical relationships. After reading this configuration table, the system aggregates the collaborative performance evaluation scores of all members in each of the four primary departments—R&D, Testing, Quality Approval, and Production—for the current evaluation period. It then calculates three aggregated statistics for each department: average score, highest score, and lowest score. Furthermore, it calculates the difference between the average score of each department and the average score of the previous statistical period, generating a month-on-month change. Once the aggregated data is written to the report generation buffer, the system immediately triggers a call to the front-end rendering component.

[0052] The front-end rendering component generates the targeted collaborative performance report containing three types of views based on the aggregation results in the buffer. The first type of view is a time-series evolution curve, which displays the parallel changing trends of the average collaborative performance evaluation score, collaboration friction coefficient, and collaboration obstruction degree of each department over the past twelve statistical periods in the form of a line graph. The horizontal axis is the statistical period time axis, and the left side of the vertical axis is the score scale, and the right side is the indicator value scale. The dual-axis design allows management to intuitively observe the response relationship between the increase in collaboration friction coefficient and the decrease in score. In the actual reports of the above-mentioned enterprises, the time-series evolution curve of the quality approval group clearly shows the positive correlation between the continuous increase in collaboration friction coefficient from the 43rd to the 47th statistical days and the gradual decrease in the average score during the same period. The second type of view is a map of bottleneck nodes, using a business topology map as the base map and overlaying a heatmap rendering layer. The color depth of a node is positively correlated with the cumulative number of times it has been marked as a bottleneck node in the current statistical period. In the company's monthly report, the incoming material inspection node and the quality approval review node are presented in the darkest color, with a cumulative number of bottleneck markings of 14 and 9 times, respectively. The remaining nodes are significantly lighter in color, allowing management to locate high-frequency bottlenecks in the current process system within seconds. The third type of view is an efficiency ranking, displaying the ranking of each department's average collaborative performance evaluation score from highest to lowest using a horizontal bar chart. The right side of each bar is marked with an arrow indicating the increase or decrease compared to the previous period's ranking, along with the actual result assessment weight value used in the current period, indicated in parentheses on the right side of each department's bar. This allows report users to directly perceive the current rebalancing magnitude while viewing the ranking, improving the interpretability of the report conclusions. The targeted collaborative performance report is finally presented on the enterprise management terminal screen via a standardized data push interface with an end-to-end latency of no more than 200 milliseconds. The report refresh frequency is synchronized with the sampling cycle of the performance evolution engine.

[0053] This embodiment utilizes a fusion mechanism of adjusting the coefficient matrix and eigenvector product to precisely encode the differentiated emphasis of targeted dynamic weights on the two dimensions of business results and process collaboration into a computable matrix operation, avoiding errors from single-result-oriented data. Through cross-departmental aggregation and the joint presentation of three types of visualization views, process and result data originally scattered across various business systems are unified into a comprehensive management view with three analytical dimensions: time-series comparison, spatial distribution, and horizontal ranking. This reduces the time spent cross-referencing data across multiple systems and enhances the ability of performance data to support process optimization decisions.

[0054] Furthermore, the specific implementation process of outputting a resource intervention command pointing to the process blockage node to the management terminal when it is determined that the slope of the change in the collaborative obstruction degree exceeds a preset warning threshold includes: A real-time evolution monitoring sequence of the collaborative bottleneck is established and continuously written into a time-series database according to a preset sampling period. A first-order difference algorithm is used to calculate the slope of the collaborative bottleneck in adjacent time periods. When the obtained slope exceeds a preset warning threshold, it is determined that the collaborative bottleneck has increased in the business system. The process bottleneck node that caused the increase is traced upwards, and the resource bottleneck attribute of the process bottleneck node is extracted, which includes the resource utilization rate and personnel load status. Based on the resource bottleneck attribute, a suitable resource tilt allocation and personnel scheduling expansion scheme is matched from a preset strategy library. The matched scheduling scheme is encapsulated into a resource intervention instruction with a standard protocol format and sent to the management terminal through a secure interface to perform resource reallocation scheduling.

[0055] Specifically, after the performance evolution engine completes its initial deployment, a real-time evolution monitoring sequence for the collaborative hindrance is synchronously established. Using a 30-minute preset sampling period, at the end of each sampling period, the latest collaborative hindrance value is read from the upstream cascaded delay calculation module and continuously stored in a dedicated time-series database along with the corresponding sampling period number and sampling completion timestamp. The time-series database adopts a columnar storage structure partitioned by time. Each record contains only three fields: sampling timestamp, the collaborative hindrance value, and the source department identifier. The write time for a single record does not exceed two milliseconds, supporting millisecond-level range queries on historical records from the most recent 48 sampling periods (i.e., the most recent 24 hours) without affecting write throughput.

[0056] After each new round of collaborative stagnation value writing is completed, a first-order difference algorithm is immediately invoked to calculate the slope between the current sampled value and the historical value of the previous sampling period. The first-order difference algorithm reads the collaborative stagnation value of the current sampling period and the collaborative stagnation value of the immediately preceding sampling period from the time-series database, calculates the difference between the two, and divides it by the sampling period time interval of thirty minutes to obtain the slope value in units of collaborative stagnation change per minute. This slope value is compared in real time with a preset warning threshold, which is determined based on the 95th percentile of the historical slope distribution of collaborative stagnation values ​​for each department within the past three months. To avoid false triggers caused by occasional single-period data fluctuations, the system adopts a continuous confirmation mechanism. It requires that the slope values ​​of two consecutive adjacent sampling periods exceed the preset warning threshold before a formal determination is made that a leap in collaborative stagnation has occurred in the business system. Isolated threshold exceedance events in a single period are only recorded in the anomaly log but do not trigger subsequent intervention processes. In a preferred embodiment, the quality approval department's collaborative resistance level is detected to be 1.47 hours at 2:00 PM, rising to 2.59 hours at 2:30 PM, corresponding to a slope of approximately 0.04 hours per minute, exceeding the preset warning threshold of 0.03; the sampling value further rises to 3.81 hours at 3:00 PM, corresponding to a slope of approximately 0.04 hours per minute, exceeding the threshold again. The confirmation condition of exceeding the threshold for two consecutive cycles is met, and a formal determination is made that the collaborative resistance level has surged, and the tracing and intervention process is immediately initiated.

[0057] After the jump determination is established, a directed graph reverse traversal is performed along the business topology graph. Starting from each downstream affected node currently in a stagnant state, the process traces upwards level by level according to the reverse direction of the directed edges to identify the common ancestor node that appears simultaneously on multiple stagnant paths. This common ancestor node is determined as the process stagnant node that triggered the current coordinated stagnation jump. After tracing back along the topology graph, it was found that the stagnant paths of the seven downstream nodes currently in a stagnant state, including the packaging process, aging test, and appearance inspection, all converge to the quality approval review node. This node is confirmed as the source process stagnant node of this jump.

[0058] After locating the process bottleneck node, the system immediately extracts the resource bottleneck attribute of that node synchronously from two data sources: server monitoring and human resource scheduling. The computing resource utilization data from server monitoring reflects a real-time snapshot of the CPU and memory usage of the server currently handling the node's business processes. The personnel load status data from human resource scheduling reflects the backlog of tasks and shift duration for each person currently responsible for processing tasks at that node. These two types of data are aggregated into a single resource bottleneck attribute record, containing three core fields: average server computing resource utilization, average backlog of tasks per person, and average shift duration per person. Based on the combination of computing resource utilization and personnel load status in the resource bottleneck attribute, a matching query is initiated from the pre-set strategy library. The pre-configured strategy library pre-configures five standard response schemes based on the severity of computing resource bottlenecks and personnel load bottlenecks: When computing resource utilization exceeds 85% while personnel load is normal, a single computing resource expansion scheme is matched, dynamically increasing the number of target server threads to 1.5 times the current level; when personnel backlog exceeds the rated limit by 50% while computing resources are normal, a single personnel scheduling scheme is matched, drawing at least one person from the list of qualified standby personnel to coordinate the process; when computing resource utilization exceeds 85% and personnel backlog exceeds the rated limit by 50%, a combined computing resource and personnel expansion scheme is matched, simultaneously executing thread expansion and personnel scheduling operations; when computing resource utilization exceeds 95% or personnel have been working continuously for more than eight hours, an emergency priority joint intervention scheme is matched, adding an immediate alarm notification to the direct management level on the basis of joint expansion; when the coordination bottleneck jumps and continues for more than three consecutive sampling periods and no bottleneck is observed to decrease after the execution of the above four schemes, an escalation reporting scheme is matched, automatically generating a special operational anomaly report and pushing it to a higher management level. In the bottleneck scenario of the quality approval review node on the aforementioned 53rd statistical day, the average computing resource utilization rate of 91% exceeded the 85% benchmark, and the backlog of personnel of 56.3 items per person exceeded the rated limit of 30 items by more than 50%. When both conditions were met, the system matched a joint expansion plan for computing resources and personnel. At the same time, since the CPU utilization rate of 91% exceeded 85% but did not reach the emergency threshold of 95%, and the working hours of the on-duty personnel did not exceed eight hours, the emergency priority upgrade condition was not triggered, and the standard joint expansion plan was maintained.

[0059] After matching the solutions, the specific execution parameters of the joint expansion solution are encapsulated into the resource intervention instruction. The resource intervention instruction is organized according to the standard communication protocol format of the enterprise information system, including six mandatory fields: instruction type identifier, target node number, computing resource expansion parameters, personnel scheduling expansion parameters, instruction generation timestamp, and expected completion deadline. In the above scenario, the computing resource expansion parameters specify increasing the number of approval processing threads on the quality approval review server from the current eight to twelve; the personnel scheduling expansion parameters specify retrieving the numbers of two qualified non-duty quality inspectors from the standby personnel list and the temporary authorization validity period for their access to the system. After encapsulation, the resource intervention instruction is sent in message form to the enterprise administrative maintenance management terminal and human resources scheduling terminal via an encrypted secure application interface. Upon receiving the instruction, the administrative maintenance terminal automatically triggers the server thread expansion script, and the human resources scheduling terminal pushes a collaborative intervention notification and temporary system access authorization to the mobile devices of the corresponding standby personnel. In a preferred embodiment, the entire process of the resource intervention command, from the determination of the collaborative bottleneck increase to the completion of its issuance, has a processing delay of 163 milliseconds. The server thread expansion operation takes effect within approximately four seconds after the command is issued. Two standby personnel log in and begin processing backlogged tasks within an average of eleven minutes after receiving the notification. Subsequently, the collaborative bottleneck sampling value at 3:30 PM in the next sampling period drops back to 2.41 hours, the slope of change changes from positive to negative, and the jump state is lifted. This intervention, from the trigger determination to the first drop in bottleneck, takes approximately thirty minutes. Compared to the company's historical record of approximately two hours and forty minutes before the introduction of this system, when relying on manual inspections by management to discover and handle similar bottleneck events, the response time is improved by approximately 5.3 times.

[0060] This embodiment upgrades static threshold exceedance judgment to proactive perception of dynamic changes in collaborative obstruction by continuously recording data from a time-series database and calculating the real-time slope of the first-order difference. This allows for intervention triggered in the early stages of accelerating process obstruction, rather than passively responding after the obstruction has been fully exposed. A pre-defined strategy library with hierarchical matching directly connects resource status perception and scheduling decisions, achieving full automation from anomaly detection to intervention command generation.

[0061] Example 2: This embodiment fully deploys the aforementioned big data-based end-to-end performance data management method on a hospital's medical device configuration system. In the hospital's actual operation, R&D workstations are used to record the digital twin operations of medical devices, cleanroom sensor terminals are used to track the personnel and material trajectories during the configuration and packaging of sterile consumables, and the performance approval network carries the flow records of test review and material procurement.

[0062] Furthermore, the system collects interaction logs from R&D personnel at workstations, trajectory coordinates based on ultra-wideband positioning tags within the cleanroom, and node timestamps in the approval network to construct an initial behavioral trace set. The system invokes a protocol parsing operator to extract these unstructured logs into metadata retaining only three feature dimensions: occurrence time, operation entity identifier, and event action type. Subsequently, the system establishes a cross-domain mapping space, unifying the identity identifiers that originally existed in different forms such as employee ID numbers, system login names, and hardware media addresses into a standardized, unique code for all employees, thereby eliminating modal differences. Based on this, the system uses a graph network to treat event records under the same employee code as nodes, establishing directed edges to connect them according to the chronological order of occurrence and the relationship between tasks and subjects. Independent event records are encapsulated into a spatiotemporal cross-domain data stream containing the preceding and following business logic context. After being sliced ​​using an advanced encryption standard algorithm, the data is continuously injected into the distributed collaborative monitoring model through a streaming message transmission middleware.

[0063] Furthermore, after the distributed collaborative monitoring model receives the aforementioned spatiotemporal cross-domain data stream, the system activates its internally configured time-series parsing operator, setting a sliding window with a time span of twenty minutes to dynamically capture the data stream. Within this window, the system traverses and identifies cross-departmental business nodes, such as those transferring data from the R&D department to the approval department, calculating the absolute response time difference between the submission action of the previous department and the receipt action of the subsequent department. The system compares this time difference with a preset flow threshold of forty-five minutes derived from historical statistics. Once the actual response time exceeds this threshold, the system marks the flow record as a delay event and accumulates it in a global counter, thereby generating the frequency of asynchronous pauses that characterize the severity of waiting time. In a complete trial application process monitoring lasting one week, the system captured a total of 137 such cross-departmental pauses. At the same time, the system synchronously activates the cross-domain addressing tracing operator to specifically parse query nodes with cross-domain attributes in the data stream, such as an R&D personnel initiating searches in the patient medical record database, pharmacy inventory database, and R&D archive database in a short period of time. The system records in detail the network access jump order of these query nodes between different database systems, thereby constructing a cross-domain retrieval trajectory that characterizes the complexity of information search, and writes the above asynchronous pause frequency and cross-domain retrieval trajectory as basic feature data into the high-speed analysis pool in real time.

[0064] Furthermore, to quantify the captured behavioral characteristics into an evaluation index system, the system extracts the frequency of asynchronous pauses from the memory analysis pool and counts the total number of database switching hops in the cross-domain retrieval trajectory. In terms of specific calculation rules, the system performs logarithmic compression on the asynchronous pause frequency and hop count, then weights and fuses them according to preset weighting coefficients to obtain an initial friction coefficient. Subsequently, the system retrieves the historical collaboration smoothness index of each department in the hospital over the past six months, i.e., the proportion of historically completed handover tasks, and divides the initial friction coefficient by this smoothness index for environmental correction, ultimately outputting a collaboration friction coefficient that characterizes the resistance to cross-departmental collaboration and communication. A comprehensive scan of the hospital's business topology map mapped by the spatiotemporal cross-domain data flow accurately locates the node causing a large number of downstream reagent preparation tasks to be continuously stalled as the material procurement review node. The system then collects the cascading delay data caused by this node in real time, and statistics show that it affects a total of forty-five downstream reagent preparation nodes, causing a cumulative delay of over three hundred hours. To eliminate the one-sidedness of single-dimensional data, the system performs a discreteness calculation on these cascaded delay data, that is, extracts the delay duration array of each affected node, calculates the standard deviation of the array (when the number of affected nodes is less than three, the product of the number of affected nodes and the average delay duration is used as the alternative calculation result), and uses the standard deviation value to characterize the dispersion of the overall process delay, as the output of the collaborative obstruction index.

[0065] Furthermore, after acquiring the two key environmental indicators mentioned above, the system synchronously inputs them into the performance evolution engine specifically designed for personnel effectiveness assessment. To achieve an adaptive evaluation mechanism, the engine pre-configures a collaborative state mapping matrix. This matrix directly converts the collaborative friction coefficient into a friction resistance characteristic value corresponding to the severity level, and the collaborative obstruction degree into a collaborative consumption characteristic value representing the difficulty of process advancement. Based on these two characteristic values, the system automatically activates the built-in adaptive weight allocation algorithm. Since both the friction resistance level value and the collaborative consumption level value exceed the preset benchmark level, the system determines that the cross-system data processing overhead of the current business task exceeds the normal level, and then triggers the weight decay compensation logic. Specifically, the system lowers the result-oriented weight, which originally accounted for 70% of the performance assessment, to 40%, while increasing the process collaboration compensation weight, which originally accounted for only 30%, to 60%. This generates targeted dynamic weights for R&D and configuration personnel affected by approval delays, conforming to the current obstructed environment, and pushes them into a high-concurrency weight update queue. The system then extracts the targeted dynamic weight from the queue and structurally extracts the explicit node achievement rate, representing the proportion and quality of actual task completion, from the spatiotemporal data stream. In the multidimensional fusion processing stage, the system uses the mathematical principle of product to extend the targeted dynamic weight into an adjustment coefficient matrix containing multiple assessment dimensions, constructs the explicit node achievement rate into a multidimensional feature vector, and then multiplies the corresponding row and column elements of the matrix with the corresponding elements of the feature vector one by one and sums them. Through the above fusion calculation, the personnel collaborative performance evaluation score for the current evaluation period is obtained. Finally, based on the hospital's departmental administrative hierarchy, the system clusters employee scores by R&D group and configuration group, and calls the front-end graphics rendering component to generate a performance time-series evolution curve, a hospital-wide distribution map of bottleneck nodes, and an environmentally corrected performance ranking report on a large screen.

[0066] Furthermore, to prevent further deterioration of process bottlenecks, the system established a real-time evolution monitoring sequence for collaborative bottlenecks. The system uses a 30-minute sampling period, employing a first-order difference algorithm to calculate the difference between the current bottleneck and the previous bottleneck, dividing by the time interval to obtain the slope of change. When the system detects that this slope exceeds a preset 0.3 warning threshold, it directly determines that an abnormal surge in collaborative bottleneck has occurred in the hospital's business system. The system immediately traces upstream along the topology, re-identifying the procurement review node that triggered the surge, and extracts the node's resource bottleneck attributes from the hospital server: the node's current computing resource occupancy is as high as 90%, and the number of pending approval tasks under the procurement review personnel has reached an overload of 80 items per person. Based on these dual resource bottleneck attributes, the system autonomously queries the pre-set strategy response library and matches an appropriate joint resource intervention plan. The system packages the matched plan into a resource intervention command conforming to the hospital's information system standard communication protocol and sends it to the hospital's administrative maintenance terminal through an encrypted secure application interface. This instruction automatically triggers the server to increase the number of threads for the procurement review module and sends an emergency coordination and scheduling instruction to non-on-duty logistics personnel with equivalent qualifications, requiring them to immediately intervene and share the review task.

[0067] This embodiment transforms external environmental obstacles in the business process into calculable collaborative friction coefficients and collaborative stagnation degrees, and introduces a weighted adaptive compensation mechanism to achieve cross-system data correction. This allows for the early detection of process bottlenecks by monitoring the slope of the stagnation degree in the early stages of business disruptions, and the automatic issuance of resource intervention commands, effectively avoiding delays caused by critical node failures.

[0068] It should be clarified that the embodiments described above are merely exemplary and are intended to aid in understanding the present invention, not to limit it. Those skilled in the art can make various changes and modifications after grasping the core ideas of the present invention. Therefore, the scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. A big data-based end-to-end performance data management method, characterized in that: include: Acquire heterogeneous behavioral traces from R&D workstations, cleanroom sensor terminals, and performance approval networks; deconstruct and encapsulate these heterogeneous behavioral traces into a spatiotemporal cross-domain data stream and input it into a distributed collaborative monitoring model. The distributed collaborative monitoring model extracts the frequency of asynchronous pauses and the cross-domain retrieval trajectory during the cross-departmental iteration process based on the spatiotemporal cross-domain data stream; it calculates the collaborative friction coefficient, which characterizes the data processing overhead of inter-departmental collaboration, based on the frequency of asynchronous pauses and the cross-domain retrieval trajectory; and generates a collaborative obstruction degree based on the cascading delay data caused by process obstruction nodes. The collaborative friction coefficient and collaborative hindrance are input into the performance evolution engine. Based on the real-time quantified friction resistance and collaborative consumption, a targeted dynamic weight for performance evaluation correction is adaptively generated. The targeted dynamic weight is received and multi-dimensionally fused with the achievement rate of explicit nodes in the spatiotemporal cross-domain data stream to output a targeted collaborative performance report. When it is determined that the slope of the change in the collaborative obstruction exceeds a preset warning threshold, a resource intervention command pointing to the process obstruction node is output to the management terminal.

2. The method for full-process performance data management based on big data according to claim 1, characterized in that, The specific implementation process of acquiring heterogeneous behavioral traces output from R&D workstations, cleanroom sensor terminals, and performance approval networks, deconstructing and encapsulating these heterogeneous behavioral traces into a spatiotemporal cross-domain data stream, and inputting it into a distributed collaborative monitoring model includes: An initial behavior trace set is constructed by collecting the interaction logs of the R&D workstation, the positioning trajectory of the cleanroom sensor terminal, and the flow records of the performance approval network. A protocol parsing operator is invoked to strip data from the initial behavior trace set, extracting metadata features containing timestamps and operation types. A cross-domain mapping space is established to standardize and transform the metadata features to eliminate modal differences. A graph network is used to link and encapsulate the transformed metadata features according to temporal associations, forming a spatiotemporal cross-domain data stream containing context nodes. A secure channel is established to encrypt and slice the spatiotemporal cross-domain data stream and inject it into the distributed collaborative monitoring model for real-time analysis via streaming.

3. The method for full-process performance data management based on big data according to claim 1, characterized in that, The specific implementation process of the distributed collaborative monitoring model, which extracts the asynchronous pause frequency and cross-domain retrieval trajectory during the cross-departmental iteration process based on the spatiotemporal cross-domain data stream, includes: The time-series parsing operator within the distributed collaborative monitoring model is activated. This model is deployed based on a streaming computing framework and employs a master-slave architecture with a master node and worker nodes. The master node is responsible for receiving and distributing spatiotemporal cross-domain data streams, while each worker node receives and processes corresponding data shards in parallel according to their source from the business system. The time-series parsing operator is implemented as a state machine, internally maintaining a hash table with task numbers as keys and ordered event queues as values. It performs a sliding window of a preset time length to capture the received spatiotemporal cross-domain data stream, identifying cross-departmental flow nodes within the window. The response time difference is compared with a preset flow threshold. Delayed events exceeding the preset flow threshold are marked as asynchronous pauses and globally accumulated to generate the asynchronous pause frequency, which represents the waiting time. The cross-domain addressing tracking operator is activated synchronously, and the query node with cross-department attributes in the spatiotemporal cross-domain data stream is identified by parsing the database access identifier field in the metadata features. The access path of the query node between different databases is tracked and concatenated in the order of occurrence to form the cross-domain retrieval trajectory. The asynchronous pause frequency and the cross-domain retrieval trajectory are stored in the memory analysis pool as basic features.

4. The method for full-process performance data management based on big data according to claim 3, characterized in that, The collaboration friction coefficient, which characterizes the data processing overhead of inter-departmental collaboration, is calculated based on the frequency of asynchronous pauses and cross-domain retrieval trajectories. Simultaneously, the specific implementation process for generating the collaboration obstruction degree based on the cascading delay data caused by process bottlenecks includes: The asynchronous pause frequency is extracted from the memory analysis pool. The asynchronous pause frequency and the number of hops in the cross-domain retrieval trajectory are compressed and then weighted and fused according to a preset weight coefficient to obtain the initial friction coefficient. The proportion of each department that completes the handover task on time in the statistical period is used as the historical collaboration smoothness. The initial friction coefficient is divided by the historical collaboration smoothness to obtain the environment-corrected collaboration friction coefficient. The business topology map of the spatiotemporal cross-domain data flow is scanned to locate the process blockage node that causes continuous stagnation downstream. The cumulative downstream delay time and the number of affected nodes triggered by the process blockage node are collected in real time to form the cascaded delay data. The standard deviation of the delay time of each affected node in the cascaded delay data is calculated, and the standard deviation is used as the collaborative blockage degree to characterize the degree of dispersion of the overall process delay.

5. The method for full-process performance data management based on big data according to claim 1, characterized in that, The specific implementation process of inputting the cooperative friction coefficient and cooperative resistance into the performance evolution engine, and adaptively generating targeted dynamic weights for performance evaluation correction based on real-time quantified friction resistance and cooperative consumption, includes: The data receiving interface of the performance evolution engine is constructed to extract the synchronously transmitted collaboration friction coefficient and collaboration stagnation degree. Using the built-in collaboration state mapping matrix, the collaboration friction coefficient is mapped to a friction resistance level value and the collaboration stagnation degree is mapped to a collaboration consumption level value according to a pre-defined piecewise linear mapping rule. The level values ​​are specifically divided into three intervals: low, medium, and high. The boundary thresholds of each interval are determined based on the quantiles of historical business data. Based on the friction resistance level value and the collaboration consumption level value, the adaptive weight allocation algorithm within the engine is activated. When the friction resistance level value and the collaboration consumption level value exceed the preset benchmark level, the weight decay compensation logic is triggered, reducing the result assessment weight by a preset reduction and increasing the process collaboration compensation weight by an equal amount, with the sum of the two always being 1. Based on the processing result, the targeted dynamic weight matching the current environment is output and pushed into the weight update queue.

6. The method for full-process performance data management based on big data according to claim 5, characterized in that, The specific implementation process of receiving the targeted dynamic weights and performing multi-dimensional fusion processing with the achievement rate of explicit nodes in the spatiotemporal cross-domain data stream to output a targeted collaborative performance report includes: The targeted dynamic weights are extracted from the weight update queue, and the explicit node achievement rates, which represent the business processing results, are structurally extracted from the spatiotemporal cross-domain data stream. A multi-dimensional fusion model is constructed, and the targeted dynamic weights are transformed into an adjustment coefficient matrix. This matrix is ​​then multiplied with the feature vector formed by the explicit node achievement rates to offset the assessment bias caused by a single result-oriented approach. Based on the calculation results, a collaborative performance evaluation score that comprehensively reflects efficiency and the collaborative environment is obtained. According to the management hierarchy, a cross-departmental classification and aggregation operation is performed on the collaborative performance evaluation score. Based on the aggregation results, the front-end rendering component is invoked to generate the targeted collaborative performance report, which includes a time-series evolution curve, a map of obstructing node distribution, and an efficiency ranking.

7. The method for full-process performance data management based on big data according to claim 1, characterized in that, The specific implementation process of outputting a resource intervention command to the management terminal pointing to the process blockage node when it is determined that the slope of the change in the collaborative obstruction degree exceeds a preset warning threshold includes: A real-time evolution monitoring sequence of the collaborative bottleneck is established and continuously written into a time-series database according to a preset sampling period. A first-order difference algorithm is used to calculate the slope of the collaborative bottleneck in adjacent time periods. When the obtained slope exceeds a preset warning threshold, it is determined that the collaborative bottleneck has increased in the business system. The process bottleneck node that caused the increase is traced upwards, and the resource bottleneck attribute of the process bottleneck node is extracted, which includes the resource utilization rate and personnel load status. Based on the resource bottleneck attribute, a suitable resource tilt allocation and personnel scheduling expansion scheme is matched from a preset strategy library. The matched scheduling scheme is encapsulated into a resource intervention instruction with a standard protocol format and sent to the management terminal through a secure interface to perform resource reallocation scheduling.

Images