Process asset management system and method based on BPM management system

Abstract

The invention relates to the technical field of enterprise process management digitization, in particular to a process asset management system and method based on a BPM management system. Comprising a process framework construction unit; a multi-dimensional authority management unit; a flow chart increment analysis unit, wherein the flow chart increment analysis unit adopts a collaborative strategy of initialized total analysis and timing increment analysis; a role classification permission unit; an approval responsibility closed loop unit; and a demand scheme merging unit. According to the method, targeted optimization of existing process management defects is realized through a multi-dimensional technical design: in the aspect of digital management of process assets, standardized generation of a tree-shaped business classification framework is realized through hierarchical construction and a uniqueness verification mechanism of a process framework construction unit; the problem of disordered process framework organization in a traditional scheme is solved, and the hierarchical management efficiency of process assets is improved; the problem of low flow change analysis efficiency in the prior art is effectively solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of enterprise process management digitization, in particular to a process asset management system and method based on a BPM management system. BACKGROUND

[0002] In the field of enterprise digital management, business processes, as the core knowledge assets for organizations to achieve efficient operation, their standardized and digitized management has become a key means to improve enterprise performance. Business process management is a systematic approach that focuses on standardizing the construction of end-to-end excellent business processes and aims to continuously improve organizational business performance. The process management method based on the BPM (Business Process Management) system realizes the systematic control of enterprise operation logic by constructing an end-to-end business process framework. However, with the individualization and complexity of enterprise management needs, the traditional process management mode gradually exposes the limitations of process asset digitized management, and a more flexible technical solution is needed to realize the online integration of process indicators, files and requirements.

[0003] Although the current mainstream process management software has realized the informatization of basic process information, there are still two technical defects in actual use: first, it lacks multi-dimensional digitized management capability for process assets, especially in the aspects of process framework construction, dynamic allocation of authority, and process change analysis, etc., which makes it difficult to meet the fine control needs of the whole life cycle of process assets; second, the correlation mechanism between process management and enterprise system is weak, which cannot effectively map the management system requirements and informationized processes, resulting in insufficient flexibility in scenarios such as closed-loop management of approval responsibilities and consolidation of demand schemes. In view of the above defects, we propose a process asset management system and method based on the BPM management system. SUMMARY

[0004] The present application aims to provide a process asset management system and method based on the BPM management system to solve the problems of lack of multi-dimensional digitized management capability for process assets and weak correlation mechanism between process management and enterprise system as mentioned in the background.

[0005] To solve the above technical problems, one of the purposes of the present application is to provide a process asset management system based on the BPM management system, which comprises:

[0006] A process framework construction unit, which is used to construct a tree-shaped business classification framework, associate items and authority data through parent coding, generate a hierarchical structure with framework path, and realize the uniqueness control of sub-node names under the same parent node;

[0007] A multi-dimensional authority management unit, which realizes multi-dimensional visualization and query of authority division based on a matter, role classification and role dimension, by using a tree list and an associated view;

[0008] A flowchart incremental analysis unit, which adopts a cooperative strategy of initialization full analysis and timing incremental analysis; the initialization full analysis traverses all nodes of the flowchart, extracts role, authority and approval responsibility attribute BPMN business tags, generates full associated data and constructs an initial benchmark version; the timing incremental analysis uses a BPMN business tag fingerprint comparison algorithm to compare the business tags, node roles, node authorities and node approval responsibility attributes of the current flowchart and the historical benchmark version, accurately identifies the changed nodes; only the changed nodes are subjected to incremental analysis and data update, thereby realizing efficient synchronization of flowchart data;

[0009] A role classification permission unit, which is used to associate departments and personnel with role classification, realizes fine-grained access control of authority data by using a data row filtering mechanism, and displays grayed-out null cells when unauthorized users access;

[0010] An approval responsibility closed loop unit, which is used to maintain the approval responsibility description of the nodes of the flowchart and integrates feedback submission, record tracing and email notification functions;

[0011] A demand scheme merging unit, which integrates demand application and scheme approval processes, and sets a "special approval" check box at the approval node of the process management part; after the check box is checked, 1-5 level approvers can be filled in by customizing, and product manager approvers are automatically matched according to preset rules of demand classification.

[0012] As a further improvement of the technical solution, the process framework construction unit comprises a level calculation module, a path generation module and a uniqueness verification module, wherein:

[0013] The level calculation module integrates a parent framework point selection interaction interface for receiving selection instructions of the parent framework; if no parent framework is associated, the current framework is marked as the topmost level (the initial value of the level of the framework is set as 1 by default); if a parent framework is associated, the level of the current framework is the level value of the parent framework plus 1;

[0014] The path generation module is used to receive the parent path and the current level value output by the level calculation module, and generate a framework path with levels;

[0015] The uniqueness verification module is used to listen to the sub-node name input action and verify the uniqueness of the sub-node names under the same parent node in real time; if it is detected that the sub-node names under the same parent node are duplicated, a pop-up window prompts a name conflict and blocks the framework storage process.

[0016] As a further improvement to this technical solution, the multi-dimensional authority management unit realizes multi-dimensional organization and query of authority through a multi-dimensional authority hierarchy mapping algorithm, including the following steps:

[0017] S200.1 Constructing a three-dimensional hierarchical relationship model:

[0018] Define the three-dimensional hierarchical relationship between tasks, roles, and roles, and construct a set of triples M = {(T} i C j R k )};wherein, T i C represents the i-th item; j Represents the j-th role category; R k This represents the k-th role; and the same event T i The following role category C j It is unique, belonging to the same role category C. j The character R below k It is unique;

[0019] S200.2, Binding Authority Attribute Parameters:

[0020] For each triple (T) i C j R k Bind the set of authority attributes A = {D, V, P}, where: D represents the effective date; V represents the approval amount threshold; and P represents the description of approval responsibilities.

[0021] Construct a complete record of authority R = (T) i C j R k (D, V, P);

[0022] S200.3. Based on the three-dimensional hierarchical relationship of S200.1 and the authority attributes of S200.2, a hierarchical authority data tree Tree(M, A) is generated, where:

[0023] The root node set is the event {T1, T2, ..., T}. n}; where n represents the number of nodes in the root node level;

[0024] Each item T i The set of child nodes is the class of roles associated with it {C} j1 C j2 C jm}; where m represents each item T i The following is related to the role category C j quantity;

[0025] Each role is categorized as Cj The set of child nodes is the set of roles {R} associated with it. k1 R k2 ,…,R kp}; where p represents each role category C j The related role R k quantity;

[0026] Each leaf node (role R) k The associated authority record R = (T) generated by S200.2 i C j R k (D, V, P), enabling access to the effective date, approval amount threshold, and description of approval responsibilities;

[0027] S200.4, Implement multi-dimensional query optimization:

[0028] For the effective date D, construct a range index I. D ={[D min D max ]}, where D min and D max These are the minimum and maximum dates within the query range, respectively.

[0029] For the description of approval responsibilities P, construct a keyword hash index H. P ;

[0030] H P ={(w1, h1), (w2, h2),..., (w q h q )};wherein, w q This indicates keywords in the job description; h q Indicates keyword w q The corresponding hash value;

[0031] In the process of querying using tree lists and related views, the formula Q = I is used. D ∩H P , performs an intersection operation to quickly locate the set of authority records that meet the conditions; where Q represents the result set of a multi-condition joint query; ∩ represents the intersection operation of the sets.

[0032] As a further improvement to this technical solution, the timed incremental parsing of the flowchart incremental parsing unit adopts the BPMN service tag fingerprint comparison algorithm, including the following steps:

[0033] S300.1, Current Flowchart Feature Extraction and Assembly:

[0034] When incremental parsing is triggered periodically, all nodes in the current flowchart are traversed to extract the following basic business attributes and BPMN business tags:

[0035] Basic business attributes: Node role R (e.g., "financial director"), node authority A (e.g., "approval amount ≤ 100,000 yuan"), node approval responsibility P (e.g., "review invoice compliance");

[0036] BPMN business tags: Node type T (e.g., "User task", "Exclusive gateway"), Event triggering rule E (e.g., "Timer trigger, timeout = 3 days"), Process connection relationship C (e.g., "Previous node ID = 101, subsequent node ID = 103");

[0037] The basic business attributes and BPMN business tags are concatenated into a feature string using the following formula. in, To prevent conflicting delimiters and avoid parsing discrepancies when attribute values ​​contain regular delimiters; R i A i P i T i E i C i These correspond to the role, authority, approval responsibility, node type, event triggering rules, and process connection relationship of the i-th node, respectively.

[0038] S300.2, Business fingerprint hash calculation:

