A method for cross-system integration and intelligent allocation management of scientific and technological achievement data

Abstract

This invention provides a cross-system integration and intelligent allocation management method for scientific and technological achievement data, relating to the field of scientific research data processing technology. The method includes: constructing an automatic integration mechanism for multi-source heterogeneous scientific and technological achievement data, forming a standardized achievement data pool after cleaning, deduplication, and standardization; constructing a hierarchical and interactive scientific and technological achievement management dashboard, which uses a hierarchical aggregation calculation model to achieve multi-dimensional indicator calculation, visualization, and abnormal fluctuation early warning; constructing an intelligent allocation and processing system for rewards and bonuses, based on a dynamic allocation rule engine and contribution measurement, to achieve online and automated reward allocation throughout the entire process; constructing a cross-business system data collaborative flow mechanism, connecting data links between systems such as project, intellectual property, and finance; and configuring a full-link hierarchical permission control and audit traceability mechanism. This invention enables the comprehensive acquisition and organic integration of scientific and technological achievement data, improving management efficiency and business accuracy.

Description

Technical Field

[0001] This invention relates to the field of scientific research data processing technology, and more particularly to a method for cross-system integration and intelligent allocation management of scientific and technological achievement data. Background Technology

[0002] With the deepening of enterprise digital transformation, technological innovation activities in large group enterprises are becoming increasingly frequent. The management of technological innovation achievements involves multiple business processes, including achievement registration, transformation tracking, intellectual property management, research project management, and reward and bonus allocation. This business data is typically stored in different information systems, with heterogeneous data sources, inconsistent formats, and asynchronous updates. This necessitates managers exporting data across platforms and relying on manual aggregation and verification when conducting statistical analysis and reward allocation, resulting in low efficiency and a high risk of errors. Therefore, achieving automatic integration, visual monitoring, and intelligent allocation of multi-source heterogeneous scientific and technological achievement data has become crucial for improving the refinement and intelligence of science and technology management.

[0003] In terms of the integration and visualization of scientific and technological achievements data, relevant technical solutions already exist. For example, Chinese invention patent application CN111930723A discloses a method for data fusion of scientific and technological achievements based on big data. This method builds a data fusion database, utilizes ETL tools for data extraction, transformation, and loading, enabling cross-platform, cross-domain, and cross-professional access to scientific and technological achievements data, and combines pie charts, bar charts, and line charts for visualization and health threshold monitoring. Chinese invention patent application CN113128915A discloses an intelligent scientific research data management and analysis system. This system integrates business modules such as scientific and technological ledger management, scientific research management, and achievement reward management through a collaborative management platform, and uses a data analyzer to classify and process document, image, and video data and perform threshold comparisons. Chinese invention patent application CN113128979A discloses a big data-based scientific research decision support system. It uses a data acquisition module to input data on scientific and technological records, scientific research management, and achievement awards. After threshold comparison by a data review module and tagging by a data labeling module, the system uses a data perception module and a display module to retrieve and display the data.

[0004] However, the above solutions mainly focus on one-way data aggregation, basic report display, or scientific research decision support, without addressing the implementation of configurable and interactive functions for management personnel. In terms of the depth of data integration, there is a lack of automated cleaning, standardization, and unified governance for multi-source heterogeneous scientific and technological achievement data, and there is still room for improvement in the flexibility and intelligence of data access.

[0005] Regarding innovation reward data management, Chinese invention patent application CN121413598A discloses a method for detecting duplicate innovation reward data. This method maps reward data into high-dimensional vectors using a FastText word embedding model, determines candidate pairs using hash bucket filtering and undirected graph connected component partitioning, and identifies duplicate data based on cosine similarity. This method focuses on deduplication of reward data and represents a single-stage optimization in reward management, without involving data linkage with front-end operations such as achievement registration, transformation tracking, and intellectual property management.

[0006] In summary, existing technologies related to the management of scientific and technological achievements still suffer from problems such as low automation in integrating multi-source heterogeneous data, weak visualization and monitoring capabilities, insufficient automation in reward distribution, and prominent data barriers across business systems.

[0007] Therefore, there is an urgent need for a full-chain digital management method that can automatically integrate multi-source data of scientific and technological achievements, provide intelligent monitoring in a visualized cockpit, and intelligently distribute rewards and bonuses. Summary of the Invention

[0008] To address the technical problems in existing technologies for managing scientific and technological achievements, such as low data integration efficiency, insufficient visualization and monitoring capabilities, low degree of automation in reward allocation, and prominent cross-business data barriers, this invention provides a cross-system integration and intelligent allocation management method for scientific and technological achievement data, so as to realize the full-link digitalization, visualization interaction, and intelligent allocation of scientific and technological achievement data in large enterprises.

[0009] To achieve the above objectives, the present invention adopts the following technical solution: A method for cross-system integration and intelligent allocation management of scientific and technological achievement data includes: Construct an automatic integration mechanism for multi-source heterogeneous scientific and technological achievement data, configure the access of scientific and technological achievement data from enterprise multi-source information systems, perform automatic cleaning, deduplication, and format correction on the accessed multi-source heterogeneous scientific and technological achievement data, perform field mapping and standardized conversion according to unified standards, and construct a standardized achievement data pool. A layered and interactive technology achievement management dashboard is constructed, adopting a three-level display architecture. It supports multi-dimensional filtering and drill-down queries based on professional fields, affiliated units, achievement types, time ranges, etc. It automatically calculates core indicators and generates trend analysis, realizing the visualization of achievement indicators and early warning of abnormal fluctuations. Build an intelligent allocation and processing system for rewards and bonuses, and realize the online and automated processing of the entire process of reward and bonus allocation in the scientific and technological achievement management dashboard; Build a cross-business system data collaboration and flow mechanism, connect the data links of various business systems related to technological innovation in the enterprise, realize the automatic association and synchronization of scientific research results data with project data and reward data, and provide a unified data service interface to support external system calls; Establish a full-link hierarchical access control and audit traceability mechanism, configure system roles and data permissions in accordance with the principle of role-based access control, record the entire process of key operations such as data synchronization, configuration modification, and reward allocation, and support multi-dimensional log retrieval and structured export.

[0010] Preferably, the automatic integration mechanism for multi-source heterogeneous scientific and technological achievement data includes: Configure differentiated data access channels based on the data types and interaction characteristics of the enterprise's multi-source information systems; the enterprise's multi-source information systems may include human resource systems, project management systems, and intellectual property systems containing data related to scientific and technological achievements.

[0011] The multi-source heterogeneous scientific and technological achievement data includes structured and unstructured data. For structured data, a synchronization mechanism is established that integrates timed batch extraction with real-time incremental capture based on database logs. For unstructured files, a convergence mechanism is established that integrates secure file transmission and automatic metadata extraction. This forms an adaptive access network covering all types of data sources, ensuring the complete and timely acquisition of data.

[0012] For the original scientific and technological achievement data stream that has been accessed, firstly, the format is standardized and outlier is handled, and the display format and logical errors of the fields are automatically identified and corrected; Then, the content parsing service is invoked to extract structured information from the unstructured file in order to complete and verify the associated data; Finally, a multi-level matching strategy is adopted for data deduplication. First, the data is accurately deduplicated based on strong unique identifiers. Then, the remaining data is associated through a fuzzy matching algorithm, and suspected duplicates are marked to support controlled manual arbitration, forming a closed-loop governance mechanism for rule self-optimization.

[0013] A dynamic field mapping engine and standard dictionary service are configured to map and escape values ​​from multi-source heterogeneous data after governance, according to a pre-defined unified data model. Simultaneously, using the core business primary key as the link, results information, personnel information, and attachment information from different systems are linked and integrated to construct a logically complete, physically hierarchically stored standardized results data pool, which provides standardized data support externally through a unified data service interface.

[0014] It provides a visual data access and rule configuration interface, allowing administrators to flexibly configure data sources, cleaning rules, and indicator calculation logic according to management needs; Preferably, the construction of the hierarchical and interactive technology achievement management cockpit adopts a multi-dimensional achievement indicator calculation model. The model adopts a hierarchical aggregation calculation architecture, including an input layer, a feature extraction layer, an indicator aggregation layer, a visualization rendering layer, and an output layer.

[0015] The input layer receives three types of data input: raw data from the standardized results data pool, user context information, and indicator configuration rules. The input layer performs format verification and permission filtering on the input data to ensure that the data is within the user's access range. After preprocessing, the data is passed to the feature extraction layer. The feature extraction layer performs four parallel feature extractions on the input data: the first path extracts basic features of the results; the second path extracts conversion efficiency features; the third path extracts time series features; and the fourth path extracts reward-related features. After the four feature extractions are completed, the data enters the indicator aggregation layer. The index aggregation layer aggregates and calculates the four types of features output by the feature extraction layer, and generates a standardized index set according to the configured index formula. It supports two aggregation strategies: global aggregation and dimension drill-down aggregation. The global aggregation strategy calculates the overall index based on the full data, while the dimension drill-down aggregation strategy can group and aggregate according to the dimension selected by the user to generate sub-dimensional indexes. The aggregation layer also executes anomaly detection logic to identify and mark situations where index fluctuations exceed the threshold. The visualization rendering layer receives the indicator data output by the indicator aggregation layer, automatically matches the visualization components according to the view configuration, and completes the chart rendering and page layout; at the same time, it loads interactive controls to realize the binding of interactive functions such as filtering, drill-down, and exporting. The output layer returns the rendered cockpit page to the front-end user, and simultaneously writes the input parameters, calculation process, and result data of this indicator calculation to the audit log and data cache. Subsequent accesses under the same conditions will directly read from the cache, improving response speed. The output layer also provides a standardized indicator data interface to support calls from other systems.

