A role-based multi-dimensional performance management system and method

Abstract

This invention provides a role-based multi-dimensional performance management system and method, relating to the field of enterprise information management technology. The system includes configuring functional permissions and data permission rules based on user roles; generating data filtering conditions based on the data permission rules corresponding to user roles and the organizational dimension field in core business data records to limit the data scope accessible to user roles; obtaining performance appraisal schemes configured for at least one user role; collecting business data from related business modules based on data source identifiers; and calculating and generating performance results according to scoring formulas. When key data affecting performance results changes, a change record is generated, the historical version of the original record is retained, and a confirmation process is triggered. Upon confirmation, the performance results are updated; upon rejection, the performance results before the change are maintained. This invention enables data permission control for different user roles, performance result calculation, and result management after changes to key data.

Description

Technical Field

[0001] This invention relates to the field of enterprise information management technology, and in particular to a role-based multi-dimensional performance management system and method. Background Technology

[0002] As enterprises increasingly adopt information systems, more and more companies are managing customers, projects, finances, human resources, and daily business processes. Currently, companies typically deploy corresponding management modules or systems around different business scenarios to achieve functions such as business data entry, approval processes, result statistics, and business analysis. Simultaneously, to evaluate the performance of employees or departments, some companies also set performance appraisal rules based on business data from projects, sales, operations, and finance, and generate performance results accordingly.

[0003] In practical applications, performance management typically relies on data generated by multiple business modules. The assessment indicators, data sources, and scoring logic often differ across positions and roles. While some existing management systems offer functions such as access control, data querying, and performance statistics, they still suffer from insufficient coordination in areas like data access scope control, differentiated performance scheme configuration, and automatic performance data acquisition. For example, the accessibility of business data for different user roles may need to be determined jointly by factors such as department, manager, project, or region. However, existing systems often employ rather coarse-grained methods for controlling data access, making it difficult to simultaneously address the data isolation and management viewing needs of different roles. Furthermore, performance evaluation often requires extracting relevant data from multiple business modules. Without a unified configuration and calculation mechanism, issues such as excessive manual processing, inconsistent statistical standards, or untimely results updates can easily arise.

[0004] Furthermore, in performance management scenarios, some business data may still be modified after generation due to business adjustments, changes in ownership, or information corrections. When this type of data is associated with performance results, data changes may further affect existing performance results. In existing technologies, the common approach to modifying such critical data is to directly update the original records or retain only limited operation log information, thus failing to fully reflect the data content before and after the change, the reasons for the change, and its impact on performance results. When it is necessary to review, retrospectively examine, or verify responsibility for performance results, there is often a lack of clear and reliable evidence.

[0005] Therefore, the existing technology still needs further improvement. Summary of the Invention

[0006] To overcome the shortcomings of existing technologies, the technical problem to be solved by this invention is to propose a role-based multi-dimensional performance management system and method, employing the following technical solution: This invention provides a role-based, multi-dimensional performance management method, comprising: S1: Configure function permissions and data permission rules according to user roles; S2: In response to a data query request, obtain the user role that initiated the request, and generate data filtering conditions based on the data permission rules corresponding to the user role and the preset organization dimension fields in the core business data records to limit the range of data that the user role can access. S3: Obtain the performance evaluation scheme configured for at least one user role. The performance evaluation scheme includes at least one performance indicator, as well as the target value, weight, scoring formula and data source identifier associated with the performance indicator. S4: Based on the data source identifier in the above performance appraisal scheme, collect business data from the corresponding related business modules, and calculate and generate performance results according to the scoring formula corresponding to each performance indicator; S5: In response to changes to key data affecting the above performance results, generate a change record containing the changes, retain the original record of the key data as a historical version, and trigger a confirmation process for the above change. S6: Receive feedback information regarding the above confirmation process. When the above change operation is confirmed, use the changed key data to update the above performance results; when the above change operation is rejected, maintain the performance results before the change.

[0007] In the above technical solution, by configuring functional permissions and data permission rules according to user roles, and generating data filtering conditions by combining organizational dimension fields when responding to data query requests, different user roles can be assigned different data access scopes, thus matching the viewing and use of business data with user roles and responsibilities. Furthermore, by configuring a performance appraisal scheme for at least one user role, including performance indicators, target values, weights, scoring formulas, and data source identifiers, and collecting business data from related business modules for performance calculation based on the data source identifiers, different user roles can be assigned different performance appraisal standards and result generation methods, allowing performance results to be determined in conjunction with specific job responsibilities and business data sources. Simultaneously, when key data affecting performance results changes, by generating change records, retaining historical versions of the original records, and triggering a confirmation process, performance results are updated using the changed key data after the change operation is confirmed. If the change operation is rejected, the performance results before the change are maintained, preventing uncontrolled impacts on existing performance results from being directly overwritten by key data. This creates a seamless processing chain between data access control, performance scheme configuration, business data collection and calculation, and critical data change handling. This helps improve the targeting of performance management for different roles, the controllability of data processing, and the accuracy and reliability of performance results.