[0039] To generate the business fingerprint of the current node, the SHA-256 hash algorithm is used to hash the feature string S. curr,i Perform encrypted calculations and define the business fingerprint H. curr，i The calculation formula for H is as follows: curr,i =SHA-256(S curr，i ); where SHA-256 outputs a 256-bit hash value, ensuring that different feature strings generate a unique fingerprint and have collision resistance;

[0040] Construct the current fingerprint set H set_curr :

[0041] H set_curr ={H curr,i |i = 1, 2, ..., m};

[0042] Among them, H curr,i This represents the business fingerprint of the i-th node in the current flowchart, where m is the total number of nodes in the current flowchart.

[0043] S300.3, Historical baseline fingerprint retrieval and comparison:

[0044] Retrieve historical benchmark fingerprint database D from the databasebase Each record contains a node ID and the historical role R of the j-th node. base,j The authority of the j-th historical node A base，j Historical approval responsibilities P at the j-th node base,j The j-th historical node of type T base，j The triggering rule for the j-th historical event, E base，j The historical process connection relationship of node j, C base j and its corresponding hash value H base，j ;

[0045] Construct historical fingerprint set H set_base The formula is: H set_base ={H base，j |j = 1, 2, ..., n};

[0046] Where n is the total number of nodes in the historical baseline version;

[0047] S300.4, Precise positioning of change nodes:

[0048] Change nodes are identified using symmetric difference operations, with the following formula:

[0049] H diff =H set_curr ΔH set_base =(H set_curr -H set_base )∪(H set_base -H set_curr );

[0050] Among them, H diff This represents the set of differing fingerprints, i.e., the set of fingerprints corresponding to nodes that have undergone changes; Δ represents the symmetric difference operator, used to calculate the elements that are not common to the two sets; H set_curr -H set_base This represents a unique element in the current fingerprint set, corresponding to a newly added node; H set_base -H set_curr This represents a unique element in the historical fingerprint set, corresponding to a deletion node or an attribute modification node;

[0051] For each difference fingerprint, the change type is confirmed by associating it with the node ID:

[0052] If the fingerprint H is different diff，k ∈(H set_curr -H set_base ), and the node ID corresponding to this fingerprint is in the historical benchmark database D. base If it does not exist in the current flowchart, it is determined to be a newly added node (the node added at node number i in the current flowchart).