[0016] The process of constructing the multi-dimensional outcome indicator calculation model also includes constructing a complete set of indicator configuration rules. These indicator configuration rules are a set of metadata used to drive the calculation model to operate in a configurable manner, and their construction includes: Construct indicator calculation rules, configure the calculation formula for each core indicator that needs to be presented, and bind and map each operand in the formula to the feature labels from the standardized results data pool to make the calculation logic structured, parsable, and support version management. Construct data standards, establish a standard dictionary in the field of scientific and technological achievements, define a unified value range for fields such as achievement type, professional field, and award level, and make standardized declarations on the statistical scope, calculation range and time window of each indicator to ensure that the calculation of indicators is consistent across multiple data sources. Build a dimension configuration, establish a unified dimension hierarchy tree covering organizational, type, and time dimensions, configure the many-to-many relationship between each indicator and dimension, and define the drill-down path and aggregation method under each dimension.

[0017] Preferably, the intelligent allocation and processing system for rewards and bonuses is configured with a multi-dimensional dynamic allocation rule engine. The rule engine is used to preset a basic bonus base based on the achievement attributes and set multiple adjustable allocation coefficients, thereby combining them to form differentiated allocation strategy templates. Based on the standardized results data pool and cross-system collaborative data, the contribution correlation information of the results completers is automatically collected, and the initial contribution weight is calculated according to the preset algorithm. At the same time, the controlled correction operation of the weight is recorded. The rule engine and contribution weight are invoked to automatically generate a reward distribution scheme containing calculation details, and a configurable multi-level approval process is initiated, with budget threshold verification and allocation anomaly warning mechanism embedded in the process. After approval, instructions are automatically sent to the relevant business systems through the unified data service interface, triggering bonus distribution, synchronization of individual reward records, and write-back of achievement status. The allocation status and indicators are then fed back to the cockpit for display, forming a closed loop.

[0018] In one embodiment of the present invention, the business systems related to enterprise and technological innovation include project management systems and intellectual property systems, etc. Preferably, the mechanism for constructing cross-business system data collaboration and transfer includes: The standardized results data pool is connected to the intellectual property system, and the entire process information such as application, authorization, and fees of intellectual property rights such as patents, software copyrights, and papers is synchronized to the standardized results data pool on a regular basis. At the same time, it supports pushing the results number of the cockpit to the intellectual property system to realize two-way data mapping. Establish a data link between the enterprise's project management and intellectual property system. The results information of the project completion output is automatically synchronized to the intellectual property system as data to be registered, and the results transformation data is reversely synchronized to the project management system as the basis for post-project evaluation. The reward allocation plan is linked to the corresponding scientific research achievement information in the intellectual property system, automatically filling in basic fields such as achievement name, number, and type, reducing manual data entry; after the reward allocation plan is approved, the reward information is automatically written back to the full life cycle archive of the corresponding scientific research achievement. It provides standardized data service interfaces to external users, enabling other business systems within the enterprise to access data such as performance indicators and reward information, and supporting upper-level decision analysis applications.

[0019] In the cross-system integration and intelligent allocation management method for scientific and technological achievement data provided by this invention, a multi-source data collaboration and consistency guarantee mechanism is also configured to ensure high timeliness and high reliability of the data, including: Real-time data change synchronization mechanism: When any related business system's achievement data or reward data is added, modified, or deleted, a data change event is triggered. The event carries data ID, change type, change time, and change content information, and asynchronously triggers the automatic integration mechanism of multi-source heterogeneous scientific and technological achievement data through a message queue. The synchronization delay is controlled at the second level to ensure timely updates of the dashboard data. For non-real-time data, a scheduled full synchronization task is configured as a backup to ensure eventual data consistency. Cockpit access snapshot mechanism: Each time a user accesses the cockpit, the cockpit backend does not directly query the real-time business database, but generates an access snapshot based on the data pool at the current moment. All filtering and drill-down operations within this access period are performed based on this snapshot; thereby avoiding the problem of indicator values ​​jumping or inconsistencies caused by real-time changes in the underlying data. Cross-system two-way verification mechanism: The core fields in the standardized results data pool are periodically extracted and automatically compared with the corresponding fields in the source business system; inconsistent data entries are identified and recorded, a difference report is generated and pushed to the preset management personnel; the verification process is automatically recorded throughout, forming a data quality monitoring log, which supports traceability by time and system dimension; Incremental and full synchronization collaborative mechanism: Daily data updates adopt incremental synchronization mode, which only transmits changed data to reduce network overhead and system load; full synchronization mode is executed at preset fixed periods or through manual triggering to correct the cumulative deviation that may occur during incremental synchronization; the two synchronization modes work together to balance the efficiency and accuracy of data processing. Data change tracking and rollback mechanism: For all data change operations in the standardized results data pool, a snapshot of the historical version before the change and an operation record including the operator, operation time, and change content are saved; it supports querying and tracing the historical data status by time point. When data errors are found or auditing is required, the specified data entries can be quickly rolled back to any historical version to ensure business continuity and data recoverability.

[0020] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention's method for cross-system integration and intelligent allocation management of scientific and technological achievement data addresses the problems of scattered data storage across multiple independent systems and low data integration efficiency by establishing an automatic integration mechanism for multi-source heterogeneous scientific and technological achievement data and constructing a standardized achievement data pool. It also solves the problems of insufficient visualization monitoring capabilities and inadequate decision support by building a hierarchical and interactive scientific and technological achievement management dashboard that enables visualized presentation of core indicators, multi-dimensional filtering and querying, and automatic trend analysis. Furthermore, it addresses the problems of low automation in reward allocation and low efficiency in manual verification by designing an intelligent reward and bonus allocation system that enables a fully online process including template adaptation, automatic generation of reward allocation schemes, automatic verification, and online preview and modification. Finally, it addresses the problems of high data barriers and severe data silos across business systems by establishing a cross-business system data collaboration and transfer mechanism that constructs data links for achievement, project, intellectual property, and reward modules. Finally, it addresses the problems of lack of full-link traceability and compliance risks by constructing a full-link hierarchical access control and audit traceability mechanism that ensures all operations are fully traceable and auditable. This invention enables comprehensive acquisition and organic integration of scientific and technological achievement data, improving management efficiency and business accuracy. Attached Figure Description

[0021] Figure 1 This is a flowchart of a cross-system integration and intelligent allocation management method for scientific and technological achievement data provided in an embodiment of the present invention; Figure 2 This is a detailed flowchart of S1 provided in an embodiment of the present invention; Figure 3 This is a diagram of the multi-dimensional performance indicator calculation model architecture provided in an embodiment of the present invention; Figure 4 This is a detailed flowchart of S3 provided in an embodiment of the present invention; Figure 5 This is a detailed flowchart of S5 provided in an embodiment of the present invention. Detailed Implementation

[0022] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0023] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0024] Example 1 Figure 1A flowchart illustrating a cross-system integration and intelligent allocation management method for scientific and technological achievement data, as provided in an embodiment of the present invention, is shown below. Figure 1 As shown, the specific steps are as follows: S1 establishes an automatic integration mechanism for multi-source heterogeneous scientific and technological achievement data, used to automatically aggregate heterogeneous scientific and technological achievement data scattered across multiple business systems within an enterprise into a high-quality, standardized data pool. Figure 2 A detailed flowchart of S1 provided in an embodiment of the present invention is shown below. Please refer to [link / reference]. Figure 2 Specifically, it includes the following steps: S11, Configuration of Multi-Source Heterogeneous Scientific and Technological Achievement Data Sources: First, an inventory of the enterprise's multi-source business systems is conducted, and differentiated access channels are configured based on their data formats and interaction capabilities. In this embodiment, the multi-source heterogeneous scientific and technological achievement data is mainly divided into structured data and unstructured data.

[0025] For structured data access channels, two synchronization modes are deployed for project management systems and intellectual property management systems that provide relational database access. For historical full data or non-real-time data, a scheduled batch extraction task based on ETL tools is configured, performing full or incremental extraction via JDBC during periods of low system load. For core business tables such as result status tables and bonus distribution tables, a change data capture sensor based on database log parsing is deployed to monitor and push Insert, Update, and Delete event streams to a message queue in real time, achieving second-level real-time synchronization. The two modes operate in tandem, with incremental synchronization as the primary method on a daily basis, and a full synchronization performed periodically to correct for deviations.

[0026] For unstructured data access channels, a file monitoring program is deployed on attachment servers or document clouds storing scanned copies of patent certificates, PDF technical reports, and other files. When a new file is detected, it is uploaded to a unified distributed object storage system via secure protocols such as SFTP. Metadata such as the filename, associated achievement number, and upload time are extracted simultaneously, generating a file index record in the data pool. At the same time, an integrated OCR service or document parsing engine is automatically invoked to extract key information such as certificate number and authorization date from the file content, writing it back to the corresponding structured fields to achieve automatic parsing and completion of unstructured content.