[0008] As a further improvement, in response to changes to key data affecting the aforementioned performance results, a change record containing the changed information is generated, and a confirmation process for the aforementioned change operation is triggered, including: Based on the pre-established performance dependency mapping relationship, identify the set of performance objects and the set of indicators that are affected by the change operations of the above key data; The aforementioned performance dependency mapping relationship is used to characterize the association between performance indicator identifiers, data source identifiers, scoring formula identifiers, user role identifiers, and assessment cycle identifiers.

[0009] In the above technical solution, by pre-establishing performance dependency mapping relationships, the correspondence between performance indicators, data sources, scoring formulas, user roles, and assessment cycles is pre-linked. When key data changes, the affected set of performance objects and indicator sets can be identified accordingly. This avoids indiscriminate processing of all performance objects and indicators after each data change, allowing for targeted adjustments based on the actual scope of impact. This improves the specificity of change handling and provides a clear basis for subsequent confirmation, updates, and recalculations.

[0010] Further improvements include: For the aforementioned set of affected performance objects, generate a candidate performance snapshot corresponding to the change operation of the aforementioned key data in addition to the performance results before the change, and set the aforementioned performance result snapshot before the change to read-only status.

[0011] In the above technical solution, after identifying the set of affected performance objects, the original performance results are not immediately replaced with the changed data. Instead, a candidate performance snapshot corresponding to the current key data change operation is generated in addition to the performance results before the change, and the snapshot of the performance results before the change is set to read-only. In this way, the performance result states before and after the change can be stored separately, allowing the candidate results in the pending confirmation state to coexist with the original valid results. This helps to avoid overwriting the original performance results before confirmation is completed and provides a basis for subsequent comparison, verification, and rollback.

[0012] As a further improvement, when the aforementioned change operation is confirmed, the changed key data will be used to update the aforementioned performance results, including: When the above change operation is confirmed, incremental recalculation is performed only for the above-mentioned affected performance object set and indicator set, and the above performance results are updated according to the data differences before and after the above-mentioned key data changes; When the aforementioned change is rejected, the performance results prior to the change will be maintained, including: When the above change operation is rejected, the above candidate performance snapshot is deleted, and the performance results before the change are maintained as the current valid performance results.

[0013] In the above technical solution, when a change operation is confirmed, incremental recalculation is performed only on the affected set of performance objects and indicators, rather than recalculating all performance results. This ensures that the performance update process corresponds to the scope of the data change's impact, thereby reducing unnecessary duplication of processing. When a change operation is rejected, deleting candidate performance snapshots and maintaining the pre-change performance results as the current valid performance results prevents unconfirmed data changes from entering the final performance results. Therefore, this approach helps improve processing efficiency while ensuring the accuracy of performance result updates, and maintains the stability and controllability of the result status.

[0014] As a further improvement, the above-mentioned generation of change records containing the changed content includes: For the changes to the aforementioned key data, generate a change record containing the summary values ​​of the previous record and the current record. The current record summary value is generated based on at least the previous record summary value, operator identifier, operation time, data content before change, data content after change, change reason information, and the set of affected performance objects, so that each change record can establish a connection between the previous and subsequent records based on the summary value, and support the verification and traceability of the change process.

[0015] In the above technical solution, by generating a change record containing the summary values ​​of the preceding and current records for each change operation on key data, and associating the current record summary value with the summary values ​​of the preceding records and the relevant content of this change, a correspondence can be established between multiple change records. This allows for verification and tracing of the change order, content, and source based on the relationships between the change records during subsequent verification of the key data modification process, thereby enhancing the verifiability of the key data change process and the reliability of the results.

[0016] As a further improvement, the data filtering conditions generated above, based on the data permission rules corresponding to the user roles and the preset organizational dimension fields in the core business data records, include: The system retrieves the data permission rules corresponding to the user roles mentioned above from the permission management center, and dynamically converts these data permission rules into filter clauses in the database query statement to perform data filtering on the core business data records at the database level.

[0017] In the above technical solution, by obtaining the data permission rules corresponding to user roles from the permission management center and dynamically converting these rules into filter clauses in the database query statement, the limitation of data access scope can be directly applied to the database query process. Compared to manual filtering or upper-level filtering after the query results are returned, this method can directly restrict data that does not conform to the permission scope during data access, which helps to improve the accuracy of data access control for users with different roles and reduces the occurrence of irrelevant data in the result set.