[0053] If the fingerprint H is different diff，l∈(H set_base -H set_curr If the node ID corresponding to the fingerprint exists in the current flowchart (but the fingerprint is different), then it is determined to be an attribute modification node (that is, the node's role, authority, approval responsibility, node type, event rules or process connection relationship is modified, and the corresponding historical node number j and the current node number i are the same node but the fingerprint has changed).

[0054] If the fingerprint H is different diff，l ∈(H set_base -H set_curr If the node ID corresponding to the fingerprint does not exist in the current flowchart, then it is determined to be a deleted node (the corresponding historical node number j exists, and the current node number i has no corresponding node).

[0055] S300.5 Incremental Data Synchronization and Efficiency Optimization:

[0056] For the identified changed nodes, perform the following incremental update operations:

[0057] Add a node: Extract the current node role R of this node. curr,i Current node authority A curr，i Current node approval responsibilities P curr，i Current node type T curr,i Current event triggering rule E curr，i Current process connection relationship C curr，i And current business fingerprint H curr，i Inserted as a new data item into the historical benchmark fingerprint database D base ;

[0058] Delete node: from historical benchmark fingerprint database D base Delete the record corresponding to this node (historical node number j);

[0059] Attribute modification node: From historical benchmark fingerprint database D base Delete the old record of the node (corresponding to the historical node number j) and insert the new record to complete the attribute update.

[0060] As a further improvement to this technical solution, the role classification permission unit includes a role-organization association module and a power data filtering module, wherein:

[0061] The role-organization association module integrates an interactive interface and association logic to support system administrators in binding roles, departments, or personnel, and to generate role-organization association relationships. After binding, role-organization association relationship data is generated and stored according to the data structure of role category ID, associated object ID, and object type, realizing the association mapping between role categories and departments and personnel in the enterprise organizational structure.

[0062] The authority data filtering module integrates permission verification and data rendering logic. When a user initiates an authority data access request, it calls the role-organization association data to determine permissions, specifically including:

[0063] When the user's associated role matches the permission configuration of the access authority data, the authority data is rendered and returned normally according to the preset data display rules;

[0064] When a user's associated role does not have corresponding access permissions, special rendering logic is triggered for unauthorized data rows, which are presented as grayed-out empty cells (e.g., the cells are filled in gray through interface style control, and placeholders such as "No permission to access" are displayed), clearly reflecting the permission restriction result.

[0065] As a further improvement to this technical solution, the authority data filtering module includes an authority verification submodule and an access log submodule, wherein:

[0066] The permission verification submodule performs real-time verification when a user initiates a permission data access request;

[0067] The real-time verification specifically includes:

[0068] Association validity verification: Check the user's role-organization association relationship to determine whether it is in a valid state (not deleted or frozen);

[0069] Permission matching verification: Based on preset rules (such as "financial role" corresponding to "financial data row"), verify whether the user role and the permissions of the data row to be accessed match.

[0070] Interception Feedback: If any validation fails, intercept the access request, call the grayed-out value rendering logic, and send an unauthorized result to the user.

[0071] The access log submodule integrates log recording logic. When a user initiates a request to access authorized data, it automatically generates and stores standardized access logs for auditing and tracing authorized access behavior.

[0072] Furthermore, log data items include:

[0073] Access timestamp (accurate to milliseconds);

[0074] Access the user's unique identifier (user ID);

[0075] The unique identifier (row ID) of the accessed authority data row;

[0076] Permission verification result (enumerated values: success / unauthorized);

[0077] Reason for unauthorization (association failure / permission mismatch, only filled in if the verification result is unauthorized).

[0078] As a further improvement to this technical solution, the closed-loop approval responsibility unit includes a responsibility editing module, a feedback information interaction module, a historical version tracing module, and an event notification triggering module, wherein:

[0079] The responsibility editing module integrates a node-level responsibility editing interface, which allows administrators to create and modify the approval responsibilities of flowchart nodes, automatically associate the responsibility content with the unique node identifier, and generate a responsibility description dataset containing operation timestamps.

[0080] The feedback information interaction module is used to integrate a feedback interaction entry into the approval business operation interface. Users can submit feedback information related to their approval responsibilities (such as suggestions for supplementing the description of responsibilities), and store the feedback data in a structured field according to user ID, node ID, feedback content, and submission time to form a traceable set of feedback records.

[0081] The historical version tracing module supports retrieving historical modification records of approval responsibilities by node ID, displaying the differences in responsibility content in the form of version comparison, and displaying the feedback records and processing status of the corresponding nodes in association, so as to realize two-way tracing of responsibilities and feedback.

[0082] The event notification triggering module adopts an event-driven mechanism. When the job description changes, it sends a notification containing version comparison to the associated approvers. When new unprocessed feedback is added, it pushes a pending notification containing feedback content and node identifier to the administrator to ensure a closed loop of job management.

[0083] As a further improvement to this technical solution, the requirement solution merging unit includes a process association module, a special approval configuration module, and an approver intelligent matching module, wherein:

[0084] The process association module is used to establish the association between the demand application process and the solution approval process. Based on the configuration mapping mechanism, the process mapping interface allows administrators to set association rules according to the demand category, business department, and at least one parameter dimension for configuring association rules, and generate a process association table (recording the demand process ID, solution process ID, association conditions, and effective time) to realize the connection and status synchronization of the two processes.

[0085] The special approval configuration module is designed to meet the needs of special approval scenarios and provides differentiated approver configuration capabilities at the approval nodes of the process management department. It adopts a method of embedding a Boolean checkbox (which is unchecked by default) in the approval interface. When checked, the custom approver input area is activated, which supports the input of 1-5 approvers (fields: approver ID, approval level (level 1-5), approval responsibility), and verifies the number of inputs in real time.

[0086] The intelligent approver matching module is used to automatically match product manager approvers. Based on the preset mapping rules of requirement classification and approver (stored in the system configuration table), it automatically queries the associated product managers by reading the requirement classification tags. If special approval has been enabled, it integrates the custom-entered approvers with the matched product managers to generate the final approver list.

[0087] As a further improvement to this technical solution, the requirement scheme merging unit further includes a state synchronization module and an exception handling module, wherein:

[0088] The status synchronization module is used to synchronize the status changes of the demand application and solution approval process in real time, automatically update the integrated status table through the status monitoring mechanism, and send status change notifications to relevant personnel.

[0089] The exception handling module is used to deal with abnormal situations during process operation and handles abnormal situations (such as missing approver, data synchronization failure, etc.) based on preset rules.

[0090] The second objective of this invention is to provide a process asset management method based on a BPM management system. The process asset management system based on the aforementioned BPM management system includes the following steps:

[0091] S100, Hierarchical Construction of Process Framework: Construct a tree-like business classification framework, associate items and authority data through parent codes, generate a hierarchical structure with framework paths, and achieve unique control of child node names under the same parent node;

[0092] S200, Incremental Flowchart Parsing and Authority Organization: A collaborative strategy of initial full parsing and timed incremental parsing is adopted; the initial full parsing traverses the flowchart nodes and extracts roles, authority, approval responsibility attributes, BPMN, and business tags; the timed incremental parsing uses a business tag fingerprint comparison algorithm to compare the current flowchart with the historical baseline version using feature hashing, identifies change nodes, and performs incremental updates; at the same time, based on the three-dimensional hierarchical relationship model of item-role classification-role, authority attribute parameters are bound to generate a hierarchical authority data tree.

[0093] S300, Closing the Approval Responsibility Loop and Merging the Requirement Process: Maintain the approval responsibility description of the flowchart nodes and integrate feedback submission, record tracking and email notification functions; integrate the requirement application and solution approval process, set special approval check boxes in the approval nodes of the process management department, and after checking, support the custom filling in of 1-5 level approvers, and automatically match the product manager approver according to the preset rules of requirement classification.

[0094] S400, Access Control and Process Status Management: Associating roles with departments and personnel, and using a data row filtering mechanism to achieve fine-grained access control of authority data; synchronizing the status of requirement applications and solution approval processes in real time, and handling abnormal situations based on preset rules.

[0095] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0096] 1. This invention achieves targeted optimization of existing process management deficiencies through multi-dimensional technical design: In terms of digital management of process assets, the hierarchical construction and uniqueness verification mechanism of process framework building units enables the standardized generation of a tree-like business classification framework, solving the problem of chaotic process framework organization in traditional solutions and improving the efficiency of hierarchical management of process assets; at the same time, relying on the collaborative strategy of initial full parsing and timed incremental parsing of the flowchart incremental parsing unit, combined with the BPMN business tag fingerprint comparison algorithm, it achieves accurate identification and efficient synchronization of process changes, reducing computational resource consumption compared to traditional full parsing solutions and effectively solving the problem of low process change parsing efficiency in existing technologies;

[0097] 2. At the level of process and management system linkage, this invention utilizes a multi-dimensional authority management unit to construct a three-dimensional hierarchical relationship model of item-role classification-role, coupled with a composite indexing mechanism, to achieve multi-dimensional organization and rapid querying of authority data, thereby improving the efficiency of cross-departmental authority collaboration. The requirement and solution merging unit integrates requirement application and solution approval processes, achieving integrated management of requirements and approval processes through special approval configurations and intelligent matching rules for approvers. It supports differentiated approval configurations, solving the problem of insufficient flexibility in approval processes in traditional solutions. Furthermore, the approval responsibility closed-loop unit, through an integrated design of responsibility editing, feedback interaction, and historical version tracing, forms a two-way traceability chain between approval responsibilities and system requirements, ensuring the effective mapping of enterprise management systems and information processes, and compensating for the weak process-system linkage in existing technologies. Attached Figure Description

[0098] Figure 1 This is a system framework diagram of the present invention;

[0099] Figure 2 This is a schematic diagram of the method steps of the present invention;

[0100] The meanings of the labels in the diagram are as follows:

[0101] 100. Process framework construction unit; 110. Hierarchical calculation module; 120. Path generation module; 130. Uniqueness verification module;

[0102] 200. Multi-dimensional authority management units;

[0103] 300. Flowchart Incremental Parsing Unit;

[0104] 400. Role-based permission unit; 410. Role-organization association module; 420. Authority data filtering module; 421. Permission verification submodule; 422. Access log submodule;

[0105] 500. Closed-loop approval responsibility unit; 510. Responsibility editing module; 520. Feedback information interaction module; 530. Historical version tracking module; 540. Event notification triggering module;

[0106] 600. Demand Solution Merging Unit; 610. Process Association Module; 620. Special Approval Configuration Module; 630. Approver Intelligent Matching Module; 640. Status Synchronization Module; 650. Exception Handling Module. Detailed Implementation

[0107] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. 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.

[0108] Example 1

[0109] like Figure 1 As shown, this embodiment provides a process asset management system based on the BPM management system, including:

[0110] The process framework construction unit 100 is used to construct a tree-like business classification framework. By associating matters and authority data through parent codes, it generates a hierarchical structure with a framework path, thereby achieving unique control over the names of child nodes under the same parent node.

[0111] In this embodiment, the process framework construction unit 100 includes a hierarchical calculation module 110, a path generation module 120, and a uniqueness verification module 130, wherein:

[0112] The hierarchical calculation module 110 integrates a parent frame selection interface to receive selection instructions from the parent frame. If no parent frame is associated, the current frame is marked as the top level (its initial level value is set to 1 by default). If a parent frame is associated, the level of the current frame is the level value of the parent frame plus 1.

[0113] The path generation module 120 is used to receive the parent path and the current level value output by the level calculation module 110, and generate a hierarchical frame path.

[0114] As a further explanation of this embodiment, the path generation in this embodiment adopts a recursive concatenation algorithm, generating a complete path based on the parent node path and the current node name. When the parent node path is " / company-level process" and the current node name is "finance department", the path " / company-level process / finance department" is generated. For changes such as renaming of parent nodes, the system traverses child nodes through database triggers or scheduled tasks, re-concatenates the path, and updates the fields to ensure that the path and hierarchical structure are synchronized in real time.

[0115] The uniqueness verification module 130 is used to monitor the child node name input action and verify the uniqueness of the child node name under the same parent node in real time; if duplicate child node names are detected under the same parent node, a pop-up window will prompt name conflict and block the framework storage process.

[0116] As a further explanation of this embodiment, the uniqueness verification module 130 employs dual front-end and back-end verification: the front-end listens for user input in real time in the input box and sends the node name and parent node ID to the back-end for verification; the back-end uses an SQL query to determine whether a node with the same name exists under the same parent node. If the verification fails, the front-end displays an error message and disables the save button, while the back-end blocks the storage process. For example, if "Finance Department" is entered repeatedly under the "Finance Department" node, the system immediately prompts a name conflict until the name is changed to a unique name before saving.

[0117] Furthermore, in this embodiment, when creating a framework node, the user selects the parent node and enters its name through the interface. The system then sequentially performs hierarchy calculation, path generation, and uniqueness verification. For example, taking the creation of the "Financial Approval Process" child node as an example: after selecting "Finance Department" as the parent node and entering its name, the system calculates the hierarchy to be 3, generates the path / Company-level Process / Finance Department / Financial Approval Process, and after successful verification, stores it in the database and updates the cache.

[0118] Meanwhile, the exception handling mechanism in this embodiment includes: when a parent node is deleted, the child node parent_id is set to null, the level is reset to 1, the path is recalculated, and a change notification is sent to the associated process instance; a circular dependency detection algorithm is used to prevent hierarchical loops (such as ABA), and if a loop is detected, the operation is blocked and an error is prompted to ensure the effectiveness of the framework structure.

[0119] The multi-dimensional authority management unit 200, based on matters, role classification and role dimensions, uses a tree list and related views to realize multi-dimensional visualization and query of authority division;

[0120] In this embodiment, the multi-dimensional authority management unit 200 realizes multi-dimensional organization and query of authority through a multi-dimensional authority hierarchy mapping algorithm, including the following steps:

[0121] S200.1 Constructing a three-dimensional hierarchical relationship model:

[0122] Define the three-dimensional hierarchical relationship between tasks, roles, and roles, and construct a set of triples M = {(T} i C j R k )};wherein, T i C represents the i-th item; j Represents the j-th role category; R k This represents the k-th role; and the same event T i The following role category C j It is unique, belonging to the same role category C. j The character R below k It is unique;

[0123] Understandably, during system initialization, administrators import item data through the backend interface, and the system generates a unique identifier for each item. When creating role categories, the system verifies the uniqueness of category names under the same item: if a duplicate name is entered, the front-end interface will display a conflict warning in real time and block the creation; when creating roles, the system verifies the uniqueness of role names under the same category to ensure the accuracy of hierarchical relationships. For example, under the "Procurement Approval" item, categories "Procurement Administrator" and "Financial Auditor" are created sequentially, and then the role "Level 1 Procurement Specialist" is created under the "Procurement Administrator" category, forming a three-level hierarchical structure.

[0124] S200.2, Binding Authority Attribute Parameters:

[0125] For each triple (T) i C j R k Bind the set of authority attributes A = {D, V, P}, where: D represents the effective date; V represents the approval amount threshold; and P represents the description of approval responsibilities.

[0126] Construct a complete record of authority R = (T) i C j R k (D, V, P);

[0127] Understandably, when assigning authority to a role, the system provides an interactive interface: the effective date is entered via a calendar selector, the approval amount threshold supports range settings (e.g., "≤50,000 yuan"), and the approval responsibility description supports text editing. After data submission, the system automatically associates the current matter, role category, and role's unique identifier to generate a complete authority record containing the effective date, amount threshold, and responsibility description, storing it in the authority record table to ensure accurate association between authority and the three-dimensional hierarchy.

[0128] S200.3. Based on the three-dimensional hierarchical relationship of S200.1 and the authority attributes of S200.2, a hierarchical authority data tree Tree(M, A) is generated, where:

[0129] The root node set is the event {T1, T2, ..., T}. n}; where n represents the number of nodes in the root node level;