[0027] API service adaptation: Provides a unified adapter for each access channel to handle authentication (such as OAuth2.0), rate limiting and protocol conversion for different systems, shielding the differences in the underlying systems.

[0028] S12, data cleaning, deduplication, and quality management configuration, performs hierarchical and progressive quality management on the raw data stream. Details are as follows: Level 1: Format standardization and outlier processing. First, a format regular expression library covering common types of scientific and technological achievement data is constructed. The construction method of this regular expression library is as follows: For date-type fields, a multi-template recognition rule set is configured, including no less than 10 matching regular expressions for common date formats such as "YYYY-MM-DD", "YYYY / MM / DD", "YYYY年MM月DD日", and "MM / DD / YYYY", which are uniformly converted and output in the standard "YYYY-MM-DD" format; for amount value fields, thousandths separator cleaning rules and decimal place truncation rules are configured to uniformly retain two decimal places; for text-type fields, standardization rules such as capitalizing the first letter, converting full-width characters to half-width characters, and filtering invisible characters are configured. Automatic logic error detection is implemented through a preset check rule table, which is defined by classification according to field types, including: null value detection rules (marking data rows with empty required fields), numerical range detection rules (e.g., the number of achievements is non-negative, and the transformation amount does not exceed a preset magnitude threshold), logical dependency detection rules (e.g., when the "transformation status" is "transformed", the "transformation date" field cannot be empty), and enumeration value range detection rules (checking whether the field value belongs to the valid code set defined in the standard dictionary table). For data that triggers the abnormality mark of the check rule table, the system executes an automatic correction process: null values are preferentially completed from associated data (such as other source fields of the same achievement), and if the completion fails, the default value of the field type is filled in and a completion failure log is recorded; if the value exceeds the range, it is truncated to the threshold boundary and an alarm event is generated; if there is a logical dependency conflict, it is marked as to-be-manually-reviewed and pushed to the cockpit to-do center.

[0029] Level 2: Intelligent deduplication and entity association. A matching deduplication engine is built, which adopts a determination strategy combining exact matching and fuzzy matching. Specifically, hard matching is performed based on strong unique identifiers such as patent numbers, project numbers, or software copyright registration numbers, records with a 100% matching success rate are directly merged, the latest update timestamp of all associated information is retained, and the union of the field values from each source is taken.

[0030] For data records that do not have strong unique identifiers, an improved edit distance algorithm combined with a scientific and technological achievement domain dictionary is used for similarity calculation. Let the achievement name strings of two records to be matched be A and B respectively, and their improved edit distance is Lev_adj(A, B). The calculation method is based on the standard edit distance, introducing domain synonym replacement cost adjustment: if the participles at the corresponding positions in the two strings belong to the synonym pairs in the pre-built scientific and technological achievement domain synonym dictionary, the replacement operation cost is reduced from the standard value 1 to 0.3; if they belong to a hyponymy-hypernymy relationship, the replacement cost is adjusted to 0.6. The lengths of the strings are recorded as len(A) and len(B), then the calculation formula of the similarity Sim(A, B) is:

[0031] Simultaneously, a combined feature vector is constructed for multi-feature comprehensive judgment. The combined features include: similarity of achievement names (weight 0.6), Jaccard similarity of the set of names of the contributors (weight 0.3, normalized using a domain dictionary for common aliases), and consistency of achievement types (weight 0.1). The comprehensive similarity score is the weighted sum of each feature. The fuzzy matching judgment threshold is set as follows: when the comprehensive similarity is ≥ 0.85, it is automatically judged as a match and merged; when the comprehensive similarity is 0.65 ≤ comprehensive similarity < 0.85, it is marked as a suspected duplicate record and pushed to the dashboard task center for data administrators to perform manual arbitration of "merge," "keep," or "ignore," with the arbitration operation fully traceable; when the comprehensive similarity is < 0.65, it is judged as a mismatch. The system records the valid matching pairs in each manual arbitration conclusion and periodically feeds them back to the training dataset of the fuzzy matching model to adjust the weights of the domain thesaurus and the replacement cost parameters of the edit distance, forming a closed loop of rule self-optimization.

[0032] Level 3: Standardized Transformation and Association Integration. A dynamic field mapping engine is configured to map source system fields to standard fields in the data pool. The storage structure for the mapping relationship uses a relational mapping table, which contains the following core fields: unique identifier for the mapping rule, source system identifier, source table name, source field name, target standard field name, transformation function identifier, mapping relationship status, version number, effective time, and expiration time. The mapping rule configuration is implemented through a visual interface. Administrators drag and drop to connect fields in the source field list on the left with target fields in the standard field tree on the right. The front end generates a JSON-formatted mapping relationship configuration based on the connection, which is then parsed by the backend and written to the mapping table. The rule version management mechanism is as follows: each addition, modification, or deletion of a mapping rule does not overwrite the original record; instead, a new mapping relationship record is generated and assigned a new version number, while the effective status of the previous version is updated to "expired." All historical versions are fully preserved, supporting backtracking to any historical snapshot of the mapping rule by version number. After completing the field mapping, the standard dictionary service of the enterprise-level master data management platform is invoked to uniformly convert the source system values ​​of fields such as "affiliated unit," "professional field," and "achievement type" into standard codes. Then, using project number, achievement number, etc. as the association primary key, a multi-table join query method is used to associate and merge data such as basic achievement information, completer details, attachment list, and award status from different systems, assembling them into a complete scientific and technological achievement data object, which is then written into the standardized achievement data pool.

[0033] The standardized results data pool adopts a three-tier physical storage architecture: The first layer is the operational data storage layer, which stores copies of the original data directly accessed from each source system. It is stored in separate databases and tables according to the source system, and the table structure is consistent with the source system. All historical change records are retained for data traceability and reprocessing.

[0034] The second layer is the data warehouse layer, constructed using a hybrid modeling approach combining star and snowflake schemas. Fact tables include outcome fact tables, conversion fact tables, and reward fact tables. Dimension tables include time dimension tables, organizational dimension tables (unit-department-team hierarchical tree), outcome type dimension tables, and professional domain dimension tables. Fact tables and dimension tables are linked via foreign keys. The dimension tables employ a slowly changing dimension strategy, recording the history of each dimension attribute change and supporting backtracking queries at any historical point in time.

[0035] The third layer is the data mart layer, which aggregates and stores data by subject domain, pre-constructing summary tables and materialized views for typical query scenarios in the dashboard. For example, it pre-calculates summary tables of result quantity and conversion amount by month-unit-result type, and pre-calculates summary tables of result growth rate by year-professional field, significantly improving the query response speed of the dashboard's multidimensional analysis. Data flows between layers through periodic ETL tasks or real-time streaming pipelines. Incremental data from the ODS layer is cleaned and transformed before being written to the detailed fact table and dimension table of the DW layer. Data from the DW layer is aggregated by dimension drill-down or roll-up before being written to the summary table of the DM layer. In terms of indexing strategy, B-Tree indexes are created for foreign key fields in the DW layer fact table, partition indexes are created for date fields, composite indexes are created for the DM layer summary table based on combinations of commonly used query dimensions, and inverted indexes are created for text search fields such as result name and author name to optimize the performance of various query scenarios.

[0036] S2 constructs a layered and interactive technology achievement management dashboard, adopts a three-level display architecture, supports multi-dimensional combination filtering and drill-down queries by professional field, affiliated unit, achievement type, time range, etc., automatically calculates core indicators and generates trend analysis, and realizes the visualization of achievement indicators and early warning of abnormal fluctuations. Specifically, the cockpit uses a three-tiered display rack system, including: The primary page displays global core metrics, including total number of achievements, total conversion amount, annual growth rate, and patent holdings. It automatically calculates year-on-year and month-on-month changes in core metrics such as the number of achievements, conversion efficiency, and patent applications, generating trend line charts and bar charts. It supports automatic identification and highlighting of abnormal metric fluctuations. Anomaly detection uses a combination of moving average and standard deviation: for each metric, it calculates the moving average μ and standard deviation σ over the past N periods (N is configurable, default is 6). When the current value exceeds the range of μ ± 3σ, it is considered an abnormal fluctuation, and the system automatically highlights and generates an anomaly alert.

[0037] The second-level page supports drill-down analysis by professional field, affiliated institution, and output type, displaying the distribution and proportion of each dimension. It supports multi-dimensional filtering by time range, institution level, professional field, output type, and conversion status, with filtering conditions taking effect in real time, and all charts and indicators in the dashboard updating synchronously. It supports interactive operations such as chart zooming, exporting, and data drill-down.

[0038] The third-level page allows you to view detailed data on the entire lifecycle of a single achievement, including basic information about the achievement, its transformation progress, intellectual property information, and awards.

[0039] For personalized view configuration, the system supports different user roles in configuring exclusive dashboard views. Administrators focus on overall totals and trends, while business personnel focus on detailed results and conversion progress within their own units. The system automatically loads the corresponding view based on the user's role. View configuration information is stored in the database, and each user can save multiple view templates.