[0018] As a further improvement, the above-mentioned organization dimension fields include at least one or a combination of the following: department identifier, person in charge identifier, project in charge identifier, and region identifier; When the above user roles are configured to have global permissions, the above data filtering conditions allow access to all core business data records. When the user role does not have global permissions, the data filtering conditions are determined by the values ​​of one or more of the organization dimension fields.

[0019] In the above technical solution, the organization dimension field can be set to at least one or a combination of identifiers such as department, person in charge, responsible project, and region, according to actual business management needs. For user roles with global permissions, access to all core business data records is permitted; for user roles without global permissions, their access scope is determined by the values ​​of one or more organization dimension fields. In this way, data access control can adapt to both the management's need for viewing global data and the access needs of ordinary or local management roles for local business data, thereby improving the flexibility and adaptability of data access control.

[0020] As a further improvement, the above-mentioned acquisition of performance evaluation schemes configured for at least one user role includes: A preset performance indicator library is provided, which stores multiple candidate performance indicators; Receive the scheme configuration instruction initiated by the administrator for at least one user role, select the target performance indicators from the above performance indicator library, and set the corresponding target value, weight, scoring formula and data source identifier for each selected target performance indicator to generate the above performance appraisal scheme.

[0021] In the above technical solution, by pre-setting a performance indicator library and selecting target performance indicators from the library after receiving a scheme configuration instruction from the administrator, and then setting the target value, weight, scoring formula, and data source identifier respectively, different performance appraisal schemes can be assigned to different user roles. In this way, performance indicators and their calculation methods are no longer fixed to a single model, but can be configured according to different positions, responsibilities, or management requirements. This improves the flexibility of performance scheme configuration and ensures a better correlation between performance results and actual business responsibilities.

[0022] As a further improvement, the above-mentioned data source identifier is used to collect business data from the corresponding related business modules, and performance results are calculated and generated according to the scoring formula corresponding to each performance indicator, including: Through the data platform, business data is collected from the aforementioned related business modules based on the aforementioned data source identifiers; The scoring formula above is executed through a rules engine or a custom script to calculate the scores for each performance indicator and the overall performance score. The aforementioned data collection is triggered by background scheduled tasks or message queue mechanisms.

[0023] In the above technical solution, by collecting business data from related business modules based on data source identifiers through a data platform, and executing scoring formulas through a rule engine or custom scripts, a clear correspondence can be established between performance calculation and the source of business data. Furthermore, by triggering business data collection through background scheduled tasks or message queue mechanisms, the acquisition of business data and the performance calculation process can be automated, thereby reducing the involvement of manual data processing and calculation, and improving the timeliness of performance data acquisition and the consistency of the performance calculation process.

[0024] This invention also proposes a role-based multi-dimensional performance management system, which applies the role-based multi-dimensional performance management method proposed above, including: A data platform is used to collect, clean, transform, integrate, and store business data from at least one related business module. The User and Permission Management Center is used to configure function permissions and data permission rules according to user roles, and generate data filtering conditions based on the above data permission rules and the organization dimension field in the core business data records to limit the range of data that different user roles can access. The multi-dimensional performance management engine is used to obtain performance appraisal schemes configured for at least one user role, retrieve business data from the data platform based on the data source identifier in the performance appraisal scheme, and calculate and generate performance results according to the scoring formula. The data change tracking and confirmation module is used to respond to changes to key data that affect the above performance results, generate a change record containing the changes, retain the original record of the key data as a historical version, trigger a confirmation process for the above change, and use the changed key data to update the above performance results when the above change is confirmed, and maintain the performance results before the change when the above change is rejected.

[0025] In the above technical solution, by setting up a data platform, a user and permission management center, a multi-dimensional performance management engine, and a data change traceability and confirmation module, functions such as business data processing, permission control, performance calculation, and confirmation of key data changes can be implemented respectively. These modules work together around business data, permission rules, and performance results, enabling data access control for different user roles, performance appraisal scheme configuration, performance result generation, and key data change processing to be carried out collaboratively within the same system. This improves the integration level of the performance management system, data processing consistency, and the controllability of result management. Attached Figure Description

[0026] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained from these drawings without creative effort.

[0027] Figure 1 This is a flowchart of the steps of the method of the present invention. Detailed Implementation