[0130] Each item T i The set of child nodes is the class of roles associated with it {C} j1 C j2 C jm}; where m represents each item T i The following is related to the role category C j quantity;

[0131] Each role is categorized as C j The set of child nodes is the set of roles {R} associated with it. k1 R k2 , ..., R kp}; where p represents each role category C j The related role R k quantity;

[0132] Each leaf node (role R) k The associated authority record R = (T) generated by S200.2 i C j R k (D, V, P), enabling access to the effective date, approval amount threshold, and description of approval responsibilities;

[0133] Understandably, the system constructs the authority data tree according to the following logic:

[0134] Root node: Retrieves all items from the item table (such as "Purchase Approval" and "Financial Reimbursement");

[0135] Second-level node: Based on the task-related role classification table, obtain the role classification for each task;

[0136] Leaf node: Based on the role category, associate the role table to obtain the specific role and associate the attribute data in the authority record table.

[0137] The front end uses a tree-like component to render the hierarchical structure, with leaf nodes displaying role names and authority attributes. For example, under the root node "Procurement Approval", the category "Procurement Administrator" is expanded, and the "Level 1 Procurement Specialist" role node under it displays authority information such as "Effective Date: 2023-01-01" and "Approval Amount Threshold: ≤50,000 RMB", realizing a visual representation of the three-dimensional relationship.

[0138] S200.4, Implement multi-dimensional query optimization:

[0139] For the effective date D, construct a range index I. D ={[D min D max ]}, where D min and D max These are the minimum and maximum dates within the query range, respectively.

[0140] For the description of approval responsibilities P, construct a keyword hash index H. P ;

[0141] H P ={(w1, h1), (w2, h2),..., (w q h q )};wherein, w q This indicates keywords in the job description; h q Indicates keyword w q The corresponding hash value;

[0142] In the process of querying using tree lists and related views, the formula Q = I is used. D ∩H P , performs an intersection operation to quickly locate the set of authority records that meet the conditions; where Q represents the result set of a multi-condition joint query; ∩ represents the intersection operation of the sets.

[0143] It is understood that the index building strategy in this embodiment includes: effective date index: an index is created on the effective date field of the authority record table to support fast range queries;

[0144] Keyword Index for Responsibilities: Keywords (such as "review" and "compliance") in the description of approval responsibilities are extracted through word segmentation algorithms, and an index mapping relationship is generated to accelerate keyword retrieval;

[0145] Furthermore, when a user enters query conditions (such as "effective in 2023 and includes audit responsibilities"), the system filters records that match the time range through the effective date index, matches the responsibility description through the keyword index, performs the intersection operation, returns the results, and displays them in the front-end related view.

[0146] It's worth noting that the system uses database foreign key constraints to implement cascading operations: deleting an item automatically deletes associated role categories, roles, and authority records; when authority attributes are updated, the front-end tree component refreshes in real time. In case of query errors, if the keyword index has no matching results or the date range exceeds the data range, the system prompts the user to adjust the query conditions, ensuring the integrity of the interaction process.

[0147] The flowchart incremental parsing unit 300 employs a collaborative strategy of initial full parsing and timed incremental parsing. The initial full parsing traverses all nodes in the flowchart, extracts BPMN business tags for roles, authority, and approval responsibilities, generates full-scale associated data, and constructs an initial baseline version. The timed incremental parsing uses a BPMN business tag fingerprint comparison algorithm to perform feature hash comparisons of the business tags, node roles, node authority, and node approval responsibilities between the current flowchart and the historical baseline version, accurately identifying changed nodes. Incremental parsing and data updates are performed only on changed nodes, achieving efficient synchronization of process data.

[0148] In this embodiment, the timed incremental parsing of the flowchart incremental parsing unit 300 adopts the BPMN service tag fingerprint comparison algorithm, including the following steps:

[0149] S300.1, Current Flowchart Feature Extraction and Assembly:

[0150] When incremental parsing is triggered periodically, all nodes in the current flowchart are traversed to extract the following basic business attributes and BPMN business tags:

[0151] Basic business attributes: Node role R (e.g., "financial director"), node authority A (e.g., "approval amount ≤ 100,000 yuan"), node approval responsibility P (e.g., "review invoice compliance");

[0152] BPMN business tags: Node type T (e.g., "User task", "Exclusive gateway"), Event triggering rule E (e.g., "Timer trigger, timeout = 3 days"), Process connection relationship C (e.g., "Previous node ID = 101, subsequent node ID = 103");

[0153] The basic business attributes and BPMN business tags are concatenated into a feature string using the following formula. in, To prevent conflicting delimiters and avoid parsing discrepancies when attribute values ​​contain regular delimiters; R i A i P i T i E i C i These correspond to the role, authority, approval responsibility, node type, event triggering rules, and process connection relationship of the i-th node, respectively.

[0154] S300.2, Business fingerprint hash calculation:

[0155] To generate the business fingerprint of the current node, the SHA-256 hash algorithm is used to hash the feature string S. curr,i Perform encrypted calculations and define the business fingerprint H. curr，iThe calculation formula for H is as follows: curr,i =SHA-256(S curr，i ); where SHA-256 outputs a 256-bit hash value, ensuring that different feature strings generate a unique fingerprint and have collision resistance;

[0156] Construct the current fingerprint set H set_curr :

[0157] H set_curr ={H curr，i |i = 1, 2, ..., m};

[0158] Among them, H curr,i This represents the business fingerprint of the i-th node in the current flowchart, where m is the total number of nodes in the current flowchart.

[0159] S300.3, Historical baseline fingerprint retrieval and comparison:

[0160] Retrieve historical benchmark fingerprint database D from the database base Each record contains a node ID and the historical role R of the j-th node. base，j The authority of the j-th historical node A base,j Historical approval responsibilities P at the j-th node base,j The j-th historical node of type T base j, the triggering rule of the j-th historical event E base j, the historical process connection relationship of node j C base j and its corresponding hash value H base，j ;

[0161] Construct historical fingerprint set H set_base The formula is: H set_base ={H base,j |j = 1, 2, ..., n};

[0162] Where n is the total number of nodes in the historical baseline version;

[0163] S300.4, Precise positioning of change nodes:

[0164] Change nodes are identified using symmetric difference operations, with the following formula:

[0165] H diff =H set_curr ΔH set_base =(H set_curr -H set_base )∪(H set_base -H set_curr );

[0166] Among them, H diffThis represents the set of differing fingerprints, i.e., the set of fingerprints corresponding to nodes that have undergone changes; Δ represents the symmetric difference operator, used to calculate the elements that are not common to the two sets; H set_curr -H set_base This represents a unique element in the current fingerprint set, corresponding to a newly added node; H set_base -H set_curr This represents a unique element in the historical fingerprint set, corresponding to a deletion node or an attribute modification node;

[0167] For each difference fingerprint, the change type is confirmed by associating it with the node ID:

[0168] If the fingerprint H is different diff，k ∈(H set_curr -H set_base ), and the node ID corresponding to this fingerprint is in the historical benchmark database D. base If it does not exist in the current flowchart, it is determined to be a newly added node (the node added at node number i in the current flowchart).