[0040] The cockpit employs a multi-dimensional performance indicator calculation model, and the specific model construction includes the following steps: S21. Construction of Indicator Configuration Rules: Before building the cockpit's computational model, a complete set of dynamically configurable indicator configuration rules needs to be constructed as the core metadata driving the computation. This includes the following steps: S211, Metric Calculation Rule Construction: For each core metric, define its unique identifier and business meaning, and configure the calculation formula (e.g., conversion rate = number of converted results / total number of results × 100%). Bind the operands in the formula to feature tags in the data pool; the formula supports version management.

[0041] S212, Data Standard Construction, establishes a standard dictionary in the field of scientific and technological achievements, defines a unified value range for fields such as achievement type, technology maturity, and award level; and standardizes the statistical scope, inclusion / exclusion conditions, and time window for each indicator.

[0042] S213, Dimension Configuration: Construct a unified hierarchical tree of dimensions, including organizational dimensions (unit → department → team), type dimensions (major category of results → minor category), and time dimensions (year → quarter → month). Configure the many-to-many relationships between each indicator and dimension, as well as the drill-down path and aggregation method for each dimension.

[0043] S22, detailed configuration of the hierarchical aggregation computing model. The cockpit engine adopts a multi-dimensional performance indicator calculation model, which uses a hierarchical aggregation computing architecture. Figure 3 This diagram illustrates the architecture of a multi-dimensional performance indicator calculation model provided by an embodiment of the present invention. Please refer to [link / reference]. Figure 3 It includes an input layer, a feature extraction layer, an indicator aggregation layer, a visualization rendering layer, and an output layer.

[0044] The input layer receives a query result set from the standardized results data pool, currently effective indicator configuration rules, and user context including user role, affiliated unit, and data access permissions. The input layer first prunes the raw data according to permissions to ensure that only the data range that the user is authorized to view is returned. Then, after type validation, the data is passed to the feature extraction layer.

[0045] The feature extraction layer initiates four-way parallel extraction based on the data binding relationship in the indicator configuration rules. The specific feature dimension list, data source, and extraction algorithm for each extraction are as follows: The first approach extracts the basic features of the results. The data source is the results fact table, results type dimension table, and organization dimension table from the standard results data pool. The extracted feature dimensions include: unique identifier of the results, results type code, technology maturity level (level 1-9), organization node ID, number of people who completed the results, and results registration date. The extraction algorithm is direct field mapping reading. For the organization node ID, it also traces upwards to obtain its parent node ID to support hierarchical aggregation of the organization dimension. The second approach extracts transformation efficiency features. The data source is the transformation fact table of the standard achievement data pool. The extracted feature dimensions include: the number of transformation contracts corresponding to the achievement, the total amount of transformation contracts, the transformation method (transfer / licensing / investment), and whether industrial application has been achieved. The extraction algorithm is to group and summarize statistics based on the achievement number as the primary key, perform SUM aggregation on the total amount of transformation contracts, perform COUNT aggregation on the number of transformation contracts, and take the status value of the latest transformation record for transformation method and industrial application status. The third approach extracts time-series features from data sources including timestamped achievement registration and conversion records in a standard achievement data pool. The extracted features include: the number of achievement registrations grouped by calendar year, the conversion amount grouped by quarter, the year-on-year growth rate of achievement quantity for each year, and the month-on-month growth rate of conversion amount for each quarter. The extraction algorithm uses SQL window functions. After grouping and aggregating by time dimension, the previous period's value is obtained using LAG window functions, and the year-on-year / month-on-month growth rate is calculated using the formula (current period value - previous period value) / previous period value × 100%. If the previous period value is 0, the growth rate is recorded as NULL. The fourth approach extracts reward-related features. The data source is the reward fact table and reward allocation details table from the standard achievement data pool. The extracted feature dimensions include: total reward amount of the achievement, number of times the achievement has received rewards, number of participants in the reward allocation, and the highest reward amount per person. The extraction algorithm is to group and summarize the achievement number as the primary key, perform SUM aggregation on the reward amount, COUNT aggregation on the reward allocation record, and MAX aggregation on the reward amount per person.

[0046] After the four-way feature extraction is completed, the extraction results are merged by outer join according to the result number to form a wide table feature set containing all feature dimensions, which is then passed to the indicator aggregation layer.

[0047] The index aggregation layer receives the wide table feature set output by the feature extraction layer, substitutes it into the calculation formula in the index configuration rules, and performs two types of calculations: global aggregation and dimension drill-down aggregation.

[0048] The calculation logic of the global aggregation is to perform index formula calculation on the full set of feature data without adding any dimensional grouping conditions.

[0049] In this embodiment, taking the results conversion rate indicator as an example, the pseudocode for its globally aggregated SQL execution logic is as follows: SELECT (COUNT(CASE WHEN conversion status = 'converted' THEN 1 END) 1.0 / COUNT(1)) 100 AS conversion rate FROM wide table feature set WHERE data permission filtering conditions; The calculation logic for dimension drill-down aggregation is to dynamically concatenate the corresponding dimension fields in the SQL GROUP BY clause based on the dimension combination currently selected by the user, and then perform grouped aggregation calculation.

[0050] In this embodiment, taking the user's choice to drill down by professional field and affiliated unit as an example, the pseudocode of its SQL execution logic is as follows: SELECT Professional Field Code, Affiliated Institution Code, COUNT (Unique identifier for output) AS Number of outputs, SUM(Total Contract Amount Converted) AS Conversion Amount (COUNT(CASE WHEN conversion status='converted' THEN 1 END) 1.0 / COUNT(1)) 100 AS conversion rate from wide table feature set WHERE Data Permission Filtering Conditions AND Other Filtering Conditions GROUP BY: Professional Field Code, Affiliated Organization Code ORDER BY: Professional Field Code, Affiliated Institution Code; To optimize the performance of multi-dimensional aggregation, a pre-computed cube strategy is adopted. The system statistically analyzes high-frequency dimension combinations based on historical access logs and executes pre-computed tasks asynchronously in the background on a weekly basis. These pre-computed tasks perform grouped aggregation calculations on commonly used dimension combinations (including but not limited to: time + organization, time + outcome type, organization + outcome type, time + organization + outcome type), storing the aggregation results in a pre-computed summary table at the data mart layer. The table structure includes the field codes and hierarchical paths for each dimension, the pre-computed values ​​for each indicator, and the calculation timestamp. When a user initiates multi-dimensional filtering and drill-down queries, the indicator aggregation layer first parses the dimension combinations in the query request and matches the finest-grained pre-computed results in the pre-computed summary table. If a pre-computed data set that perfectly matches or is finer-grained than the queried dimension combination exists, the result is directly read from the pre-computed summary table, with a response time controlled within milliseconds. If no matching pre-computed result is found, the system reverts to the data warehouse layer to perform grouped aggregation calculations in real time, recording the dimension combinations from this query in the access log as a reference for subsequent pre-computed task scheduling.

[0051] While performing aggregation calculations, the indicator aggregation layer executes anomaly detection logic in parallel to determine anomalies in the core indicator values ​​calculated in the current period.

[0052] The anomaly detection employs a combination of moving average and standard deviation. Specifically, let the value of the current indicator to be detected at time point t be V_t. A sequence of indicator values ​​{V_{t-1}, V_{t-2}, ..., V_{tN}} (where N is the detection window size) over the past N historical periods is selected. The formulas for calculating the moving average μ and the sample standard deviation σ of this sequence are as follows:

[0053]

[0054] Define anomaly score When σ=0, Z_score is recorded as 0.

[0055] The method for determining the detection window size N is as follows: First, the base window is determined based on the data characteristics of the indicator. For monthly updated indicators (such as the number of new monthly achievements), the initial window N0 is set to 12 (covering the past year); for quarterly updated indicators, the initial window N0 is set to 4 (covering the past year). Based on this, the system collects the autocorrelation coefficient of the historical sequence of the indicator. If the autocorrelation coefficient is greater than 0.6 (indicating a strong trend in the sequence), the window is increased to N = N0 × 1.5 to smooth the trend effect; if the autocorrelation coefficient is less than 0.3 (indicating large fluctuations in the sequence), the window is decreased to N = N0 × 0.7 to improve the sensitivity of anomaly detection. The window size is centrally managed through configuration rules and can be manually adjusted by the administrator.

[0056] The criteria for classifying anomalies are as follows: |Z_score|≥3.0: This is considered a serious anomaly (red alert), indicating that the corresponding indicator value deviates significantly from the historical normal range; 2.0≤|Z_score|<3.0: This is considered a minor anomaly (yellow warning), indicating that the corresponding indicator value deviates significantly but is still within a controllable range; |Z_score|<2.0: This is considered a normal fluctuation and no warning will be triggered.

[0057] In addition, if the indicator shows a deviation in the same direction for three consecutive periods and the Z_score of each period is greater than 1.5, a trend deviation warning (orange warning) will be triggered, indicating that the indicator may have a systematic deviation.