[0028] To facilitate understanding by those skilled in the art, the technical solution of the present invention will now be described in further detail with reference to the accompanying drawings: In the description of this invention, terms such as user role, organizational dimension field, performance indicator, data source identifier, and key data are used to describe the business data and processing objects in the technical solution of this invention, and their specific content can be configured according to the actual application scenario. The numbering of steps S1 to S6 is only used to illustrate the logical order of the technical solution and does not constitute an absolute limitation on the order of execution. This invention provides a role-based, multi-dimensional performance management method. This method is applicable to both enterprise internal management platforms and performance management systems connected to enterprise business systems. It provides unified management of the scope of business data access, performance evaluation criteria, and handling of key data changes for different user roles. Key data refers to business data that directly affects performance result calculation, such as project ownership information, responsible person information, business amount information, cost and revenue information, and task completion status information. Through unified management, the access to business data, the generation of performance results, and the updating process of performance results after key data changes are kept consistent. The following is combined with… Figure 1 The following describes the content of this invention: Step S1: First, configure function permissions and data permission rules according to user roles.

[0029] In this step, functional permissions are used to limit the functional pages, entry points, and operations that different user roles can access. Data permission rules are used to limit the range of data that different user roles can view, analyze, access, or process. User roles can be set according to the company's internal organizational structure and job responsibilities, such as company management roles, department heads, project managers, ordinary employees, or other roles that meet the company's management requirements. Different roles correspond to different sets of permissions in the system, and system administrators can configure, adjust, and maintain the functional permissions and data permission rules for each role in the permission management interface.

[0030] Specifically, functional permissions can correspond to operation types such as viewing, inputting, modifying, approving, and exporting, while data permission rules can correspond to permission scopes such as visibility of all data, visibility of data within a department, visibility of data the user is responsible for, visibility of data for a specified project, and visibility of data for a specified area. By configuring functional permissions and data permission rules to different user roles, the system can support the usage needs of personnel at different levels and with different responsibilities on the same set of business data. For example, department heads can view business data within their department and perform performance approval operations, ordinary employees can view data related to their own responsibilities and view their own performance results, and corporate management can view a wider range of data and perform cross-departmental statistical analysis. This ensures that user access behavior is consistent with role responsibilities.

[0031] Step S2: In response to the data query request, obtain the user role that initiated the request, and generate data filtering conditions based on the data permission rules corresponding to the user role and the preset organization dimension fields in the core business data records to limit the range of data that the user role can access.

[0032] In this step, data query requests can be list query requests on the front-end page, data extraction requests from statistical reports, or requests to read business data during performance calculations. Upon receiving a request, the system first identifies the user role corresponding to the currently logged-in user or the current session, and then determines the data scope control logic based on the data permission rules corresponding to that role.

[0033] The pre-defined organization dimension fields in core business data records describe the correspondence between the business data and the enterprise's organizational structure. Organization dimension fields can include department identifiers, responsible person identifiers, responsible project identifiers, and region identifiers. Other identifiers reflecting the data's scope can also be added based on the enterprise's management methods. When each piece of core business data is written to the system, these organization dimension fields can be written simultaneously, ensuring that subsequent data access control and statistical analysis are centered around organizational affiliation.

[0034] Specifically, when the system identifies that the current user role has global permissions, it can generate data filtering conditions that allow access to all core business data records. In this case, the query results are not restricted by department, project, or region. When the system identifies that the current user role does not have global permissions, it extracts the corresponding fields and values ​​from the organization dimension fields according to the data permission rules for that role and concatenates them to form data filtering conditions. For example, for the role of department head, data filtering conditions within the department can be generated based on the department identifier; for the role of project head, data filtering conditions within the project can be generated based on the project identifier; for roles restricted by both department and region, the department identifier and the region identifier can be combined as filtering conditions. In this way, when different roles request the same data table, the final range of results obtained can be different.

[0035] In one specific embodiment, data filtering conditions can be dynamically transformed into filtering clauses in a database query statement, and data filtering can be performed on core business data records at the database level. The permission management center can store data permission rules corresponding to each user role. When the system receives a data query request, it reads the data permission rules for the current user role from the permission management center, constructs a filtering clause based on the organization dimension field in the business data record, and appends this filtering clause to the database query statement for execution. In this way, the database has already completed data range restrictions before returning the query results. This approach allows unauthorized data to be excluded during the database retrieval stage, making data access control more direct and facilitating unified permission filtering across different business modules.

[0036] Organizational dimension fields can be controlled using a single field or a combination of multiple fields. Preferably, organizational dimension fields include at least one or a combination of the following: department identifier, person in charge identifier, project identifier, and region identifier. When a user role is configured with global permissions, data filtering conditions allow access to all core business data records. When a user role does not have global permissions, data filtering conditions are determined by the values ​​of one or more organizational dimension fields. This approach allows for both flexibility and granularity in data scope control, satisfying both management's requirements for viewing overall data and the constraints imposed on access to specific data by ordinary and local management roles.