[0169] If the fingerprint H is different diff，l ∈(H set_base -H set_curr If the node ID corresponding to the fingerprint exists in the current flowchart (but the fingerprint is different), then it is determined to be an attribute modification node (that is, the node's role, authority, approval responsibility, node type, event rules or process connection relationship is modified, and the corresponding historical node number j and the current node number i are the same node but the fingerprint has changed).

[0170] If the fingerprint H is different diff，l ∈(H set_base -H set_curr If the node ID corresponding to the fingerprint does not exist in the current flowchart, then it is determined to be a deleted node (the corresponding historical node number j exists, and the current node number i has no corresponding node).

[0171] S300.5 Incremental Data Synchronization and Efficiency Optimization:

[0172] For the identified changed nodes, perform the following incremental update operations:

[0173] Add a node: Extract the current node role R of this node. curr,i Current node authority A curr,i Current node approval responsibilities P curr，i Current node type T curr,i Current event triggering rule E curr，i Current process connection relationship C curr，i And current business fingerprint H curr,i Inserted as a new data item into the historical benchmark fingerprint database D base ;

[0174] Delete node: from historical benchmark fingerprint database D base Delete the record corresponding to this node (historical node number j);

[0175] Attribute modification node: From historical benchmark fingerprint database D base Delete the old record of the node (corresponding to the historical node number j) and insert the new record to complete the attribute update.

[0176] As a further explanation of this embodiment, in the initial full-scale parsing process of this embodiment, when the system parses the flowchart for the first time, it traverses all nodes to extract attributes and BPMN tags, and concatenates feature strings. Taking the "Financial Approval" node as an example, the initial feature string is: Financial Director ||| Approval Amount ≤ 100,000 RMB ||| Review Invoice Compliance ||| User Task ||| Timer Triggered, Timeout = 3 Days ||| Pre-node ID = 101, Post-node ID = 103. The hash value is calculated using the SHA-256 algorithm, stored in the historical benchmark database, and marked with the version number V1.0.

[0177] As a further explanation of this embodiment, in the timed incremental parsing of this embodiment, efficient synchronization of process data is achieved through the following steps:

[0178] First, when the scheduled task triggers incremental parsing, the system traverses all nodes of the current flowchart through the process engine interface, extracts basic business attributes such as node roles, node authority, and approval responsibilities, as well as BPMN business tags such as node type, event triggering rules, and process connection relationships;

[0179] Subsequently, the feature string is encrypted using the SHA-256 hash algorithm to generate a 256-bit business fingerprint (e.g., a hexadecimal string). The system collects the business fingerprints of all nodes in the current flowchart to form the current fingerprint set for comparison with historical baseline versions. This step leverages the collision-resistant properties of hash algorithms to ensure that different feature strings generate unique fingerprints, providing an accurate basis for subsequent change identification.

[0180] Then, the latest version of node fingerprint data is retrieved from the historical benchmark fingerprint database to construct a historical benchmark fingerprint set. A symmetric difference operation is used to compare the current fingerprint set with the historical benchmark fingerprint set to identify the sets of differing fingerprints. For example, if the current fingerprint set contains fingerprints not found in the historical benchmark database, the corresponding node is identified as a newly added node; if a fingerprint in the historical benchmark database does not exist in the current set, the corresponding node is identified as a deleted or attribute-modified node.

[0181] Next, for each fingerprint in the difference fingerprint set, the change type is confirmed by associating it with the node ID: if the node ID corresponding to the difference fingerprint does not exist in the historical baseline database, it is determined to be a new node; if the node ID exists in the current flowchart but the fingerprint is different, it is determined to be an attribute modification node (such as attribute changes such as role, authority, approval responsibility, etc.); if the node ID does not exist in the current flowchart, it is determined to be a deleted node.

[0182] Finally, targeted updates are performed on the identified change nodes: when a new node is added, its characteristic string, business fingerprint, and other information are inserted into the historical baseline fingerprint database; when a node's attributes are modified, the old record is deleted and the new record is inserted; when a node is deleted, the corresponding data is removed from the database. This process only handles change nodes, avoiding the resource consumption of full parsing and achieving efficient synchronization of process data.

[0183] Furthermore, in this embodiment, the flowchart incremental parsing unit 300 implements periodic parsing through a Quartz timer. The initial frequency can be configured in the background. When there are no node changes after three consecutive parsings, the interval is automatically extended. If a change is detected, the initial frequency is restored. For network anomalies (such as process engine interface timeout), logs are recorded and retry is delayed (up to 3 times). If the node attribute format is incorrect (such as containing illegal characters), the node is skipped and a report containing the node ID, error type, and repair suggestions is generated. If the hash calculation is abnormal (such as feature string transcoding failure), MD5 auxiliary verification is automatically triggered. If it still fails, it is handled as an attribute format error scenario.

[0184] The role classification permission unit 400 is used to associate departments and personnel with role classifications. It adopts a data row filtering mechanism to realize fine-grained access control of authority data. When unauthorized users access the data, grayed-out empty cells are displayed.

[0185] In this embodiment, the role classification permission unit 400 includes a role-organization association module 410 and a power data filtering module 420, wherein:

[0186] The role-organization association module 410 integrates an interactive interface and association logic to support system administrators in binding roles, departments, or personnel, and to generate role-organization association relationships. After binding, role-organization association relationship data is generated and stored according to the data structure of role category ID, associated object ID, and object type, thereby realizing the association mapping between role categories and departments and personnel in the enterprise organizational structure.

[0187] As a further explanation of this embodiment, the front-end provides a two-way selection interface for role category trees and organizational structure trees in the interactive interface, supporting batch selection of departments / personnel and setting association status and expiration time. For example, after selecting the "Chief Financial Officer" role category, the "Finance Department" department is selected in the organizational structure tree, and the expiration time is set to "long-term valid". In the back-end verification, after the interface receives the bound data, it verifies the legality of the role category ID and organization ID (queries whether the corresponding table exists), verifies the validity of the expiration time format, and inserts a record into the role-organization association table after passing the verification, returning an operation success message.

[0188] The authority data filtering module 420 integrates permission verification and data rendering logic. When a user initiates an authority data access request, it calls the role-organization association data to determine permissions, specifically including:

[0189] When the user's associated role matches the permission configuration of the data to be accessed (i.e., the user has permission), the data will be rendered and returned normally according to the preset data display rules.

[0190] When a user's associated role does not have corresponding access permissions, special rendering logic is triggered for unauthorized data rows, which are presented as grayed-out empty cells (e.g., the cells are filled in gray through interface style control, and placeholders such as "No permission to access" are displayed), clearly reflecting the permission restriction result.

[0191] In this embodiment, the authority data filtering module 420 includes an authority verification submodule 421 and an access log submodule 422, wherein:

[0192] The permission verification submodule 421 performs real-time verification when a user initiates a permission data access request;

[0193] Furthermore, the real-time verification specifically includes:

[0194] Association validity verification: Check the user's role-organization association to determine if it is in a valid state (not deleted or frozen); for example, obtain the user ID or department ID from the user's login status, query the role-organization association table, and filter out association records with a status of "valid" and whose expiration time has not expired. If no valid association is found, it is determined as "association invalid".

[0195] Permission matching verification: Based on preset rules (such as "financial role" corresponding to "financial data row"), verify whether the user role and the permissions of the data row to be accessed match; for example, based on the ID of the data row of the user's requested authority, query the permission configuration table. If a record with an access level other than "no permission" is matched, it is determined that the permissions match; otherwise, it is determined that the permissions do not match.

[0196] Interception Feedback: If any validation fails, the access request is intercepted, the grayed-out rendering logic is invoked, and the user is informed of the unauthorized result. If validation fails, the front-end triggers special rendering logic, setting the corresponding data row cell to a gray background and filling it with the "No Permission to Access" placeholder text; the back-end interface directly returns empty data to avoid real data leakage.

[0197] The access log submodule 422 integrates log recording logic. When a user initiates a data access request, it automatically generates and stores standardized access logs for auditing and tracing authorized access behavior. Regardless of whether the permission verification passes, the system automatically generates access logs: obtaining a timestamp accurate to milliseconds through a system time function, extracting user information from the login state, obtaining data row identifiers from the request parameters, and combining the verification result with the reason for unauthorization (if any), writing the logs asynchronously to ensure that the main process response speed is not affected.

[0198] Furthermore, log data items include:

[0199] Access timestamp (accurate to milliseconds);

[0200] Access the user's unique identifier (user ID);

[0201] The unique identifier (row ID) of the accessed authority data row;

[0202] Permission verification result (enumerated values: success / unauthorized);

[0203] Reason for unauthorization (association failure / permission mismatch, only filled in if the verification result is unauthorized).

[0204] As a further explanation of this embodiment, this embodiment constructs three types of core data tables to support the permission management logic, specifically including:

[0205] The Role-Organization Association Table stores the binding relationships between role categories and departments / personnel. It includes fields such as Association ID (primary key), Role Category ID, Organization ID (associated with the enterprise's organizational structure), Organization Type (department / personnel), Association Status (valid / frozen / deleted), and expiration time. For example, when the "Chief Financial Officer" role category is associated with the "Finance Department" department, the Role Category ID, Department ID, and Organization Type are recorded as "Department," and the association status is set to "Valid."

[0206] The authority data row permission configuration table defines the access permissions for specific authority data rows for role categories, including the configuration ID (primary key), role category ID, authority data row ID, access level (editable / viewable only / no permission), and permission rule description. For example, the access level for the "Purchasing Specialist" role category to "Purchase Request #001" is configured as "viewable only".

[0207] Access Log Table: Records access permissions and includes fields such as Log ID (primary key), access timestamp, user ID, username, authority data row ID, data row name, permission verification result (success / unauthorized) and reason for unauthorized access, providing data support for auditing and tracing.

[0208] Furthermore, this embodiment ensures the robustness of access control through the following mechanisms:

[0209] First, for the lifecycle management of role-organization associations, the system deploys a daily scheduled task (e.g., at 1:00 AM) to scan the role-organization association table, filter records whose expiration time is earlier than the current time, automatically update their association status to "frozen", and trigger the administrator notification mechanism (e.g., system message push) to ensure that expired associations no longer participate in permission verification.

[0210] Then, for scenarios with multiple role-based permission conflicts (such as a single user being associated with multiple role categories through different organizations such as their department or temporary project team), access permissions for the same data row are strictly determined according to the priority rule of "editable > view only > no permission" to avoid access abnormalities caused by permission conflicts.

[0211] Finally, regarding support for dynamic permission changes, when the management side modifies and saves the permission configuration of the authority data row, the system immediately updates the record in the permission configuration table of the authority data row; when users access the data row subsequently, the permission verification submodule 421 directly reads the latest configuration and performs verification to ensure the real-time nature of permission control.

[0212] The approval responsibility closed-loop unit 500 is used to maintain the approval responsibility description of the flowchart node and integrates feedback submission, record traceability and email notification functions.

[0213] In this embodiment, the approval responsibility closed-loop unit 500 includes a responsibility editing module 510, a feedback information interaction module 520, a historical version tracing module 530, and an event notification triggering module 540, wherein:

[0214] The responsibility editing module 510 integrates a node-level responsibility editing interface, which supports administrators in creating and modifying the approval responsibilities of flowchart nodes, automatically associating the responsibility content with the unique node identifier, and generating a responsibility description dataset containing operation timestamps.

[0215] As a further explanation of this embodiment, the system administrator maintains approval responsibilities through the process of "node selection - rich text editing - version increment - storage trigger notification". The front end provides a "node responsibility management" page. The left side displays the flowchart nodes in a tree structure (such as "procurement process - requirement approval - financial approval"), and the right side is a rich text editing area that supports formatting such as paragraphs, bolding, and lists, and has a length limit of ≤500 characters. When a node is selected, the currently effective responsibility content is automatically loaded (if there is no content, the system will prompt "no responsibility description available"). When "save" is clicked, the system verifies the validity of the node ID (by querying the flowchart node table) and the compliance of the content length. If the verification is successful, a new version is automatically generated based on the existing version number +1 (such as V1.0-V2.0). The responsibility content, version number, and modification information are written into the approval responsibility table, and the event notification trigger module 540 is triggered to send a responsibility change notification to the associated approvers.

[0216] The feedback information interaction module 520 is used to integrate a feedback interaction entry into the approval business operation interface. Users can submit feedback information related to approval responsibilities (such as suggestions for supplementing the description of responsibilities) and store feedback data in structured fields such as user ID, node ID, feedback content, and submission time to form a traceable set of feedback records.

[0217] As a further explanation of this embodiment, users participate in responsibility optimization through the process of "feedback entry - content submission - data storage - trigger administrator notification" in the approval business interface. A "responsibility feedback" button is set in the approval operation area (such as the "purchase application form details page"). After clicking, an interactive box that automatically fills in the node name and the current responsibility content (read-only) pops up. A multi-line input box with ≤300 characters is provided below. After submitting feedback, the system verifies the legality of the node ID and responsibility ID (by querying the approval responsibility table) and the compliance of the feedback content length. If it passes, the system writes the user ID, feedback content, submission time and default "unprocessed" status into the feedback record table and triggers the event notification trigger module 540 to push a pending notification containing the feedback content and node identifier to the system administrator.

[0218] The historical version tracing module 530 supports retrieving historical modification records of approval responsibilities by node ID, displaying the differences in responsibility content in the form of version comparison, and displaying the feedback records and processing status of the corresponding nodes in association, so as to realize two-way tracing of responsibilities and feedback.

[0219] As a further explanation of this embodiment, the historical version tracing module 530 realizes bidirectional tracing of responsibilities and feedback through "node retrieval - version list - difference comparison - feedback association". It supports querying by node ID / name and displays the version list (including version number, modification time, and modifier). After clicking "version comparison", a pop-up window displays the differences between the old and new versions in a left-right split format. Newly added content is highlighted with a green background, and deleted content is highlighted with a red strikethrough. The reason for the version modification is also displayed simultaneously (such as "adopted due to feedback XXX"). The version details page displays the feedback records for that version (including feedback person, content, processing status, and processing opinion), realizing the association tracing from "responsibility version" to "feedback opinion".

[0220] The event notification triggering module 540 adopts an event-driven mechanism. When the description of a responsibility changes, it sends a notification containing a version comparison to the associated approvers. When new unprocessed feedback is added, it pushes a pending notification containing the feedback content and node identifier to the administrator to ensure a closed loop of responsibility management.

[0221] As a further explanation of this embodiment, the event notification triggering module 540 achieves information synchronization based on event-driven and multi-channel outreach. When the responsibility version is updated, the system automatically assembles notification content including version comparison, modifier, and reason for change. It obtains the list of approvers associated with the node through the role-organization association table, sends an email to them (e.g., title: "[Responsibility Change] Node XXX (Version Vx.x)"), and generates an unread notification in the system (recorded in the notification log table). After feedback is submitted, the system extracts the feedback content and node information, sends an email to the administrator list (e.g., title: "[Feedback to be Processed] Node XXX"), and pushes a to-do reminder in the system (jumping to the processing interface). If the email fails to send, the system marks the reason in the notification log table (e.g., "SMTP connection timeout"), and automatically retryes after 10 minutes (up to 3 times). If it still fails, a background error reminder is triggered for the administrator to manually correct the recipient information.

[0222] As a further explanation of this embodiment,

[0223] Furthermore, during a responsibility version rollback, the administrator selects the old version from the historical version list and clicks "Set as Current Version." After verifying the administrator's permissions, the system marks that version as the currently effective version and updates the modification time, re-triggers the responsibility change notification. When processing feedback in batches, the administrator selects multiple unprocessed feedback items in the feedback management interface and performs a "Batch Accept / Reject" operation. The system updates the processing status, comments, handlers, and time in batches and pushes the result notification to the feedback users. If a notification fails to send, the above retry mechanism is followed to ensure that the notification reaches the intended recipient.

[0224] The requirement solution merging unit 600 integrates the requirement application and solution approval process, and sets a "special approval" checkbox at the approval node of the process management department. After checking, it supports the custom filling in of 1-5 level approvers, and automatically matches the product manager approver according to the preset rules of requirement classification.

[0225] In this embodiment, the demand scheme merging unit 600 includes a process association module 610, a special approval configuration module 620, and an approver intelligent matching module 630, wherein:

[0226] The process association module 610 is used to establish the association between the demand application process and the solution approval process. Based on the configuration mapping mechanism, the process mapping interface allows administrators to set association rules according to the demand category, business department and at least one parameter dimension for configuring association rules, and generate a process association table (recording the demand process ID, solution process ID, association conditions and effective time) to realize the connection and status synchronization of the two processes.

[0227] As a further explanation of this embodiment, the front end provides a process mapping interface, displaying the requirement categories and business department tree on the left and listing the solution processes on the right; it supports dragging and dropping solution processes to target nodes, setting effective time and associated conditions (such as "requirement amount > 500,000 yuan"). The back end verifies the validity of the process ID and the condition syntax; if valid, it stores it in the process association table, realizing the automatic association between requirements and solution processes (such as automatically triggering the start of associated solution processes after a requirement process is submitted).

[0228] Furthermore, the parameters used to configure association rules include, but are not limited to, requirement category and business department, and can also be extended to dimensions such as requirement priority, project stage, and applicant role. Its core function is to define the association logic between the requirement application process and the solution approval process.

[0229] The special approval configuration module 620 is designed to meet the needs of special approval scenarios and provides differentiated approver configuration capabilities at the approval nodes of the process management department. It adopts a method of embedding a Boolean checkbox (which is unchecked by default) in the approval interface. When checked, the custom approver input area is activated, which supports the input of 1-5 approvers (fields: approver ID, approval level (level 1-5), approval responsibility), and verifies the number of inputs in real time.

[0230] As a further explanation of this embodiment, in the approval interface of the approval node of the process management department, the approval interface embeds an "Enable Special Approval" checkbox (unchecked by default). When checked, the approver input area is displayed, which supports the selection of 1-5 approvers and the filling in of the approval level (level 1-5) and responsibilities. At the same time, when submitting, the number of approvers (1≤number≤5) and the legality of the users are verified (by querying the user table). After passing the verification, the approver information is stored in the special approval configuration table in JSON format and associated with the current process instance.

[0231] The intelligent approver matching module 630 is used to automatically match product manager approvers. Based on the preset mapping rules of requirement classification and approver (stored in the system configuration table), it automatically queries the associated product managers by reading the requirement classification tags. If special approval has been enabled, it integrates the custom-entered approvers with the matched product managers to generate the final approver list.

[0232] In this embodiment, the demand scheme merging unit 600 further includes a state synchronization module 640 and an exception handling module 650, wherein:

[0233] The status synchronization module 640 is used to synchronize the status changes of the demand application and solution approval process in real time, automatically update the integrated status table through the status monitoring mechanism, and send status change notifications to relevant personnel.

[0234] As a further explanation of this embodiment, the status synchronization module 640 captures status changes (such as "submitted", "approved", "rejected") in the requirement application and solution approval process in real time through an event listening mechanism, automatically updates the integrated status table, and triggers cross-process status linkage. For example, when the requirement process status changes to "approved", the system automatically starts the associated solution process and synchronizes its status to "pending approval"; when the solution process is rejected, the requirement process status is synchronously updated to "solution rejected", and a notification containing status change details is sent to relevant personnel.

[0235] The exception handling module 650 is used to deal with abnormal situations during process operation and handles abnormal situations (such as missing approver, data synchronization failure, etc.) based on preset rules.

[0236] As a further explanation of this embodiment, the exception handling module 650 pre-sets rules to handle typical exceptions: when the approver is missing, a default product manager is automatically assigned and the log is recorded; when data synchronization fails, it is retried according to the rule of "5-minute interval × 3 times", and if it still fails, a work order is generated; when there is a conflict in the associated rules, it is executed according to the principle of the latest effective time to ensure that the process flow logic is consistent.

[0237] Example 2

[0238] like Figure 2As shown, this embodiment also provides a process asset management method based on a BPM management system. The process asset management system based on the aforementioned BPM management system includes the following steps:

[0239] S100, Hierarchical Construction of Process Framework: Construct a tree-like business classification framework, associate items and authority data through parent codes, generate a hierarchical structure with framework paths, and achieve unique control of child node names under the same parent node;

[0240] S200, Incremental Flowchart Parsing and Authority Organization: A collaborative strategy of initial full parsing and timed incremental parsing is adopted; the initial full parsing traverses the flowchart nodes and extracts roles, authority, approval responsibility attributes, BPMN, and business tags; the timed incremental parsing uses a business tag fingerprint comparison algorithm to compare the current flowchart with the historical baseline version using feature hashing, identifies change nodes, and performs incremental updates; at the same time, based on the three-dimensional hierarchical relationship model of item-role classification-role, authority attribute parameters are bound to generate a hierarchical authority data tree.

[0241] S300, Closing the Approval Responsibility Loop and Merging the Requirement Process: Maintain the approval responsibility description of the flowchart nodes and integrate feedback submission, record tracking and email notification functions; integrate the requirement application and solution approval process, set special approval check boxes in the approval nodes of the process management department, and after checking, support the custom filling in of 1-5 level approvers, and automatically match the product manager approver according to the preset rules of requirement classification.

[0242] S400, Access Control and Process Status Management: Associating roles with departments and personnel, and using a data row filtering mechanism to achieve fine-grained access control of authority data; synchronizing the status of requirement applications and solution approval processes in real time, and handling abnormal situations based on preset rules.

[0243] Those skilled in the art will understand that the process of implementing all or part of the steps of the above embodiments can be carried out by hardware or by a program instructing the relevant hardware.

[0244] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely preferred examples and are not intended to limit the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. A process asset management system based on BPM management, characterized in that, include: The process framework construction unit (100) is used to construct a tree-like business classification framework. By associating matters and authority data through parent codes, a hierarchical structure with a framework path is generated to achieve unique control of the names of child nodes under the same parent node. A multi-dimensional authority management unit (200) is established, which uses a tree-like list and related views to realize multi-dimensional visualization and query of authority division based on matters, role classification and role dimensions; The flowchart incremental parsing unit (300) adopts a collaborative strategy of initial full parsing and timed incremental parsing; The initialization process involves full parsing and traversing all nodes of the flowchart, extracting BPMN business tags for roles, authority, and approval responsibilities, generating full associated data, and constructing an initial baseline version. The timed incremental parsing uses the BPMN business tag fingerprint comparison algorithm to compare the business tags, node roles, node authority, and node approval responsibility attributes of the current flowchart with those of the historical baseline version using feature hashing, accurately identifying changed nodes; incremental parsing and data updates are only performed on changed nodes, achieving efficient synchronization of process data; Role classification permission unit (400), the role classification permission unit (400) is used to associate departments and personnel for role classification, and adopts a data row filtering mechanism to realize fine-grained access control of authority data. When unauthorized users access, grayed-out empty value cells are displayed. Approval responsibility closed-loop unit (500), the approval responsibility closed-loop unit (500) is used to maintain the approval responsibility description of the flowchart node, and integrate feedback submission, record traceability and email notification functions; The requirement solution merging unit (600) integrates the requirement application and solution approval process, and sets a "special approval" checkbox at the approval node of the process management department. After checking, it supports custom filling in the approvers of level 1-5, and automatically matches the product manager approvers according to the preset rules of requirement classification.

2. The process asset management system based on BPM management system according to claim 1, characterized in that, The process framework construction unit (100) includes a hierarchical calculation module (110), a path generation module (120), and a uniqueness verification module (130), wherein: The hierarchical calculation module (110) integrates a parent frame selection interaction interface to receive the selection instruction of the parent frame; if no parent frame is associated, the current frame is marked as the top level; if a parent frame is associated, the level of the current frame is the level value of the parent frame plus 1. The path generation module (120) is used to receive the parent path and the current level value output by the level calculation module (110) and generate a hierarchical frame path; The uniqueness verification module (130) is used to monitor the child node name input action and verify the uniqueness of the child node name under the same parent node in real time; if the duplicate child node name under the same parent node is detected, a pop-up window will prompt the name conflict and block the framework storage process.

3. The process asset management system based on BPM management system according to claim 1, characterized in that, The multi-dimensional authority management unit (200) realizes multi-dimensional organization and query of authority through a multi-dimensional authority hierarchy mapping algorithm, including the following steps: S200.1 Constructing a three-dimensional hierarchical relationship model: Define the three-dimensional hierarchical relationship between tasks, roles, and roles, and construct a set of triples M = {(T} i C j R k )};wherein, T i C represents the i-th item; j Represents the j-th role category; R k This represents the k-th role; and the same event T i The following role category C j It is unique, belonging to the same role category C. j The character R below k It is unique; S200.2, Binding Authority Attribute Parameters: For each triple (T) i C j R k Bind the set of authority attributes A = {D, V, P}, where: D represents the effective date; V represents the approval amount threshold; and P represents the description of approval responsibilities. Construct a complete record of authority R = (T) i C j R k (D, V, P); S200.

3. Based on the three-dimensional hierarchical relationship of S200.1 and the authority attributes of S200.2, a hierarchical authority data tree Tree(M, A) is generated, where: The root node set is the event {T1, T2, ..., T}. n }; where n represents the number of nodes in the root node level; Each item T i The set of child nodes is the class of roles associated with it {C} j1 C j2 C jm }; where m represents each item T i The following is related to the role category C j quantity; Each role is categorized as C j The set of child nodes is the set of roles {R} associated with it. k1 R k2 , ..., R kp }; where p represents each role category C j The related role R k quantity; Each leaf node is associated with the authority record R = (T) generated by S200.