[0058] The alert push mechanism is as follows: When an anomaly detection triggers an alert, the indicator aggregation layer writes the alert record (including indicator name, current value, historical mean, standard deviation, anomaly score, anomaly level, and trigger time) into the cockpit alert message table, and simultaneously sends the alert event to the notification service asynchronously via a message queue. The notification service matches the push channel according to the alert level: red alerts and trend deviation alerts are pushed to system administrators and business managers in real time via both enterprise instant messaging tools and SMS; yellow alerts are only displayed in the cockpit as highlighted markers and pop-up notifications, and are not pushed externally.

[0059] The visualization rendering layer acquires the aggregated indicator data, automatically matches visualization components such as dashboards, trend charts, bar charts, and pie charts according to the view configuration bound in the indicator configuration rules, and loads interactive controls such as filters and drill-down buttons to complete the rendering of charts and page layout.

[0060] Output layer: Returns the rendered cockpit page to the front end; simultaneously writes the input parameters, configuration rule version number, and calculation results to the audit log; and writes the results to the memory cache using the user context and the hash value of the filtering conditions as the key, so that subsequent accesses with the same conditions can directly read from the cache. The output layer also provides standardized indicator data APIs for other systems to call.

[0061] S23, the cockpit is equipped with an access snapshot mechanism, and the snapshot is generated using a temporary materialized table scheme bound to the session. When a user accesses the cockpit for the first time or clicks the "Refresh Snapshot" button, the cockpit backend executes a snapshot generation stored procedure. This stored procedure first constructs a data query statement with permission filtering based on the current user's role and data permissions, and then executes it, copying the data within the permission range from the standardized results data pool at the current moment to a temporary table. The snapshot table contains the latest data of all related dimension tables and fact tables at the time of the query, ensuring that the data view is completely consistent throughout the access period.

[0062] The isolation mechanism between snapshots and real-time data is as follows: the snapshot temporary table is physically isolated from the source business database and the standardized results data pool during real-time write operations. When data changes in the source business system are written to the standardized results data pool through a synchronization mechanism, no updates to the snapshot temporary table are triggered. SQL queries for operations such as filtering, sorting, drill-down, and exporting in the dashboard backend all use the snapshot temporary table as the data source, rather than directly accessing the standardized results data pool. This mechanism ensures that all charts and metrics are calculated based on the same data version at any given time during a single dashboard access session, completely eliminating inconsistencies or numerical jumps in metrics caused by changes in the underlying data during the query process.

[0063] The snapshot lifecycle management strategy is as follows: the lifecycle of the snapshot temporary table is bound to the user session. A snapshot is created when a user logs in and visits the dashboard for the first time. When the user actively clicks "Refresh," the snapshot is rebuilt (first DROP the old table and then CREATE the new table). When the user clicks "Reset," the snapshot is restored to the initial snapshot (no rebuild, only the filter conditions are reset). After a user logs out normally or the session times out (the timeout period is configured to 30 minutes and is adjustable), all temporary snapshot tables associated with that session are cleaned up in the background to release database storage resources. Simultaneously, a scheduled cleanup task is configured to scan the database every morning and delete residual snapshot tables created more than 24 hours ago and whose corresponding sessions have expired, to prevent storage leaks caused by abnormal logouts.

[0064] S3 constructs an intelligent reward and bonus allocation system, realizing a fully online and automated process from reward allocation scheme generation to distribution and write-back. Figure 4 A detailed flowchart of step S3 provided in an embodiment of the present invention is shown below. Please refer to [link / reference]. Figure 4The detailed construction process is as follows: S31, the configuration of a multi-dimensional dynamic allocation rule engine, allows for the construction of a configurable rule engine in the cockpit backend.

[0065] The rule engine adopts a hybrid expression method that combines decision tables and DRL (Drools Rule Language).

[0066] The decision table is stored in a relational database in the form of a two-dimensional table. The rows of the table define rule instances, and the columns define condition attributes and action attributes.

[0067] The conditional attributes include the type of achievement (invention patent / utility model / software copyright / paper, etc.), achievement level (national / provincial / municipal / municipal / enterprise level), professional field code, and technology maturity level (TRL 1-9). The action attributes are the base bonus and coefficient template identifiers. For rules involving complex logical judgments (such as multi-dimensional condition combination weighting, dynamic allocation of the budget pool, etc.), they are written in DRL rule language and stored in the rule base directory as .drl files, which facilitates fine-grained logical control by senior administrators.

[0068] The decision table and DRL rules share the same working memory and are triggered uniformly during rule evaluation.

[0069] Each rule is explicitly declared with an integer priority value during definition, with larger values ​​indicating higher priority. During rule engine execution, rules are sorted in descending order of priority, with higher-priority rules being matched and triggered first. When multiple rules with the same priority and simultaneously met conditions are triggered, and their actions conflict (e.g., two rules providing different bonus bases), a "later-triggered overrides earlier-triggered" strategy is adopted. This means rules are executed sequentially according to their loading order in the rule base, with the result of the later-executed action overriding the result of the earlier-executed action, and the conflict is recorded in the rule execution log. Furthermore, for the very few scenarios requiring a unique result (e.g., a single achievement can only match one reward level), a "mutually exclusive rule group" configuration is provided. Within the same mutually exclusive group, if any rule is successfully triggered, the remaining rules are automatically skipped and not executed.

[0070] The rule engine incorporates a rule base change listener and a dynamic loader. For decision table rules stored in the database, a scheduled task polls the rule table's version number field (version_no) every 60 seconds. If a version number change is detected, a rule reloading process is automatically triggered: the latest decision table is read from the database and compiled into an executable rule object, replacing the old rule set in the working memory. For DRL files stored in the rule base directory, the JavaNIO file monitoring mechanism (WatchService) listens for file creation, modification, and deletion events in the directory where the .drl files are located. Once a change event is detected, a rule compiler (such as Drools' KieScanner) is invoked to incrementally compile and hot-load the changed DRL file. After loading, the new rules take effect immediately, and the rule engine service remains uninterrupted and requires no restart during the entire hot deployment process. All rule loading and change operations are recorded in the audit log.

[0071] S32 automatically quantifies and calculates the contribution of achievements. Through a data collaboration interface, it automatically obtains structured data such as the list of achievement contributors, authorship order, project roles, and work hours invested from project management systems, human resource systems, etc. It uses a multi-factor linear weighted model to automatically calculate the initial contribution weight for each contributor.

[0072] Specifically, let the set of contributors to the scientific and technological achievement be {P_1, P_2, ..., P_m}. For any contributor P_i, the formula for calculating the contribution weight C_i is as follows:

[0073] Wherein, S_i is the authorship order score, which is calculated based on the rank_i (starting from 1) of the author in the list of authors of the work. In this embodiment, the mapping rule for calculating S_i is: S_i=1.0 when rank_i=1, S_i=0.65 when rank_i=2, S_i=0.40 when rank_i=3, S_i=0.25 when rank_i=4, and S_i=0.10 when rank_i≥5. R_i is the project role coefficient, which is mapped according to a preset role dictionary. In this embodiment, the mapping value for the project leader (including the chief scientist) is 0.40, the mapping value for the core R&D personnel is 0.30, the mapping value for the general R&D personnel is 0.20, and the mapping value for the auxiliary support personnel is 0.10. E_i is the labor input index, calculated using the following formula: , where T_i is the project work hours entered by the contributors during the research and development cycle of this achievement, and T_total is the total project work hours of all contributors; α, β, and γ are the weight coefficients of the three factors, which can be determined by the enterprise's scientific and technological achievements management experts. In this embodiment, the values ​​are α=0.50 (signature order is the core contribution factor), β=0.30 (project role is an important adjustment factor), and γ=0.20 (labor input is an auxiliary correction factor), and the sum of the three is 1.0.

[0074] After assigning values ​​to each factor, the system calculates the initial contribution weight C_i for each contributor using the formula described above, and then performs normalization on the entire set {C_1, C_2, ..., C_m}.

[0075] Make the sum of the contribution weights of each contributor equal to 1.0, and use the normalized weight W_i as the final initial contribution weight.

[0076] If cross-system data conflicts exist (such as discrepancies between the list of contributors in the project management system and the inventors registered in the intellectual property system), a preset data source priority strategy is used for disambiguation: the registration information from the intellectual property system has the highest priority, followed by the project management system, with participation records from the human resources system used as a reference. Higher-priority data sources override lower-priority data sources, and conflict situations and handling results are recorded in the data quality log. Authorized department administrators can fine-tune the normalized weights in the dashboard; each adjustment triggers audit logging, recording the weight values ​​before and after the modification, the person making the modification, and the reason for the modification.

[0077] S33: Reward distribution plan generation. Administrators can initiate the reward distribution process with one click on the results details page in the dashboard. Based on the selected strategy template and coefficients, combined with contribution weights, the proposed allocation amount for each contributor is automatically calculated, generating a pre-distribution plan containing calculation details, and visually displayed in the dashboard in the form of tables and pie charts.

[0078] S34, the pre-allocation plan enters the approval process. The approval process is pre-configured through a graphical designer, and nodes may include submission by the project leader, review by the department's science and technology supervisor, countersignature by the finance department, and approval by the unit leader. Each node has embedded rule checks; for example, if a single person's bonus exceeds the threshold, there is duplicate submission of achievements, or the budget pool balance is insufficient, the system will automatically issue a warning and block the submission.