[0037] Step S3: After completing data access control, the system obtains the performance appraisal scheme configured for at least one user role. The performance appraisal scheme is used to determine the performance evaluation criteria for different user roles. The performance appraisal scheme includes at least one performance indicator, as well as the target value, weight, scoring formula, and data source identifier associated with the performance indicator.

[0038] Specifically, performance indicators are used to indicate the performance items that need to be evaluated, such as project completion rate, business revenue, customer response time, gross profit contribution, and task achievement rate. Target values ​​describe the target level of each performance indicator, weights reflect the proportion of different performance indicators in the overall performance, scoring formulas convert business data into performance scores, and data source identifiers indicate which business module or data table the required business data for this performance indicator comes from.

[0039] In one embodiment, different user roles can be configured with different performance evaluation schemes. For example, for business roles, the performance evaluation scheme can focus more on indicators such as contract amount, payment collection rate, and customer conversion rate; for project roles, the performance evaluation scheme can focus on indicators such as project progress, project gross profit, and delivery quality; and for operations roles, the performance evaluation scheme can focus on indicators such as task completion rate, exception handling efficiency, and customer feedback. By matching performance indicators, weights, and data sources with user roles, performance results can be more closely aligned with the business responsibilities of different positions.

[0040] Preferably, the system provides a pre-set performance indicator library containing multiple candidate performance indicators. Administrators can initiate scheme configuration commands for at least one user role through the system configuration interface, selecting target performance indicators from the library and setting target values, weights, scoring formulas, and data source identifiers for each selected indicator to generate a performance appraisal scheme. The candidate indicators in the performance indicator library can be pre-maintained by the system or expanded by the administrator according to enterprise management requirements. Using an indicator library for scheme configuration makes the configuration process for performance schemes for each role more standardized, facilitates the reuse of some common indicators among different roles, and preserves space for differentiated settings.

[0041] Step S4: After obtaining the corresponding performance appraisal plan, the system collects business data from the corresponding related business modules according to the data source identifier in the performance appraisal plan, and calculates and generates performance results according to the scoring formula corresponding to each performance indicator.

[0042] In this step, the associated business module can be a project management module, customer management module, financial management module, human resources module, work order management module, or other modules that can provide the business data required for performance calculation. The data source identifier indicates the correspondence between performance indicators and business data. After reading this data source identifier, the system can determine from which business module, which type of data object, or which type of data record the basic data required for performance calculation is obtained.

[0043] In one specific embodiment, the system collects business data from related business modules based on data source identifiers through a data platform. The data platform can collect, clean, transform, integrate, and store data from different business modules. Since the data structures and naming conventions of different business modules may differ, the data platform can perform unified field mapping, standardize data formats, and preprocess duplicate, missing, or abnormal data during the data collection process. The processed business data can then be accessed by a multi-dimensional performance management engine in a unified format.

[0044] After obtaining the business data required for performance calculation, the system executes scoring formulas through a rules engine or custom scripts to calculate the scores for each performance indicator and the overall performance score. The rules engine is suitable for executing relatively standardized scoring rules according to preset logic, while custom scripts are suitable for expressing more complex and flexible calculation logic. For example, it can calculate individual scores based on the score range corresponding to the target achievement ratio, calculate composite indicator scores based on the operational relationships between multiple business data, and introduce processing logic such as weighted summation, segmented scoring, or threshold correction into the overall performance score. After the system completes the score calculation for each performance indicator according to the scoring formulas, it synthesizes the overall performance score according to the weights of each performance indicator, ultimately generating the performance result.

[0045] In one specific embodiment, during the calculation of performance results based on the scoring formula, the system also establishes a performance dependency mapping relationship. Specifically, the system establishes a field mapping table between the scoring formula and business data fields based on the data items referenced by the scoring formula and their corresponding data source identifiers. The field mapping table records the data items, data sources, and corresponding business data fields that each performance indicator depends on when executing the scoring formula. For example, when the scoring formula for a performance indicator references data items such as project revenue, project cost, or task completion quantity, the system can map project revenue to the revenue field in the project management module, project cost to the cost field in the finance module, and task completion quantity to the task status field or statistics field in the task management module, based on the data source identifier. Through this method, a correspondence can be established between performance indicators, scoring formulas, and business data fields, so that when key data changes subsequently, the affected performance objects and indicator sets can be located based on the changed fields.

[0046] As a preferred approach, business data collection is triggered via background scheduled tasks or message queues. For business data with a relatively stable update frequency, collection can be initiated at preset time periods via background scheduled tasks. For data that needs to reflect changes in business status more quickly, data synchronization can be triggered via message queues when data is written, modified, or approved in a business module. Using scheduled tasks or message queues for business data collection can automate the performance calculation process, thereby reducing delays and errors caused by manual aggregation.