2. i C j R k (D, V, P), enabling access to the effective date, approval amount threshold, and description of approval responsibilities; S200.4, Implement multi-dimensional query optimization: For the effective date D, construct a range index I. D ={[D min D max ]}, where D min and D max These are the minimum and maximum dates within the query range, respectively. For the description of approval responsibilities P, construct a keyword hash index H. P ; H P ={(w1, h1), (w2, h2),..., (w q h q )};wherein, w q This indicates keywords in the job description; h q Indicates keyword w q The corresponding hash value; In the process of querying using tree lists and related views, the formula Q = I is used. D ∩H P , performs an intersection operation to quickly locate the set of authority records that meet the conditions; where Q represents the result set of a multi-condition joint query; ∩ represents the intersection operation of the sets.

4. The process asset management system based on BPM management system according to claim 1, characterized in that, The timed incremental parsing of the flowchart incremental parsing unit (300) adopts the BPMN service tag fingerprint comparison algorithm, including the following steps: S300.1, Current Flowchart Feature Extraction and Assembly: When incremental parsing is triggered periodically, all nodes in the current flowchart are traversed to extract the following basic business attributes and BPMN business tags: Basic business attributes: Node role R, Node authority A, Node approval responsibility P; BPMN business tags: Node type T, Event triggering rule E, Process connection relationship C; The basic business attributes and BPMN business tags are concatenated into a feature string using the following formula. in, R is a collision prevention separator. i A i P i T i E i C i These correspond to the role, authority, approval responsibility, node type, event triggering rules, and process connection relationship of the i-th node, respectively. S300.2, Business fingerprint hash calculation: To generate the business fingerprint of the current node, the SHA-256 hash algorithm is used to hash the feature string S. curr,i Perform encrypted calculations and define the business fingerprint H. curr，i The calculation formula for H is as follows: curr,i =SHA-256(S curr，i ); where SHA-256 outputs a 256-bit hash value; Construct the current fingerprint set H set_curr : S300.3, Historical baseline fingerprint retrieval and comparison: Retrieve historical benchmark fingerprint database D from the database base Each record contains a node ID and the historical role R of the j-th node. base，j The authority of the j-th historical node A base,j Historical approval responsibilities P at the j-th node base,j The j-th historical node of type T base j, the triggering rule of the j-th historical event E base j, the historical process connection relationship of node j C base j and its corresponding hash value H base，j ; Construct historical fingerprint set H set_base , S300.4, Precise positioning of change nodes: Change nodes are identified using symmetric difference operations, with the following formula: H diff =H set_curr ΔH set_base =(H set_curr -H set_base )∪(H set_base -H set_curr ); Among them, H diff This represents the set of differing fingerprints, i.e., the set of fingerprints corresponding to nodes that have undergone changes; Δ represents the symmetric difference operator, used to calculate the elements that are not common to the two sets; H set_curr -H set_base This represents a unique element in the current fingerprint set, corresponding to a newly added node; H set_base -H set_curr This represents a unique element in the historical fingerprint set, corresponding to a deletion node or an attribute modification node; For each difference fingerprint, the change type is confirmed by associating it with the node ID: If the fingerprint H is different diff，k ∈(H set_curr -H set_base ), and the node ID corresponding to this fingerprint is in the historical benchmark database D. base If it does not exist in the table, it is considered a newly added node; If the fingerprint H is different diff，l ∈(H set_base -H set_curr If the node ID corresponding to the fingerprint exists in the current flowchart, it is determined to be an attribute modification node; If the fingerprint H is different diff，l ∈(H set_base -H set_curr If the node ID corresponding to the fingerprint does not exist in the current flowchart, then it is determined to be a deleted node; S300.5 Incremental Data Synchronization and Efficiency Optimization: For the identified changed nodes, perform the following incremental update operations: Add a node: Extract the current node role R of this node. curr,i Current node authority A curr,i Current node approval responsibilities P curr，i Current node type T curr,i Current event triggering rule E curr，i Current process connection relationship C curr，i And current business fingerprint H curr，i Inserted as a new data item into the historical benchmark fingerprint database D base ; Delete node: from historical benchmark fingerprint database D base Delete the record corresponding to this node; Attribute modification node: From historical benchmark fingerprint database D base Delete the old record of the node and insert the new record to complete the attribute update.

5. The process asset management system based on BPM management system according to claim 1, characterized in that, The role classification permission unit (400) includes a role-organization association module (410) and a power data filtering module (420), wherein: The role-organization association module (410) integrates an interactive interface and association logic to support system administrators in binding roles, departments, or personnel, and to generate role-organization association relationships. The authority data filtering module (420) integrates permission verification and data rendering logic. When a user initiates an authority data access request, it calls the role-organization association data to determine permissions, specifically including: When the user's associated role matches the permission configuration of the access authority data, the authority data is rendered and returned normally according to the preset data display rules; When a user's associated role does not have corresponding access permissions, special rendering logic is triggered for unauthorized data rows, which are then displayed as grayed-out empty cells to clearly reflect the permission restriction result.

6. The process asset management system based on BPM management system according to claim 5, characterized in that, The authority data filtering module (420) includes an authority verification submodule (421) and an access log submodule (422), wherein: The permission verification submodule (421) performs real-time verification when a user initiates a permission data access request; The access log submodule (422) integrates log recording logic. When a user initiates a request for access to authorized data, it automatically generates and stores standardized access logs for auditing and tracing access behavior.

7. The process asset management system based on BPM management system according to claim 1, characterized in that, The closed-loop approval responsibility unit (500) includes a responsibility editing module (510), a feedback information interaction module (520), a historical version tracing module (530), and an event notification triggering module (540), wherein: The responsibility editing module (510) integrates a node-level responsibility editing interface, which supports administrators to create and modify the approval responsibilities of flowchart nodes, automatically associates the responsibility content with the unique identifier of the node, and generates a responsibility description dataset containing operation timestamps. The feedback information interaction module (520) is used to integrate a feedback interaction entry into the approval business operation interface. Users can submit feedback information related to their approval responsibilities and store feedback data in a structured field according to user ID, node ID, feedback content, and submission time to form a traceable feedback record set. The historical version tracing module (530) supports retrieving historical modification records of approval responsibilities by node ID, displaying the differences in responsibility content in the form of version comparison, and displaying the feedback records and processing status of the corresponding nodes in association, so as to realize two-way tracing of responsibilities and feedback. The event notification triggering module (540) adopts an event-driven mechanism. When the description of responsibilities changes, it sends a notification containing version comparison to the associated approvers. When new unprocessed feedback is added, it pushes a pending notification containing feedback content and node identifier to the administrator to ensure the closed loop of responsibility management.

8. The process asset management system based on BPM management system according to claim 1, characterized in that, The demand scheme merging unit (600) includes a process association module (610), a special approval configuration module (620), and an approver intelligent matching module (630), wherein: The process association module (610) is used to establish the association between the demand application process and the solution approval process. Based on the configuration mapping mechanism, the process mapping interface allows administrators to set association rules according to the demand category, business department and at least one parameter dimension for configuring association rules, generate a process association table, and realize the connection and status synchronization of the two process data. The special approval configuration module (620) is based on the needs of special approval scenarios and is used to provide differentiated approver configuration capabilities at the approval node of the process management department. It adopts the method of embedding a Boolean check control in the approval interface. When checked, the custom approver input area is activated, which supports the input of 1-5 approvers and verifies the input number in real time. The intelligent approving module (630) is used to automatically match product manager approvers. Based on the preset mapping rules of requirement classification and approver, it automatically queries the associated product manager by reading the requirement classification tag. If special approval has been enabled, the custom-entered approver and the matched product manager will be integrated to generate the final approver list.

9. The process asset management system based on BPM management system according to claim 8, characterized in that, The requirement scheme merging unit (600) further includes a state synchronization module (640) and an exception handling module (650), wherein: The status synchronization module (640) is used to synchronize the status changes of the demand application and solution approval process in real time, automatically update the integrated status table through the status monitoring mechanism, and send status change notifications to relevant personnel. The exception handling module (650) is used to deal with abnormal situations during process operation and to handle abnormal situations based on preset rules.

10. A process asset management method based on a BPM management system, wherein the process asset management system based on a BPM management system as described in any one of claims 1-9 is characterized in that, Includes the following steps: S100, Hierarchical Construction of Process Framework: Construct a tree-like business classification framework, associate items and authority data through parent codes, generate a hierarchical structure with framework paths, and achieve unique control of child node names under the same parent node; S200, Incremental Flowchart Parsing and Authority Organization: A collaborative strategy of initial full parsing and timed incremental parsing is adopted. Initial full parsing traverses the flowchart nodes and extracts roles, authority, approval responsibility attributes, BPMN, and business tags. Timed incremental parsing uses a business tag fingerprint comparison algorithm to compare the current flowchart with the historical baseline version using feature hashing, identifies change nodes, and performs incremental updates. At the same time, based on the three-dimensional hierarchical relationship model of item-role classification-role, authority attribute parameters are bound to generate a hierarchical authority data tree. S300, Closing the Approval Responsibility Loop and Merging the Requirement Process: Maintain the approval responsibility description of the flowchart nodes and integrate feedback submission, record tracking and email notification functions; integrate the requirement application and solution approval process, set special approval check boxes in the approval nodes of the process management department, and after checking, support the custom filling in of 1-5 level approvers, and automatically match the product manager approver according to the preset rules of requirement classification. S400, Access Control and Process Status Management: Associating roles with departments and personnel, and using a data row filtering mechanism to achieve fine-grained access control of authority data; synchronizing the status of requirement applications and solution approval processes in real time, and handling abnormal situations based on preset rules.

Images