[0079] The graphical designer is implemented based on the BPMN 2.0 standard and uses a front-end canvas (based on SVG / Canvas technology) to provide a drag-and-drop node orchestration interface. The designer's built-in node components include start event nodes, user task nodes (approval nodes), mutual exclusion gateways (conditional branches), parallel gateways (countersigning), and end event nodes. Administrators complete the topology modeling of the approval process by dragging node components from the toolbar to the canvas and connecting directed lines between nodes. After modeling, the designer serializes the process topology structure in the canvas into an XML format process definition file conforming to the BPMN 2.0 standard and stores it in the process definition table of the database. The core fields in the process definition table include process definition ID, process name, version number, XML content, activation status, and effective time. Each modification to the process topology generates a new version record. Running approval instances continue to use the previous version, while newly initiated approval tasks automatically use the latest version, achieving a smooth upgrade of the process definition.

[0080] Each approval node can be bound to a set of rule validators during configuration. When the approver clicks "Approve," the system executes all validators bound to that node sequentially. Submission is only allowed after all validators pass. The pre-defined list of validation items includes: Single-person bonus threshold verification: Verify whether the bonus amount for any single person in this allocation exceeds the preset single-person bonus limit (the limit is configured according to the company's salary system). If it exceeds the limit, the submission will be blocked and the person who exceeded the limit will be highlighted. Duplicate submission verification: Verify whether the currently pending achievement already exists in the "Awarded Achievements" list. If the achievement has already been allocated a prize within the award period, it is determined to be a duplicate submission, the submission is blocked, and the time and amount of the most recent award allocation are displayed. Budget pool balance verification: Verify whether the total amount allocated this time exceeds the remaining budget amount for the current budget period. If it exceeds, the submission will be blocked and the current total budget amount, allocated amount and remaining available amount will be displayed. Verification of the attribution of the completed work: Verify whether all the workers who completed the work to be assigned are currently employed by the company (queried in real time through the human resources system interface). If there are any workers who have left or been transferred, the submission will be blocked and a list of abnormal personnel will be generated, prompting the administrator to confirm their eligibility for the reward. Data integrity verification: Verify whether the name, employee number, department, and payment account information of each person completing the allocation plan are complete. If any information is missing, the submission will be blocked and the specific missing field will be displayed.

[0081] Each approval node is configured with an approval time limit, which is adjustable and defaults to 48 hours (starting from when the task arrives at the approver's task center). The system has a built-in Quartz scheduled task that scans the task dwell time at each approval node every 15 minutes. When the dwell time at an approval node reaches 80% of the time limit, a reminder is sent to the approver via the enterprise instant messaging tool, including the link to the pending task and the remaining time limit. When the dwell time reaches 100% of the time limit, a timeout processing flow is triggered, automatically sending another reminder to the approver and a timeout alarm to the approver's immediate supervisor. If no action is taken after 12 hours (i.e., a cumulative dwell time of 60 hours), the system automatically executes processing actions according to a preset timeout strategy, which includes two selectable modes: Automatically skip the current node and proceed to the next approval node; The application is automatically rejected by the initiator, ending the approval process.

[0082] The timeout policy is selected during process definition configuration and cannot be modified online after selection; changes can only be made with a new version of the process definition. All timeout events, reminder records, and automatic processing actions are fully written to the audit log.

[0083] S35, with its allocation execution and cross-system closed-loop mechanism, automatically pushes a bonus distribution instruction with an electronic signature (including the payee's employee number, amount, and account code) to the financial system via a unified data service interface after all approvals are complete. Simultaneously, it writes the individual's science and technology award record to the human resources system and updates the "awarded" status of the achievement to the project management system. Upon completion of the allocation, an electronic allocation voucher with an anti-counterfeiting code is automatically generated and archived in the achievement's electronic file. Indicators such as remaining budget and allocation progress in the dashboard are updated in real time.

[0084] S4 establishes a cross-business system data collaboration and flow mechanism, opens up data links between enterprise technology innovation-related business systems, and realizes automatic data association and synchronization.

[0085] Specifically, in terms of technology architecture selection, RocketMQ is used as the message middleware to support the event-driven architecture, leveraging its high throughput and low latency to achieve decoupling between systems. The message topic segmentation strategy is as follows: top-level topics are divided according to business domains, such as "Scientific and Technological Achievement Management Topic", "Project Completion Topic", and "Intellectual Property Topic"; under each topic, tags are divided according to event type, such as "Project Status Change", "Patent Authorization Notice", and "Bonus Payment Completed", to achieve precise filtering on the consumer side.

[0086] To ensure reliable message delivery, a transactional messaging mechanism is employed. While executing a local database transaction (e.g., updating a project status to "completed"), the enterprise business system sends a "partial message" to the message queue. Only after the local transaction is successfully committed does the enterprise business system send an acknowledgment command to the message queue, converting the "partial message" into a consumable message. If the local transaction fails, no acknowledgment command is sent, and the message queue automatically rolls back and deletes the message, thus ensuring the atomicity of business operations and message sending. Furthermore, to ensure the sequential delivery of change messages related to the same business object (such as the same project ID), the primary key of the business object (e.g., project number) is used as the message sharding key when sending messages. This ensures that messages with the same key value enter the same message queue partition and are processed sequentially by the same consumer instance.

[0087] At the data interaction level, a standardized data change event message format is defined. This message format uses JSON or Protobuf serialization, and its specific structure definition includes: Event header: contains a unique event identifier, event type (such as CREATE, UPDATE, DELETE), event timestamp, and source system identifier; Event body: Contains the primary key, change type, a snapshot of the data before the change, and the complete data content after the change. For example, for the "patent grant" event, the event body includes key fields such as patent number, grant date, and certificate attachment address, for subscribers to parse and use.

[0088] For distributed transaction processing in cross-system data synchronization, the Saga pattern (long-lived transaction pattern) is adopted to ensure eventual data consistency. When multiple systems are involved in linked updates (such as "project completion" triggering "result registration" which then triggers "reward calculation"), the overall business process is broken down into a series of local sub-transactions. After each sub-transaction is completed, a corresponding event is published to trigger the next sub-transaction. If a step in the process fails, the system executes a series of compensation transactions in reverse according to a predefined compensation strategy (such as rolling back the generated reward calculation results and marking the result registration status as "abnormal") to eliminate the impact of the executed steps and eventually bring the data of each system back to a consistent state.

[0089] Through the aforementioned mechanism, the achievement management system is connected to the project management system, intellectual property management system, financial system, and human resources system. When any system generates a business action related to scientific and technological achievements (such as a project status changing to "completed," a patent status changing to "authorized," or a bonus being successfully distributed), that system publishes a standardized data change event through a pre-defined interface. The scientific and technological achievement management platform subscribes to these events and automatically triggers corresponding data integration or status write-back operations based on the event type. For example, upon detecting a "bonus successfully distributed" event from the financial system, it automatically updates the achievement's reward status to "distributed" and records the distribution time and voucher number. Simultaneously, the platform provides a unified data service interface, offering query services externally in the form of a RESTful API, supporting external systems in accessing standardized achievement data and indicator data.

[0090] S5 constructs a full-link hierarchical permission control and audit traceability mechanism, configures system roles and data permissions according to user roles, and leaves full traces of key operations such as data synchronization, configuration modification, and reward allocation, supporting multi-dimensional log retrieval and structured export. Figure 5 A detailed flowchart of step S5 provided in an embodiment of the present invention is shown below. Please refer to [link / reference]. Figure 5 The specific steps are as follows: S51 employs a role-based access control (RBAC) model combined with row-level data filtering in its access control model. Multiple roles are pre-defined based on the company's internal personnel system, such as system administrator, technology manager, department administrator, finance personnel, and general users.

[0091] The implementation of permission checks is primarily handled at the application layer using AOP (Aspect-Oriented Programming) interceptors. When a user initiates a request, the interceptor parses the user's role information within the context and matches it against pre-defined permission rules. For row-level data permissions (e.g., department administrators can only view data within their own department), filtering conditions are dynamically injected when constructing the database query statement (SQL) (e.g., appending WHERE department_id = current_user.dept_id) to control the scope of data access from the source. For field-level data permissions (e.g., finance personnel can only view amount fields), before the data is returned to the front end, non-authorized fields are masked or anonymized using reflection mechanisms based on the field permission configuration. For example, the technology manager is configured to have viewing permissions for all unit data and modification permissions for allocation coefficients, while finance personnel are configured to have "read" permissions only for amount-related fields and "hide" permissions for other sensitive fields.

[0092] S52, Operation Traceability and Log Tracking: To connect audit logs scattered across various modules (such as the dashboard, reward allocation, and data synchronization) into a complete operational chain, this method introduces a global process trace ID. At the entry point where a user initiates a request (such as the gateway or controller layer), a unique trace ID is automatically generated and passed through to the service layer, data access layer, and asynchronous message processing thread using thread context technology. All operations that record audit logs are automatically associated with this trace ID, thereby enabling cross-module and cross-service log association queries and reconstructing the complete business execution path.

[0093] In terms of log storage and retrieval architecture, the audit database uses the Elasticsearch distributed search engine for storage to handle high-concurrency writes and complex multi-condition retrieval requirements. Audit logs contain full information including global trace ID, operator, operation time, IP address, operation type, operation module, and data snapshots before and after the operation.

[0094] The log retention policy is configured as a three-tier storage system: active logs from the most recent 6 months are stored on Elasticsearch hot nodes, supporting millisecond-level retrieval; logs from 6 months to 2 years are migrated to warm nodes or archive databases, supporting only standard queries; logs older than 2 years are cold-backed up or destroyed according to compliance requirements.

[0095] To ensure log tamper-proof security, a digital digest mechanism is introduced. When each audit log is entered into the database, a SHA-256 digital digest is generated based on its content, and the digest value is stored in a separate tamper-proof table. Any subsequent query or audit operation on the log recalculates the content digest and compares it with the stored value; if a discrepancy is found, an alert is triggered. For core and sensitive operation logs, blockchain notarization technology is preferred, storing the log digest on the blockchain to provide legally valid proof using the immutability of blockchain.

[0096] S53, Data Change Tracking and Rollback: For every data change in the standardized deliverables data pool, a snapshot of the data version before the change is saved to the historical version table. When data errors occur or auditing is required, administrators can view any historical version on the data details page and perform a rollback operation to restore the data to the specified version. The rollback operation itself is also recorded in the audit log.

[0097] The specific collaborative relationships among the five main steps S1 to S5 in this application are as follows: Regarding data flow, the standardized results data pool constructed in step S1 serves as the single data source for the entire solution. Step S2 directly reads pre-aggregated data (such as the DM layer summary table) from the data pool through a unified data service interface to support the dashboard's indicator display. When a user triggers a reward allocation request in the dashboard interface of step S2, step S3 obtains detailed information, completer details, and historical data of the corresponding results from the data pool through the unified data service interface. After step S3 completes the approval and generation of the reward allocation scheme, the generated bonus distribution instructions and personnel reward data are transferred to the external financial and human resources systems through the event-driven architecture (such as a message queue) defined in step S4. At the same time, step S4 synchronously returns the external execution receipts (such as the distribution success status) back to the data pool for steps S2 and S3 to read and update.

[0098] In terms of control flow, the layered interactive cockpit built in step S2 serves as a unified front-end interaction entry point, receiving user business instructions. The "reward allocation" operation initiated by the user in step S2 acts as a control signal, synchronously calling the intelligent allocation processing system in step S3 to initiate the corresponding business process. When step S3 executes the approval process, any status changes (such as approval passed or rejected) are fed back to step S2 in real time through callback notifications or event subscription mechanisms, driving the cockpit interface to update the corresponding status indicators and progress bars. The end-to-end hierarchical permission control mechanism built in step S5 serves as a control cross-section throughout the entire process. Before the data access request in step S1, the data query and rendering request in step S2, the weight adjustment and approval submission request in step S3, and the cross-system interface call request in step S4 reach the processing logic, permission verification is performed. Only when the permission verification passes is the corresponding operation allowed.

[0099] Regarding the timing relationship, the order of operations and triggering conditions of each module are as follows: Step S1, as a basic service, adopts an asynchronous background continuous running mode, capturing source system data in real time or periodically and updating the standardized results data pool to provide the latest data foundation for other steps; Step S2 is in a front-end persistent state, responding to users' immediate query and visualization requests, and its data loading depends on the data update of Step S1; The business process of Step S3 does not have the ability to trigger autonomously and must be synchronously triggered by specific business operations of users in Step S2 (such as clicking "Generate Solution"). The execution of Step S3 will read the data pool snapshot at the current moment; The cross-system synchronous operation of Step S4 is asynchronously triggered by the business event of Step S3 (such as "Approval Passed"), or is triggered in reverse when Step S1 captures changes in source system data. The data changes generated after the execution of Step S4 will trigger the data integration process of Step S1 again, thereby forming a closed-loop flow of data between multiple systems and ensuring eventual consistency.

[0100] Step S5 is a cross-cutting mechanism that runs through the entire process in terms of timing. It is embedded in the execution cycle of each operation in steps S1 to S4. When any module in steps S1, S2, S3 or S4 receives an external request or is triggered by an internal event, the permission verification logic of step S5 is triggered synchronously and executed first as a prerequisite for the operation. Only after the permission verification is passed can the subsequent business logic be executed. During and after the execution of the business logic, the audit log recording operation of step S5 occurs synchronously or asynchronously, realizing real-time traceability of the entire chain operation and ensuring that the timing actions of all modules are monitored and traceable.

[0101] Example 2 The following describes the collaborative operation of the technical solution of the present invention in actual operation, using a complete business process embodiment as an example. This embodiment covers the entire closed loop from business triggering, data collection, dashboard presentation, reward allocation to cross-system synchronization and audit archiving. The specific steps are as follows: Step 1: Business Triggering and Pre-Trial Validation. When scientific and technological achievement data is updated, a reward allocation task is initiated, or a user accesses the dashboard through a browser, the corresponding business process is automatically triggered. First, pre-trial validation is performed. This validation includes: the connectivity of data interfaces with multi-source business systems, the current user's role and data access permissions, and, if it's a reward allocation task, whether the required basic information (such as master achievement data and participant information) is complete. If any pre-trial condition is not met, the dashboard user interface returns a clear error message and aborts the process. Re-triggering is supported once the conditions are met.

[0102] Step 2: Load the currently effective configuration rules. This step reads all configuration rules in effect at the current time. This rule set specifically includes: multi-source heterogeneous data source access configuration, data cleaning, deduplication and quality governance configuration, indicator configuration rules (including indicator calculation rules, data standards and dimension configurations), reward allocation, and permission configuration rules. After the configuration rules are loaded, a consistency check is automatically performed to check for logical conflicts between rules and whether all parameters are within the preset reasonable range. If the check passes, proceed to the next stage; if the check fails, an error log is recorded, and the system administrator is notified through the dashboard's warning channel for correction.

[0103] Step 3: Multi-source data aggregation and standardization. Based on the data access configuration, initiate the data integration process. Retrieve corresponding data from related business systems such as project management, intellectual property management, and human resources through batch extraction channels or real-time synchronization channels based on database logs. Next, perform data cleaning and standardization: First, deduplicate the original data using a multi-level matching strategy, fill in null values ​​in key fields, and standardize the format. Then, call the standard dictionary service to uniformly map and escape fields such as professional domain labels, unit level codes, and result type classifications. Finally, write the processed standardized data into the standardized result data pool. During this process, if data synchronization fails, an exception log is automatically recorded and a retry mechanism is triggered. After a preset number of consecutive failed retries (e.g., 3 times), the system reports the exception to the dashboard and notifies management personnel for intervention.

[0104] Step 4: Cockpit Indicator Calculation and View Generation. The cockpit's hierarchical aggregation calculation model is based on a standardized results data pool. Following the indicator configuration rules loaded in Step 2, it automatically calculates core indicators for each dimension, including but not limited to total results indicators, distribution indicators, historical trend indicators, and conversion efficiency indicators. During the calculation, the feature extraction layer performs four-way parallel feature extraction, the indicator aggregation layer executes global aggregation and dimension drill-down aggregation, and simultaneously executes anomaly detection logic. Based on the current user's role and permission context, the system automatically matches the corresponding cockpit view template, rendering the indicator data into visual charts and generating a cockpit page with interactive functions such as filtering and drill-down. For detected abnormal fluctuation indicators, the system automatically highlights them and generates anomaly prompts. This access uses a snapshot mechanism to ensure the consistency of indicator data during the operation.

[0105] Step 5: Reward Allocation Task Initiation and Template Matching. The administrator initiates a reward allocation task on the dashboard's results details page. Based on the type of result to be allocated and the preset reward strategy template, the corresponding allocation scheme template and verification rule set are automatically matched. The dashboard supports users importing allocation data in batches via templates: users download the template, fill it out, and upload it. The imported file is received and its format is parsed and preliminarily verified. If the file format is inconsistent, it is rejected directly with the specific reason provided.

[0106] Step 6: Intelligent Validation and Error Correction. The system invokes the approval process within the intelligent reward and bonus allocation system to perform a full intelligent validation of the imported allocation data. The validation process sequentially performs field format validation, business rule validation (such as whether a single person's bonus exceeds the threshold, whether there are duplicate applications), and consistency validation with the information of the contributors in the standardized results data pool. For data entries that fail validation, the system marks the error type and provides modification suggestions, and generates an online validation report. Users can modify erroneous data online through the interface. After modification, the system re-triggers incremental validation in real time until all data passes validation.

[0107] Step 7: Confirmation and Result Issuance of Allocation Scheme. After all data has passed verification, a complete pre-allocation scheme preview is generated in the cockpit interface, including the proposed allocation amount and calculation details for each participant. Users can make final manual adjustments and confirmations at this stage. After confirmation, the issuance command is submitted, the reward ledger is automatically updated, and the allocation information is synchronously written into the full lifecycle archive of the corresponding achievement through a data collaborative flow mechanism. Simultaneously, the cockpit supports batch export and printing of allocation results.

[0108] Step 8: Cross-system data synchronization and flow. At key business nodes such as data collection completion and reward allocation issuance, cross-system data synchronization is automatically triggered. Through message queues and a unified data service interface, modified outcome data or reward distribution instructions are pushed to related systems such as the intellectual property business management platform, project management system, and financial system. Processing receipts are received from each system, and incremental and full synchronization collaboration mechanisms ensure eventual consistency of cross-system data. If a synchronization failure occurs, retry is automatically performed, and exceptions are logged.

[0109] Step 9, Permission Verification and Operation Auditing: Before execution, each step of the entire process undergoes permission verification by a full-link hierarchical permission control mechanism to ensure that user operations are within the scope of their granted permissions. Every critical operation, including but not limited to rule configuration modification, manual data correction, contribution weight adjustment, approval submission, and data rollback, synchronously invokes the audit traceability mechanism, writing detailed information such as the operation subject, operation time, operation content, and snapshots before and after data changes into the audit log. The logs are stored in an independent, tamper-proof storage area, supporting multi-dimensional retrieval and structured export, achieving full traceability.

[0110] Step 10: Results Output and Archiving. The dashboard page supports the export of indicator data and charts for offline analysis. After the reward allocation is completed, an electronic allocation voucher with anti-counterfeiting code is automatically generated and archived in conjunction with the electronic results file. All business data and operation logs are archived regularly according to a preset data retention strategy to ensure data security and long-term traceability.

[0111] The above embodiments are merely descriptions of preferred embodiments of the present invention and are not intended to limit the scope of the present invention. Various modifications and improvements made by those skilled in the art to the technical solutions of the present invention without departing from the spirit of the present invention should fall within the protection scope defined by the claims of the present invention.

Claims

1. A method for cross-system integration and intelligent allocation management of scientific and technological achievement data, characterized in that, Includes the following steps: S1. Construct an automatic integration mechanism for multi-source heterogeneous scientific and technological achievement data, configure differentiated data access channels to perform automatic cleaning, deduplication, and standardized transformation based on a unified data model on the accessed multi-source heterogeneous scientific and technological achievement data, and construct a standardized achievement data pool with physical hierarchical storage. S2, Construct a hierarchical and interactive technology achievement management dashboard. Based on the standardized achievement data pool, use a hierarchical aggregation calculation model to perform multi-dimensional indicator calculation and visualization. Respond to the reward allocation operation command initiated by the user in the dashboard and call the intelligent reward and bonus allocation processing system. S3. Construct an intelligent allocation and processing system for rewards and bonuses. The intelligent allocation and processing system calculates the initial contribution weight based on a multi-dimensional dynamic allocation rule engine and contribution correlation information automatically extracted from the standardized results data pool. It automatically generates a reward allocation scheme containing calculation details and executes an online multi-level approval process with an embedded budget threshold verification and allocation anomaly early warning mechanism. S4. Construct a cross-business system data collaborative flow mechanism. After the multi-level approval process is completed, based on the event-driven architecture, push the reward allocation results to the external related business system through a unified data service interface, and receive the execution receipt from the external related business system to synchronously update the result status in the standardized result data pool. S5. Construct a full-link hierarchical permission control and audit traceability mechanism. Configure system roles and data permissions according to the principle of role-based permission separation. Implement field-level permission control for the data access, indicator calculation, reward allocation and data synchronization processes in steps S1 to S4. Use the global process tracking ID to connect the operation logs scattered in various modules into a complete audit link.

2. The method for cross-system integration and intelligent allocation management of scientific and technological achievement data according to claim 1, characterized in that, The automatic integration mechanism for constructing multi-source heterogeneous scientific and technological achievement data includes: The differentiated data access channels establish a synchronization mechanism that integrates timed batch extraction and real-time incremental capture based on database logs for structured data; and an aggregation mechanism that integrates secure file transmission and automatic metadata extraction for unstructured files. For the original scientific and technological achievement data stream that has been connected, the following steps are performed in sequence: format normalization and outlier handling, calling the content parsing service to extract structured information from unstructured files, and using a multi-level matching strategy to remove duplicate data. Configure a dynamic field mapping engine and standard dictionary service to map the managed multi-source heterogeneous data to fields and escape values ​​according to a preset unified data model, and build a standardized results data pool with physical hierarchical storage based on the core business primary key.

3. The method for cross-system integration and intelligent allocation management of scientific and technological achievement data according to claim 1, characterized in that, The aforementioned hierarchical and interactive technology achievement management dashboard adopts a multi-dimensional achievement indicator calculation model. The model employs a hierarchical aggregation calculation architecture, including an input layer, a feature extraction layer, an indicator aggregation layer, a visualization rendering layer, and an output layer. The input layer receives raw data, user context information, and indicator configuration rules from the standardized results data pool, and then passes them to the feature extraction layer after performing format verification and permission filtering. The feature extraction layer performs parallel feature extraction on the input data, including at least the extraction of basic feature of results, conversion efficiency feature, time series feature and reward-related feature; The index aggregation layer aggregates and calculates the features output by the feature extraction layer, generates a standardized index set according to the configured index formula, and executes anomaly detection logic. The visualization rendering layer is used to automatically match visualization components according to the view configuration to complete chart rendering and page layout; The output layer returns the rendered page to the front end of the technology achievement management dashboard and writes the calculation process and results into the audit log and data cache.

4. The method for cross-system integration and intelligent allocation management of scientific and technological achievement data according to claim 1, characterized in that, The intelligent allocation and processing system for rewards and bonuses includes a multi-dimensional dynamic allocation rule engine, which is used to preset the base bonus amount based on the achievement attributes and set multiple adjustable allocation coefficients to form differentiated allocation strategy templates. Based on the standardized results data pool and cross-system collaborative data, the contribution correlation information of the results completers is automatically collected, and the initial contribution weight is calculated according to the preset algorithm. The rule engine and contribution weight are invoked to automatically generate a reward distribution scheme containing calculation details, and a configurable multi-level approval process is initiated, with budget threshold verification and allocation anomaly warning mechanism embedded in the process. After approval, instructions are automatically sent to the relevant business systems through the unified data service interface, triggering bonus distribution, synchronization of individual reward records, and writing back the achievement status. The allocation status and indicators are then fed back to the technology achievement management dashboard for display.

5. The method for cross-system integration and intelligent allocation management of scientific and technological achievement data according to claim 4, characterized in that, The initial contribution weight is calculated using a multi-factor linear weighted model. For any contributor to a scientific and technological achievement, the contribution weight is calculated by weighting the score based on the authorship order, project role coefficient, and working hours input index. The weights of all contributors are then normalized.

6. The method for cross-system integration and intelligent allocation management of scientific and technological achievement data according to claim 1, characterized in that, The mechanism for building cross-business system data collaboration and flow includes: An event-driven architecture is adopted, and a standardized data change event message format is defined. The message format includes an event header and an event body. The event header contains a unique event identifier, event type, event occurrence timestamp, and source system identifier. The event body contains the data primary key, change type, and change content. Utilize message middleware to support an event-driven architecture, divide message topics according to business domains, and label them according to event types to achieve precise filtering on the consumer side; Through a unified data service interface, the reward allocation results are synchronously pushed to external related business systems, and the execution receipts from the external related business systems are received to synchronously update the result status in the standardized result data pool.

7. The method for cross-system integration and intelligent allocation management of scientific and technological achievement data according to claim 1, characterized in that, The method also includes configuring a multi-source data collaboration and consistency guarantee mechanism, which includes at least one or more of the following: a real-time data change synchronization mechanism, a cockpit access snapshot mechanism, a cross-system bidirectional verification mechanism, an incremental synchronization and full synchronization collaboration mechanism, and a data change tracking and rollback mechanism.

8. The method for cross-system integration and intelligent allocation management of scientific and technological achievement data according to claim 1, characterized in that, The established end-to-end hierarchical access control and audit traceability mechanism includes: A strategy combining role-based access control and row-level data filtering is adopted, and system roles and data permissions are configured according to user roles. A global process tracking ID is introduced, which generates a unique tracking ID when a user initiates a request and transmits it to each processing module, thus linking the operation logs scattered across various modules into a complete audit chain. Audit logs are stored in a distributed search engine and employ a three-tiered storage strategy, generating digital digests of the log content to ensure tamper-proof protection.

9. The method for cross-system integration and intelligent allocation management of scientific and technological achievement data according to claim 1, characterized in that, The standardized results data pool adopts a three-tier physical storage architecture, including: The operational data storage layer is used to store copies of the raw data directly accessed from various source systems; The data warehouse layer adopts a hybrid modeling approach that combines star schema and snowflake schema, including fact tables and dimension tables; The data mart layer aggregates and stores data by subject domain, and pre-builds summary tables and materialized views for cockpit query scenarios.

10. A method for cross-system integration and intelligent allocation management of scientific and technological achievement data according to any one of claims 1 to 9, characterized in that, The method also includes, when initiating a reward allocation task on the achievement details page of the technology achievement management dashboard, first performing a precondition verification, the verification content including data interface connectivity, operation user permissions and basic information integrity, after the verification passes, loading the currently effective configuration rules, including data access configuration, indicator configuration rules, reward allocation rules and permission configuration rules, and performing rule consistency verification.

Images