[0047] After performance results are generated, the system also processes changes to key data that affect those results. Key data refers to business data that directly impacts performance result calculation. For example, project ownership information, responsible person information, business amount information, cost and revenue information, and task completion status information can all become key data affecting performance results in different performance scenarios.

[0048] Step S5: In response to the change operation of key data affecting the performance results, lock the current valid state of the performance results, generate a change record containing the changed content, retain the original record of the key data as a historical version, and push a confirmation task to the preset review end to trigger the confirmation process.

[0049] Specifically, the change log can record the key data identifiers involved in the change, the operator, the operation time, the data content before the change, the data content after the change, the reason for the change, and the scope of performance impact related to the change. The original record is retained as a historical version, meaning the system does not directly delete or irreversibly overwrite the original record, but saves the original data state as a historical version. This allows for viewing the actual state of key data before the change during subsequent verification or tracing. The confirmation process is used to determine whether the change to key data should actually affect performance results. In the confirmation process, personnel with the appropriate review authority can confirm or reject the change.

[0050] In one specific embodiment, when the system responds to a change operation on key data affecting performance results, generates a change record containing the changed content, and triggers a confirmation process for the change operation, it also includes identifying the set of performance objects and the set of indicators affected by the key data change based on a pre-established performance dependency mapping relationship. Specifically, the system queries the aforementioned field mapping table based on the business field corresponding to the changed key data to locate the scoring formula and corresponding performance indicator that references the field, and then determines the set of affected performance objects and the set of indicators by combining the user role and assessment period.

[0051] For example, if a key data point is only related to a portion of the performance indicators for a specific user role within a certain assessment period, the system can identify the corresponding set of performance objects and indicator sets based on the performance dependency mapping relationship. This allows the system to process data within the affected scope during subsequent confirmation and performance result updates. This approach ensures that the scope of processing after key data changes is more consistent with the actual impact, improving the accuracy of the processing.

[0052] In a further embodiment, the system can also generate candidate performance snapshots corresponding to the key data change operation, in addition to the performance results before the change, for the affected set of performance objects, and set the performance result snapshot before the change to read-only. Here, the candidate performance snapshot is used to record the performance result state that may be formed under the current key data change conditions, while setting the performance result snapshot before the change to read-only is used to maintain the original performance result in a stable and unmodifiable state before confirmation. In this way, when the key data change has not yet been confirmed, the system can simultaneously save both the pre- and post-change performance result states, with the original performance result retained as the existing valid result and the candidate performance snapshot retained as the result pending confirmation.

[0053] Step S6: After the confirmation process returns feedback information, the system decides whether to update the performance results based on the feedback. When the change operation is confirmed, the changed key data is used to update the performance results; when the change operation is rejected, the performance results before the change are maintained.

[0054] In this step, the feedback information can be generated by the reviewer confirming or rejecting the application on the review interface, or it can be automatically generated after the preset approval process is completed. After reading the feedback information, the system can link the key data changes with the performance results update.

[0055] In one specific embodiment, when a change operation is confirmed, the system performs incremental recalculation only for the affected set of performance objects and indicators, and recalculates only the calculation items corresponding to the affected performance indicators based on the data differences before and after the change. Incremental recalculation means that the system does not recalculate all performance objects and all performance indicators, but only recalculates the objects and indicators actually involved in this key data change. The data differences before and after the key data change can serve as the basis for performance result correction. The system re-executes the relevant scoring formulas based on these data differences to obtain updated performance results. This approach makes the performance result update process more targeted.

[0056] In a corresponding embodiment, when a change request is rejected, the system deletes the candidate performance snapshot and maintains the performance results before the change as the current valid performance results. Thus, when a critical data change fails to pass confirmation, the candidate performance results related to that change will not be included in the current valid results, and the original performance results continue to exist as valid performance results in the system. Therefore, the impact of critical data changes on performance results only takes effect after confirmation, ensuring that the performance result update process is consistent with the confirmation result.

[0057] To enhance the verification and traceability of critical data changes, the system, when generating change records containing the changed content, can generate change records that include both the previous record summary value and the current record summary value for each critical data change operation. The current record summary value is generated through a hash algorithm, calculating the previous record summary value, operator identifier, operation time, hash of the data before the change, hash of the data after the change, change reason information, and the set of identifiers of the affected performance objects. By associating the current record summary value with the previous record summary value and the content of this change, each change record can establish a sequential relationship based on its summary value, supporting verification and traceability of the change process.

[0058] Specifically, when the system records the first critical data change, it generates a corresponding summary value. When recording subsequent critical data changes, the summary value of the previous record is used as one of the inputs in generating the summary value for the current record. This establishes a sequential relationship between different change records. When subsequent verification of the critical data change process is required, consistency checks can be performed based on the relationship between the summary values ​​in each change record and the content of the change. This approach improves the verifiability of critical data change records.

[0059] Based on the above methods, this invention also proposes a role-based multi-dimensional performance management system, including a data platform, a user and permission management center, a multi-dimensional performance management engine, and a data change traceability and confirmation module.

[0060] The data platform is used to collect, clean, transform, integrate, and store business data from at least one related business module.

[0061] The User and Permission Management Center is used to configure function permissions and data permission rules based on user roles, and to generate data filtering conditions based on the data permission rules and the organization dimension fields in the core business data records, so as to limit the range of data that different user roles can access.

[0062] The multi-dimensional performance management engine is used to obtain performance appraisal schemes configured for at least one user role, retrieve business data from the data platform according to the data source identifier in the performance appraisal scheme, and calculate and generate performance results according to the scoring formula.

[0063] The data change tracking and confirmation module is used to respond to changes to key data that affect performance results, generate change records containing the changes, retain the original records of key data as historical versions, trigger the confirmation process for the change operation, and use the changed key data to update performance results when the change operation is confirmed, and maintain the performance results before the change when the change operation is rejected.

[0064] In one specific embodiment, the data platform can function as a business data access and unified processing unit, responsible for unifying the data output from different business modules such as project management, customer management, and financial management into a data format readable by the performance management engine. The user and permission management center can function as a permission configuration and access control unit, responsible for role creation, permission allocation, permission rule maintenance, and query filter condition generation. The multi-dimensional performance management engine can function as a performance plan execution unit, responsible for reading performance plans, extracting business data, executing scoring formulas, and outputting performance results. The data change traceability and confirmation module can function as a key data change management unit, responsible for generating key data change records, retaining historical versions, triggering confirmation processes, managing candidate performance snapshots, updating results, and handling traceability verification. In one embodiment, the data change traceability and confirmation module includes a change interception unit, a snapshot storage unit, and a difference recalculation engine. The change interception unit maintains the pre-change performance results as the current valid state when key data changes; the snapshot storage unit saves the pre-change performance snapshot and marks it as read-only; the difference recalculation engine, after confirmation, incrementally updates the affected performance results based only on the changed data.

[0065] In actual deployment, the aforementioned units can be deployed on the same server or distributed across different servers or service nodes. The units collaborate through interface calls, message communication, or data sharing. This way, when enterprise business data requires entry, updates, approvals, or statistical analysis, the system can simultaneously consider the data access scope corresponding to user roles, performance scheme configuration requirements, and the impact of key data changes on performance results, thus ensuring the consistency and implementability of the entire multi-dimensional performance management process.

[0066] It should be understood that the above specific embodiments are only used to illustrate the technical solutions of the present invention. For those skilled in the art, without departing from the concept of the present invention, corresponding adjustments can be made to the user role division method, organizational dimension field setting method, performance indicator content, scoring formula form, confirmation process setting method, and data collection triggering method according to the different enterprise organizational structure, business module types, performance evaluation requirements, and key data scope. All such adjustments can fall within the protection scope of the present invention.

Claims

1. A role-based, multi-dimensional performance management method, characterized in that, include: S1: Configure function permissions and data permission rules according to user roles; S2: In response to a data query request, obtain the user role that initiated the request, and generate data filtering conditions based on the data permission rules corresponding to the user role and the preset organization dimension fields in the core business data records to limit the range of data that the user role can access. S3: Obtain a performance evaluation scheme configured for at least one user role, the performance evaluation scheme including at least one performance indicator, and target value, weight, scoring formula and data source identifier associated with the performance indicator; S4: Based on the data source identifier in the performance appraisal scheme, collect business data from the corresponding associated business modules, and calculate and generate performance results according to the scoring formula corresponding to each performance indicator; S5: In response to the change operation of key data affecting the performance results, lock the current valid state of the performance results, generate a change record containing the changed content, retain the original record of the key data as a historical version, and push a confirmation task to the preset review end to trigger the confirmation process; S6: Receive feedback information regarding the confirmation process. When the change operation is confirmed, use the changed key data to update the performance results; when the change operation is rejected, maintain the performance results before the change.

2. The role-based multi-dimensional performance management method according to claim 1, characterized in that, Step S4 also includes the step of establishing a performance dependency mapping relationship: based on the data items referenced by the scoring formula and the data source identifier, a field mapping table is established between the scoring formula and the business data fields; In step S5, in response to a change operation on key data affecting the performance results, a change record containing the changed content is generated, and a confirmation task is pushed to a preset review end to trigger the confirmation process, including: Based on the pre-established performance dependency mapping relationship, identify the set of performance objects and the set of indicators affected by the change operation of the key data. Specifically, according to the field corresponding to the changed key data, query the field mapping table to locate the set of indicators affected. The performance dependency mapping relationship is used to characterize the association between performance indicator identifiers, data source identifiers, scoring formula identifiers, user role identifiers, and assessment cycle identifiers.

3. The role-based multi-dimensional performance management method according to claim 2, characterized in that, Also includes: For the set of affected performance objects, generate a candidate performance snapshot corresponding to the change operation of the key data in addition to the performance results before the change, and set the performance result snapshot before the change to read-only.

4. The role-based multi-dimensional performance management method according to claim 3, characterized in that, When the change is confirmed, the modified key data will be used to update the performance results, including: When the change operation is confirmed, the changed business data is re-extracted from the data platform only for the affected set of performance objects and the set of indicators, and the calculation items corresponding to the affected performance indicators are recalculated only based on the data differences before and after the change, so as to update the performance results; When the change request is rejected, the performance results before the change are maintained, including: When the change operation is rejected, the candidate performance snapshot is deleted, and the performance results before the change are maintained as the current valid performance results.

5. The role-based multi-dimensional performance management method according to claim 2, characterized in that, Generate a change log containing the changed information, including: For any changes to the key data, a change record is generated that includes the summary values ​​of the previous and current records. The current record summary value is generated by a hash algorithm on the previous record summary value, operator identifier, operation time, data hash before change, data hash after change, change reason information, and the set of identifiers of affected performance objects, so that each change record can establish a connection between the previous and subsequent records based on the summary value, and support the verification and traceability of the change process.

6. The role-based multi-dimensional performance management method according to claim 1, characterized in that, Based on the data permission rules corresponding to the user roles and the preset organization dimension fields in the core business data records, data filtering conditions are generated, including: The system retrieves the data permission rules corresponding to the user role from the permission management center and dynamically converts these rules into filter clauses in a database query statement to perform data filtering on the core business data records at the database level.

7. The role-based multi-dimensional performance management method according to claim 6, characterized in that, The organization dimension fields include at least one or a combination of the following: department identifier, person in charge identifier, project in charge identifier, and region identifier; When a user role is configured to have global permissions, the data filtering conditions allow access to all core business data records; When a user role does not have global permissions, the data filtering conditions are determined by the values ​​of one or more of the organization dimension fields.

8. The role-based multi-dimensional performance management method according to claim 1, characterized in that, Obtain the performance evaluation scheme configured for at least one user role, including: A preset performance indicator library is provided, which stores multiple candidate performance indicators; The system receives a scheme configuration instruction from the administrator for at least one user role, selects target performance indicators from the performance indicator library, and sets corresponding target values, weights, scoring formulas, and data source identifiers for each selected target performance indicator to generate the performance appraisal scheme.

9. The role-based multi-dimensional performance management method according to claim 8, characterized in that, Based on the data source identifier in the performance appraisal scheme, business data is collected from the corresponding associated business modules, and performance results are calculated and generated according to the scoring formula corresponding to each performance indicator, including: Business data is collected from the associated business modules through the data platform based on the data source identifier; The scoring formula is executed through a rules engine or a custom script to calculate the scores for each performance indicator and the overall performance score. The data collection process is triggered by a background scheduled task or message queue mechanism.

10. A role-based multi-dimensional performance management system, employing the role-based multi-dimensional performance management method as described in any one of claims 1-9, characterized in that, include: A data platform is used to collect, clean, transform, integrate, and store business data from at least one related business module. The User and Permission Management Center is used to configure function permissions and data permission rules according to user roles, and generate data filtering conditions based on the data permission rules and the organization dimension field in the core business data records to limit the range of data that different user roles can access. A multi-dimensional performance management engine is used to obtain performance appraisal schemes configured for at least one user role, retrieve business data from the data platform according to the data source identifier in the performance appraisal scheme, and calculate and generate performance results according to the scoring formula. The data change tracking and confirmation module is used to respond to changes to key data that affect the performance results, generate a change record containing the changes, retain the original record of the key data as a historical version, trigger a confirmation process for the change, and use the changed key data to update the performance results when the change is confirmed, and maintain the performance results before the change when the change is rejected. The data change tracking and confirmation module includes: The change interception unit is used to maintain the performance results before the change as the current valid state when critical data changes; Snapshot storage unit, used to save performance snapshots before changes and marked as read-only; The differential recalculation engine is used to incrementally update the affected performance results based solely on the changed data after approval.

Images