An enterprise internal process automation management system and method based on cloud collaboration

Abstract

The application discloses an enterprise internal process automation management system and method based on cloud cooperation, and the method comprises the following steps: an end-side node collects process execution events, carries out local preprocessing and behavior rule checking, uploads the events to the cloud after replacing the compliance event activity identification with a mask, the cloud merges to generate a global process event log, mines a topological model, extracts high-frequency flow transfer relations as automation rules, and issues the rules; the end side executes the rules after deviation constraint checking, and feeds back conflict information to the cloud; the cloud corrects node weights according to the conflict and deviation degree, and iterates in a closed loop. Through double checking and end-side desensitization processing, the application solves the problems of mismatch between cloud mining results and end-side execution capability and data privacy leakage, and realizes closed-loop adaptive optimization.

Description

Technical Field

[0001] This invention relates to the field of enterprise internal process management technology, and in particular to an enterprise internal process automation management system and method based on cloud collaboration. Background Technology

[0002] Enterprise process management is a core component of business operations. As enterprises become increasingly digitalized, their demand for automated business process management is growing. Traditional enterprise process automation methods mainly fall into two categories: rule-based workflow engines, which drive process execution through pre-configured nodes and flow conditions; and process mining-based methods, which analyze historical event logs to identify actual processes and optimize bottlenecks.

[0003] Rule-based workflow engines require manual configuration of all process nodes, flow conditions, and exception handling rules before system deployment. In large enterprises, business processes are diverse and complex, with significant cross-functional collaboration and data flow between different departments. Manually configuring all processes is extremely labor-intensive, and any changes to the processes necessitate reconfiguration of all related rules, resulting in very high maintenance costs. More importantly, there is often a significant discrepancy between the manually configured processes and the processes actually executed by employees, leading to a disconnect between the automated processes and actual employee operations, thus greatly diminishing the effectiveness of automation.

[0004] Process mining-based methods automatically discover the topology of actual business processes by analyzing event logs accumulated in enterprise information systems. While these methods can reflect the actual execution of processes, they suffer from significant real-time issues. Event logs are typically collected and analyzed post-event, resulting in a time lag of hours or even days between the occurrence of a process event and the output of the mining results. This lag limits the value of the mining results in guiding real-time process automation. Furthermore, centralized collection and storage of event logs aggregates all process event data to the cloud or central servers, posing a risk of leakage to sensitive internal enterprise data. In process scenarios involving cross-departmental and cross-system processes, the centralized data processing model significantly conflicts with the enterprise's data security compliance requirements.

[0005] In recent years, some research has attempted to combine cloud computing capabilities with enterprise on-premises computing resources. For example, some methods deploy the training process of the process model in the cloud and the inference process on edge nodes. While these methods achieve cloud-edge division of labor in terms of computing resource allocation, they are essentially still a one-way output of analysis results from the cloud to the edge, lacking a feedback verification mechanism from the edge to the cloud analysis results. When the process model generated by global data mining in the cloud is deployed to the edge for execution, the edge cannot verify the feasibility of the process model in its local operating environment, leading to a mismatch between cloud analysis results and edge execution capabilities. Process steps deemed feasible by the cloud may fail to execute on the edge due to local system interface limitations, differences in permission configurations, or incompatible data formats, resulting in interruptions of automated processes and frequent manual intervention.

[0006] In summary, the existing technology has the following technical problems:

[0007] (1) The cloud process mining results lack edge behavior constraint verification. There is no two-way verification mechanism between the process steps issued by the cloud and the actual execution capability of the edge, resulting in a high deviation rate of automated execution.

[0008] (2) The centralized process event data collection and storage method cannot simultaneously protect data privacy and ensure the integrity of process analysis. Sensitive business data faces the risk of leakage during transmission and centralized storage.

[0009] (3) There is a one-way information flow between process mining and process execution. The real-time execution feedback data generated during process execution cannot be effectively used to correct the cloud process analysis results. The system lacks closed-loop adaptive optimization capability.

[0010] (4) In existing cloud-edge collaboration methods, the division of labor between the cloud and the edge is limited to the level of computing task allocation, and the collaborative coupling of analysis results and execution constraints is not achieved at the level of process semantics.

[0011] Therefore, there is an urgent need for a cloud-based collaborative enterprise internal process automation management system and method to solve the above problems. Summary of the Invention

[0012] To achieve the above objectives, the present invention provides a cloud-based collaborative method for automating enterprise internal processes, comprising the following steps:

[0013] Step 1: Deploy process event collection programs on the three endpoints that constitute the enterprise's internal process execution environment; the three endpoints include the financial system server, the human resources management system server, and the supply chain management system server; the process event collection program continuously collects process execution events that occur on the endpoints it is on. Each process execution event includes the event occurrence time, event type identifier, event initiator identifier, business object identifier associated with the event, and three data field identifiers operated by the event.

[0014] Step 2: The process event acquisition program performs local preprocessing on the acquired process execution events to form a local event stream on the endpoint. The local preprocessing includes mapping the event type identifier to a standardized activity identifier, converting the event occurrence time to Coordinated Universal Time (UTC) format, deleting the user identity identifier portion from the event initiator identifier, and performing hash desensitization processing on the business object identifier associated with the event.

[0015] Step 3: Every 3 minutes, the process event acquisition program on each end node calls the locally deployed behavior rule verification engine to perform behavior rule verification on the event record sequence in the newly added end-side local event stream; the standardized activity identifier in the event record sequence that conforms to the rule constraints after verification is replaced with a mask value, the standardized activity identifier in the event record sequence that does not conform to the rule constraints after verification retains the original value, and the processed event record sequence is uploaded to the cloud computing server as the end-side verification result data;

[0016] Step 4: The cloud computing server merges the end-side verification result data received from the three end-side nodes according to the event timestamp to form a global process event log; the cloud computing server executes a process mining algorithm on the global process event log to generate a cloud process topology model;

[0017] Step 5: The cloud computing server extracts the directed edges of the flow from the cloud process topology model and sorts them according to the flow frequency. The directed edges of the flow that are ranked first are selected and mapped to the cloud automated execution rules and distributed to the three end nodes. The cloud computing server calculates the deviation measurement value of the activities in the cloud process topology model that retain the original standardized activity identifier value.

[0018] Step 6: After receiving the cloud-based automated execution rules, each edge node performs deviation constraint verification between the cloud-based automated execution rules and the enterprise process execution behavior rule set pre-stored locally on the edge node; the activity flow relationships in the cloud-based automated execution rules that do not conflict after verification are added to the local automated execution queue of the edge node and driven for execution; the conflict information corresponding to the conflicting activity flow relationships after verification is uploaded to the cloud computing server.

[0019] Step 7: After receiving the conflict information, the cloud computing server adjusts the reliability weight parameters of the process nodes in the cloud process topology model according to the deviation metric value of the process nodes corresponding to the conflict information, and corrects the process mining results according to the adjusted reliability weight parameters of the process nodes in the next round of process mining.

[0020] Step 8: Repeat steps 3 through 7.

[0021] Preferably, the specific process of the process event acquisition program in step 2 performing local preprocessing on the acquired process execution events is as follows:

[0022] The process event acquisition program reads the event type identifier from the process execution event and maps the event type identifier to the corresponding standardized activity identifier according to the standardized activity identifier mapping table pre-stored locally on the end node. The standardized activity identifier mapping table contains mapping relationships for 87 types of internal business activities of an enterprise, and each type of internal business activity of an enterprise corresponds to one standardized activity identifier.

[0023] The process event acquisition program reads the event occurrence time from the process execution event and converts the event occurrence time from the local time zone of the end node to Coordinated Universal Time (UTC) format;

[0024] The process event acquisition program reads the event initiator identifier in the process execution event, identifies the position of the connector between the user identity identifier and the role identifier in the event initiator identifier, extracts the role identifier after the connector as the event initiator role identifier, and deletes the user identity identifier before the connector.

[0025] The process event acquisition program reads the business object identifier associated with the process execution event, performs a hash calculation on the business object identifier associated with the event using the SHA-256 hash algorithm, and takes the first to the 16th characters of the hash calculation result string as the de-identified business object hash value;

[0026] The process event acquisition program reads the three data field identifiers operated on by the event in the process execution event, combines the three data field identifiers operated on by the event with the converted event occurrence time, the mapped standardized activity identifier, the extracted event initiator role identifier, and the desensitized business object hash value into an event record, and writes the event record into the local event stream on the end side in the order of the event occurrence time.

[0027] Preferably, the specific process of behavior rule verification by the behavior rule verification engine in step 3 is as follows:

[0028] The behavior rule verification engine internally stores a set of enterprise process execution behavior rules pre-distributed to the edge nodes by the cloud computing server. The set of enterprise process execution behavior rules contains 37 behavior rules, each of which consists of a preceding activity condition, a current activity condition, and a timing constraint condition. The preceding activity condition is used to limit the value range of the standardized activity identifier corresponding to the event record that appears before the event record being verified in the process execution event sequence. The current activity condition is used to limit the value range of the standardized activity identifier corresponding to the event record being verified. The timing constraint condition is used to limit the time difference threshold between the occurrence time of the preceding activity condition and the occurrence time of the current activity condition.

[0029] The behavior rule verification engine extracts all new event records added since the last cloud upload operation from the local event stream on the client side, and arranges them in chronological order of event timestamps to form an event record sequence. The behavior rule verification engine reads each event record in the event record sequence in turn, takes the event record as the current event record to be verified, and checks whether the standardized activity identifiers of all event records preceding the current event record in the event record sequence, as well as the standardized activity identifier of the current event record to be verified, simultaneously satisfy a matching relationship with any behavior rule in the enterprise process execution behavior rule set. The simultaneous satisfaction of the matching relationship means that: at least one event record in the actual preceding activity sequence has a standardized activity identifier that is within the value range limited by the preceding activity condition of the behavior rule; the standardized activity identifier of the current event record to be verified is within the value range limited by the current activity condition of the same behavior rule; and the time difference between the event timestamp of the last event record in the actual preceding activity sequence that satisfies the preceding activity condition and the event timestamp of the current event record to be verified is less than or equal to the time difference threshold limited by the timing constraint condition of the same behavior rule.

[0030] If at least one event record in the event record sequence is determined to simultaneously satisfy a matching relationship with any behavior rule in the behavior rule set, then the event record sequence is determined to comply with the client-side rule constraints, and the behavior rule verification engine marks the event record sequence as a compliant sequence; if all event records in the event record sequence do not simultaneously satisfy a matching relationship with any behavior rule in the behavior rule set, then the event record sequence is determined to not comply with the client-side rule constraints, and the behavior rule verification engine marks the event record sequence as an abnormal sequence.

[0031] Preferably, the specific process of replacing the standardized activity identifier in the event record sequence that conforms to the rule constraints after verification with the mask value in step 3 is as follows:

[0032] The behavior rule verification engine reads each event record in the event record sequence marked as a compliance sequence and replaces the field value of the standardized activity identifier field in each event record with a pre-set fixed mask string; the fixed mask string is a string with a length of 8 characters, and the fixed mask string does not carry any semantic differentiation information of the enterprise's internal business activity type to the cloud computing server;

[0033] The behavior rule verification engine reads each event record in the event record sequence marked as an abnormal sequence, and keeps the value of the standardized activity identifier field in each event record as the original value of the standardized activity identifier before replacement, without performing mask string replacement operation;

[0034] The behavior rule verification engine merges the event records in the compliant sequence after the mask string replacement operation and the event records in the abnormal sequence without the mask string replacement operation to form the end-side verification result data; the process event collection program uploads the end-side verification result data to the cloud computing server in structured data format through a secure transmission channel based on the transport layer security protocol.

[0035] Preferably, the specific process of the cloud computing server generating the cloud process topology model in step 4 is as follows:

[0036] The cloud computing server receives the endpoint verification result data uploaded by the financial system server, human resource management system server, and supply chain management system server, parses the event records in each endpoint verification result data, and extracts the event timestamp field value, standardized activity identifier field value, and business object hash value field value of each event record; the cloud computing server merges and sorts all event records of the three endpoint nodes in ascending order of event timestamp field value to form a global process event log;

[0037] The cloud computing server executes a fuzzy mining-based process discovery algorithm on the global process event log. The fuzzy mining-based process discovery algorithm sequentially scans the event record sequence arranged in chronological order in the global process event log, uses the business object hash value field value as the unique identifier of the process instance, and groups the event records belonging to the same process instance. In each group of event records belonging to the same process instance, for two event records that are adjacent in time, the standardized activity identifier field value of the previous event record is used as the source node, and the standardized activity identifier field value of the next event record is used as the target node, recording a directed flow relationship from the source node to the target node.

[0038] The process discovery algorithm based on fuzzy mining traverses all directed flow relationships in all process instances, counts the total number of occurrences of each directed flow relationship in all process instances, and uses the total number of occurrences as the flow frequency of that directed flow relationship; for each directed flow relationship, it calculates the arithmetic mean of the time difference between the occurrence time of the source node and the occurrence time of the target node in all process instances, and uses the arithmetic mean of the time difference as the average flow time of that directed flow relationship.

[0039] The process discovery algorithm based on fuzzy mining takes the set of all source nodes and target nodes as the process node set and the set of all directed flow relationships as the process directed edge set. The process node set and the process directed edge set together constitute the cloud process topology model. Each process directed edge in the cloud process topology model contains a flow frequency attribute value and an average flow time attribute value.

[0040] Preferably, the process in step 5 where the cloud computing server extracts the directed edges of the flow from the cloud process topology model and sorts them by flow frequency is as follows:

[0041] The cloud computing server traverses the set of directed edges in the cloud process topology model, extracts the flow frequency attribute value of each directed edge, and constructs a flow frequency array consisting of the directed edge identifier and the flow frequency attribute value. The cloud computing server uses a quicksort algorithm to sort the flow frequency attribute values ​​in the flow frequency array in descending order of value. After sorting, it selects the directed edge identifiers corresponding to the 17 directed edges in the flow frequency array that are at the 1st to 17th positions in the sorting position.

[0042] Based on the 17 selected directed edge identifiers, the cloud computing server obtains the standardized activity identifiers corresponding to the source node and the target node of each directed edge from the cloud process topology model. It then forms an activity flow relationship by combining the standardized activity identifiers corresponding to the source node and the target node, and uses the set of 17 activity flow relationships as the cloud automated execution rules.

[0043] The cloud computing server encapsulates the cloud-based automated execution rules into cloud-based data packets, and sends these data packets simultaneously to the financial system server, human resource management system server, and supply chain management system server through a secure transmission channel.

[0044] Preferably, the process by which the cloud computing server calculates the deviation metric value of the activity in the cloud process topology model that retains the original standardized activity identifier value in step 5 is as follows:

[0045] In the global process event log formed in step 4, the cloud computing server locates all event records that were marked as abnormal sequences in step 3 and did not undergo mask string replacement, and extracts the original value of the standardized activity identifier from the event records; the cloud computing server uses the extracted original value of the standardized activity identifier as an index to search for the process node corresponding to the original value of the standardized activity identifier in the process node set of the cloud process topology model;

[0046] The cloud computing server calculates the deviation metric of the found process node. The deviation metric is calculated as follows: the flow frequency attribute values ​​of all preceding directed edges pointing to the process node in the cloud process topology model are summed to obtain the sum of preceding flow frequencies; the flow frequency attribute values ​​of all succeeding directed edges emanating from the process node in the cloud process topology model are summed to obtain the sum of succeeding flow frequencies; the absolute value of the difference between the sum of preceding flow frequencies and the sum of succeeding flow frequencies is calculated, and the absolute value of the difference is used as the deviation metric of the process node.

[0047] Preferably, the specific process of the endpoint node performing deviation constraint verification between the cloud-based automated execution rules and the enterprise process execution behavior rule set pre-stored locally on the endpoint node in step 6 is as follows:

[0048] The edge node parses the received data packets sent from the cloud and extracts 17 activity flow relationships contained in the data packets sent from the cloud; the edge node reads the enterprise process execution behavior rule set stored locally, and each behavior rule in the enterprise process execution behavior rule set is pre-configured with a flow relationship mark field that is not allowed to be executed;

[0049] The endpoint node sequentially traverses each of the 17 activity flow relationships and performs a conflict check on each one. The conflict check is performed as follows: the endpoint node checks whether the flow relationship pair consisting of the standardized activity identifier corresponding to the source node and the standardized activity identifier corresponding to the target node is the same as the flow relationship pair defined by the disallowed flow relationship flag field of any behavior rule in the locally stored enterprise process execution behavior rule set. If the flow relationship pairs are the same, a conflict is determined to exist; if the flow relationship pairs are different, no conflict is determined to exist.

[0050] For activity flow relationships that are determined to have no conflicts, the endpoint adds the activity flow relationship to the tail of the local automated execution queue. The local automated execution queue adopts a first-in, first-out (FIFO) queue structure with a queue scheduling cycle of 30 seconds. When each queue scheduling cycle arrives, the endpoint retrieves the activity flow relationships sequentially from the head of the local automated execution queue and checks the actual completion status of the business activity represented by the standardized activity identifier corresponding to the source node in the activity flow relationship in the business system running on the endpoint. If the actual completion status is "completed," the endpoint sends an execution instruction to the business system for the business activity represented by the standardized activity identifier corresponding to the target node. If the actual completion status is "incomplete," the endpoint puts the activity flow relationship back to the tail of the local automated execution queue.

[0051] For any conflicting activity flow relationships, the endpoint node uploads the conflict information corresponding to the activity flow relationship to the cloud computing server through a secure transmission channel. The conflict information includes the standardized activity identifier corresponding to the source node of the activity flow relationship, the standardized activity identifier corresponding to the target node of the activity flow relationship, and the endpoint node identifier.

[0052] Preferably, the specific process of adjusting the reliability weight parameters of the process nodes by the cloud computing server in step 7 is as follows:

[0053] In the cloud computing server, a process node reliability weight parameter is maintained for each process node in the cloud process topology model. The initial value of all process node reliability weight parameters is 1.0.

[0054] After receiving the conflict information uploaded by the end node, the cloud computing server parses the standardized activity identifier corresponding to the source node in the conflict information, locates the process node corresponding to the standardized activity identifier of the source node in the cloud process topology model, and multiplies the process node reliability weight parameter of the located process node by the attenuation coefficient 0.95 to obtain the attenuated reliability weight parameter.

[0055] The cloud computing server performs maximum and minimum normalization on the deviation metric value of the process node calculated in step 5, so that the normalized deviation metric value is between 0 and 1; the cloud computing server multiplies the normalized deviation metric value by a penalty coefficient of 0.05 to obtain the penalty weight value; the cloud computing server adds the attenuated reliability weight parameter to the penalty weight value to obtain the adjusted process node reliability weight parameter.

[0056] During the next round of process mining, when the cloud computing server executes the process discovery algorithm based on fuzzy mining, it uses the reliability weight parameter of the process node corresponding to the source node of the process directed edge as a weighting factor for the flow frequency count when counting the flow frequency attribute value of each process directed edge. This results in a corresponding decrease in the flow frequency attribute value of the flow relationship involved by process nodes with lower reliability weight parameters in the cloud process topology model.

[0057] Accordingly, this invention also provides a cloud-based collaborative enterprise internal process automation management system, which applies a cloud-based collaborative enterprise internal process automation management method as described in any one of the embodiments of this invention. The cloud-based collaborative enterprise internal process automation management system includes a cloud computing server, a financial system server, a human resource management system server, and a supply chain management system server.

[0058] The financial system server, human resource management system server, and supply chain management system server are all equipped with process event collection programs and locally deployed behavior rule verification engines. The financial system server, human resource management system server, and supply chain management system server all store a set of enterprise process execution behavior rules containing 37 behavior rules pre-issued by the cloud computing server, as well as a pre-stored standardized activity identifier mapping table.

[0059] The process event acquisition program is used to collect process execution events that occur on the local end node. The collected process execution events are preprocessed locally to form an end-side local event stream. Every 3 minutes, the locally deployed behavior rule verification engine is called to perform behavior rule verification on the event record sequence in the newly added end-side local event stream. The standardized activity identifier in the event record sequence that meets the rule constraints after verification is replaced with a mask value. The standardized activity identifier in the event record sequence that does not meet the rule constraints after verification retains the original value. The processed event record sequence is uploaded to the cloud computing server as the end-side verification result data.

[0060] The cloud computing server is used to receive end-side verification result data from the financial system server, human resource management system server, and supply chain management system server. It merges the end-side verification result data according to the event timestamp to form a global process event log. It executes a process discovery algorithm based on fuzzy mining on the global process event log to generate a cloud process topology model. It extracts the flow directed edges from the cloud process topology model and sorts them according to the flow frequency. Then, it selects the top 17 flow directed edges to map as cloud automated execution rules and sends them to the financial system server, human resource management system server, and supply chain management system server. It calculates the deviation measurement value for activities in the cloud process topology model that retain the original standardized activity identifier value.

[0061] Each end-side node in the financial system server, human resource management system server, and supply chain management system server is also used to perform deviation constraint verification between the cloud-based automated execution rules and the locally pre-stored enterprise process execution behavior rule set after receiving the cloud-based automated execution rules. The activity flow relationship in the cloud-based automated execution rules that do not conflict after verification is added to the local automated execution queue and drives the business system running on the end-side node to execute. The conflict information corresponding to the activity flow relationship that conflicts after verification is uploaded to the cloud computing server.

[0062] The cloud computing server is also used to receive conflict information, adjust the reliability weight parameters of the process nodes in the cloud process topology model according to the deviation metric value of the process nodes corresponding to the conflict information, and correct the mining results of the process discovery algorithm based on fuzzy mining in the next round of process mining according to the adjusted reliability weight parameters of the process nodes.

[0063] The beneficial effects of this invention are:

[0064] 1. This invention employs a dual verification mechanism consisting of edge-side behavior rule verification and edge-side deviation constraint verification. Before the automated execution rules issued from the cloud drive the edge-side business system to execute, the edge-side nodes verify the feasibility of the rules based on the locally stored enterprise process execution behavior rule set. Only activity flow relationships that do not conflict with local behavior rules are executed. This effectively solves the mismatch problem between cloud process mining results and actual edge execution capabilities caused by interface limitations, permission configurations, or data format differences, and significantly reduces the deviation rate of automated execution.

[0065] 2. This invention removes the user identity identifier from the process execution event locally on the end node, performs hash-based desensitization on the business object identifier, and replaces the standardized activity identifier of the event record that conforms to the end-side behavior rules with a fixed mask string without business semantics before uploading to the cloud. This allows the cloud computing server to only obtain the original activity identifier of abnormal behavior for process deviation analysis, while sensitive activity information of normal business processes does not leave the end node. This significantly reduces the amount of sensitive data transmitted to the cloud while ensuring the integrity of the data required for global process mining in the cloud.

[0066] 3. This invention dynamically adjusts the reliability weight parameters of corresponding process nodes in the cloud process topology model based on the conflict information and deviation metrics of abnormal activities uploaded by the end-side nodes through a cloud computing server. In the next round of process mining, this parameter is used as a weighting factor for flow frequency statistics to correct the process mining results. This constructs a closed-loop adaptive optimization mechanism from end-side execution feedback to cloud model correction, enabling the cloud process model to continuously iterate and approximate the real and feasible business process form according to the actual execution constraints of the end-side, overcoming the defect of unidirectional information flow between process mining and process execution in existing methods. Attached Figure Description

[0067] To more clearly illustrate the technical solutions in this invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0068] Figure 1 This is a schematic diagram of the system architecture of the present invention;

[0069] Figure 2 This is a schematic diagram of the main process steps of the method of the present invention. Detailed Implementation

[0070] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. It should also be noted that, to make the embodiments more comprehensive, the following embodiments are the best and preferred embodiments, and those skilled in the art can use other alternative methods to implement some well-known technologies; moreover, the accompanying drawings are only for more specific description of the embodiments and are not intended to specifically limit the present invention.

[0071] Please see Figures 1-2 This invention provides a cloud-based collaborative method for automating enterprise internal processes. This method achieves automated mining, verification, execution, and continuous optimization of cross-system business processes within the enterprise through collaborative interaction between a cloud computing server and end-side nodes deployed on servers of different business systems within the enterprise.

[0072] The three endpoints constituting the enterprise's internal process execution environment are the financial system server, the human resources management system server, and the supply chain management system server. These three endpoints correspond to the enterprise's three core business areas: finance, human resources, and supply chain. Typical business processes require traversing at least two of these endpoints to complete their entire lifecycle. The cloud computing server is deployed in a dedicated data center or cloud computing infrastructure and communicates with the three endpoints via a secure transmission channel.

[0073] Step 1: Deploy the process event collection program and collect process execution events.

[0074] The process event acquisition program is deployed in the operating system environments of the financial system server, human resource management system server, and supply chain management system server. The process event acquisition program is a software component running as a background service, whose function is to capture operational events related to business process execution occurring on its respective endpoint in real time. The process event acquisition program continuously collects process execution events, including calling the application programming interfaces provided by the business system running on its endpoint and monitoring the transaction logs of the business system database. The collection process does not block the normal operation of the business system.

[0075] Each collected process execution event contains the following 5 types of event attribute data:

[0076] The event occurrence time records the precise moment the process execution event occurred, with a precision of seconds. The event type identifier identifies the event's type code within the source business system, such as the internal event code for creating a payment application in a financial system. The event initiator identifier identifies the user account information that triggered the process execution event, formatted as "User Identifier - Role Identifier," separated by a hyphen. The event-associated business object identifier uniquely identifies the core business object operated on by the process execution event, such as the payment application number, employee ID, or purchase order number. The three data field identifiers operated on by the event record the names of the database table fields whose values ​​or states changed during the process execution; these three data field identifiers reflect the core data impact scope of the event.

[0077] The process event acquisition programs deployed on the three endpoint nodes run independently, without establishing direct communication connections with each other. This design meets the security management requirements for network isolation between different business systems within an enterprise.

[0078] Step 2: Perform local preprocessing on the process execution events to form a local event stream on the endpoint.

[0079] After collecting process execution events, the process event acquisition program performs preprocessing of event attribute data locally on the endpoint node before transmitting the process execution event data externally. The purpose of local preprocessing is twofold: first, to unify the heterogeneous event description methods on different endpoint nodes into standardized semantic expressions; and second, to anonymize sensitive information, reducing the risk of privacy leakage after the data leaves the endpoint node.

[0080] The specific process of local preprocessing is as follows.

[0081] First, the process event acquisition program reads the event type identifier from the process execution events and maps it to the corresponding standardized activity identifier based on a standardized activity identifier mapping table pre-stored locally on the endpoint nodes. This standardized activity identifier mapping table contains mapping relationships for 87 types of business activities within the enterprise, with each type corresponding to one standardized activity identifier. For example, the internal code "FIN_AP_CREATE" in the financial system is mapped to the standardized activity identifier "CREATE_PAYMENT_APPLICATION". This standardized activity identifier mapping table is configured by the enterprise process administrator during the system deployment phase. Its purpose is to provide a unified, cross-system activity semantic namespace for event types across different business systems, which is one of the fundamental conditions for subsequent cross-system process mining by the cloud computing server.

[0082] Secondly, the process event acquisition program reads the event occurrence time from the process execution events, detects the time zone setting of the operating system of the local endpoint, and converts the event occurrence time from the local time zone of the endpoint to Coordinated Universal Time (UTC). This operation ensures that event records from endpoints in different geographical regions can be time-series merged on a unified time base.

[0083] Next, the process event acquisition program reads the event initiator identifier from the process execution event and identifies the position of the hyphen connector between the user identity identifier and the role identifier in the event initiator identifier. The process event acquisition program extracts the role identifier portion after the connector as the event initiator's role identifier and deletes the user identity identifier portion before the connector. After this operation, the account name information reflecting the personal identity of the event executor is removed, and only the role information reflecting the executor's organizational function is retained.

[0084] Then, the process event acquisition program reads the business object identifier associated with the event in the process execution event and performs a hash calculation on the business object identifier associated with the event using the SHA-256 hash algorithm. The SHA-256 hash algorithm is a widely used cryptographically secure hash algorithm in existing technology, capable of mapping input data of arbitrary length to a fixed-length 256-bit hash value. The process event acquisition program represents the hash calculation result as a 64-bit hexadecimal string and takes the first to 16th characters of this hexadecimal string as the de-identified business object hash value. After this hash de-identification processing, the cloud computing server can still distinguish different process instances to trace the process path through the business object hash value, but it cannot deduce the original business object identifier from the business object hash value.

[0085] Finally, the process event acquisition program reads the three data field identifiers operated on by the events in the process execution events. The program combines the converted event occurrence time (UTC time), the mapped standardized activity identifier, the extracted event initiator role identifier, the de-identified business object hash value, and the original values ​​of the three data field identifiers operated on by the event into an event record. This event record is written to the local persistent storage of the endpoint node in chronological order of event occurrence, forming a local event stream on the endpoint.

[0086] Step 3: Perform edge behavior rule verification and upload edge verification result data.

[0087] On each endpoint, a behavior rule verification engine is deployed to work in conjunction with the process event collection program. Internally, this engine stores a set of enterprise process execution behavior rules pre-distributed to the endpoints from a cloud computing server. This set contains 37 behavior rules, each consisting of three parts: a preceding activity condition, a current activity condition, and a timing constraint. The preceding activity condition defines the range of standardized activity identifiers for events that must occur before the event record being verified; the current activity condition defines the range of standardized activity identifiers for the event record itself; and the timing constraint defines the maximum allowed time difference threshold, in seconds, between the occurrence of the preceding activity and the occurrence of the current activity. These 37 behavior rules are pre-defined by the enterprise process administrator based on internal control standards and compliance requirements, reflecting the permitted process execution behavior patterns within the enterprise.

[0088] The process event acquisition program has an internal timer with a duration of 3 minutes. Every 3 minutes, the program reads all new event records added since the last upload operation to the cloud computing server from the local event stream storage on the client side, and arranges these event records in chronological order according to the event timestamp field values ​​to form an event record sequence. The process event acquisition program then submits this entire event record sequence to the behavior rule validation engine for behavior rule validation.

[0089] The behavior rule validation engine performs behavior rule validation as follows: it sequentially reads each event record in the event record sequence as the current event record to be validated. For the current event record, the behavior rule validation engine checks whether the actual preceding activity sequence, consisting of the standardized activity identifiers of all event records preceding the current event record in the event record sequence, and the standardized activity identifier of the current event record, simultaneously satisfy a matching relationship with any behavior rule in the enterprise process execution behavior rule set. The criteria for simultaneously satisfying the matching relationship are: at least one event record in the actual preceding activity sequence has a standardized activity identifier within the value range defined by the preceding activity condition of the behavior rule; the standardized activity identifier of the current event record is within the value range defined by the current activity condition of the same behavior rule; and the time difference between the event timestamp of the last event record satisfying the preceding activity condition in the actual preceding activity sequence and the event timestamp of the current event record is less than or equal to the time difference threshold defined by the timing constraint condition of the same behavior rule.

[0090] If at least one event record in the event record sequence is determined to simultaneously satisfy a matching relationship with any behavior rule in the behavior rule set, the behavior rule validation engine marks the event record sequence as a compliant sequence. If none of the event records in the event record sequence simultaneously satisfy a matching relationship with any of the 37 behavior rules in the behavior rule set, the behavior rule validation engine marks the event record sequence as an abnormal sequence.

[0091] The behavior rule validation engine performs differentiated masking processing on compliant and abnormal sequences. For each event record in a sequence of event records marked as compliant, the behavior rule validation engine replaces the value of the standardized activity identifier field in the event record with a pre-defined fixed mask string. The fixed mask string is an 8-character string that does not carry any semantic information distinguishing the type of internal business activity to the cloud computing server. For each event record in a sequence of event records marked as abnormal, the behavior rule validation engine retains the original value of the standardized activity identifier in the event record and does not perform mask string replacement.

[0092] The event record sequence processed as described above constitutes the endpoint verification result data. The process event acquisition program uploads the endpoint verification result data to the cloud computing server in structured data format through a secure transmission channel based on a transport layer security protocol. The role of the endpoint behavior rule verification step is to screen the event data according to locally stored compliance behavior rules before the data is uploaded to the cloud, uploading only data that conforms to the rules in the form of a meaningless mask, while retaining the original activity information of abnormal data for cloud deviation analysis. This mechanism ensures that the cloud can identify process deviations while significantly reducing the exposure of sensitive information in normal business processes.

[0093] Step 4: Merge event logs in the cloud and generate a cloud process topology model.

[0094] The cloud computing server continuously receives endpoint verification result data uploaded from the financial system server, human resource management system server, and supply chain management system server. The cloud computing server parses each received endpoint verification result data, extracting the event timestamp field value, standardized activity identifier field value, and business object hash value field value from each event record. The cloud computing server aggregates all event records from the three endpoint nodes, globally sorts and merges them according to the event timestamp field value in ascending order, forming a global process event log.

[0095] The cloud computing server executes a process mining algorithm on the global process event log to generate a cloud process topology model. The process mining algorithm employs a fuzzy mining-based process discovery algorithm from existing technologies. The algorithm's execution process is as follows: Using the hash value of the business object as the unique identifier of the process instance, event records belonging to the same process instance in the global process event log are grouped together. Within each group of event records belonging to the same process instance, the event records are sorted by event timestamp. For two adjacent event records after sorting, the standardized activity identifier field value of the preceding event record is used as the source node, and the standardized activity identifier field value of the following event record is used as the target node, recording a directed flow relationship from the source node to the target node. After traversing all process instances, the total number of occurrences of each directed flow relationship in all process instances is counted, and this total number is used as the flow frequency attribute value of the directed flow relationship. Simultaneously, the arithmetic mean of the time differences between the occurrence times of the source node and the target node of the directed flow relationship in all process instances is calculated, and this arithmetic mean is used as the average flow time attribute value of the directed flow relationship.

[0096] The fuzzy data mining-based process discovery algorithm treats the set of all source and target nodes as the process node set and the set of all directed flow relationships as the process directed edge set. Each process node in the process node set corresponds to a standardized activity identifier. Each directed edge in the process directed edge set contains a flow frequency attribute value and an average flow time attribute value. The process node set and the process directed edge set together constitute a cloud-based process topology model. This cloud-based process topology model reflects the actual execution path and statistical characteristics of cross-system business processes within an enterprise within a certain time window.

[0097] Step 5: Extract the edge side of the cloud-based automated execution rules and calculate the deviation metric value of abnormal activities.

[0098] The cloud computing server traverses the set of directed edges in the cloud process topology model generated in step 4, extracts the flow frequency attribute value of each directed edge, and constructs a flow frequency array consisting of the directed edge identifier and the flow frequency attribute value. The cloud computing server uses the quicksort algorithm to sort the elements in the flow frequency array in descending order according to the numerical value of the flow frequency attribute value. The quicksort algorithm is a well-known comparison sorting algorithm in existing technology, with an average time complexity of O(nlogn).

[0099] After sorting, the cloud computing server selects the directed edge identifiers corresponding to the 17 directed edges located at positions 1 to 17 in the sorted flow frequency array. The reason for selecting 17 edges is that in actual enterprise business processes, a small number of high-frequency flow paths usually carry the majority of business traffic. The top 17 high-frequency flow edges can cover the main business scenarios. Selecting too many edges will introduce low-confidence rules, thereby increasing the probability of execution conflicts on the client side. Selecting too few edges will reduce the scope of automation coverage.

[0100] Based on the selected 17 directed edge identifiers, the cloud computing server retrieves the standardized activity identifiers corresponding to the source node and the target node of each directed edge from the cloud process topology model. It then combines these standardized activity identifiers into an activity flow relationship. The set of 17 activity flow relationships constitutes the cloud-based automated execution rule. The cloud computing server encapsulates this rule into a cloud-based data packet and simultaneously sends it to the financial system server, the human resources management system server, and the supply chain management system server via a secure transmission channel.

[0101] Simultaneously, the cloud computing server calculates deviation metrics for activities in the cloud process topology model that retain their original standardized activity identifier values. Specifically, the cloud computing server locates all event records marked as abnormal sequences in step 3 and for which mask string replacement was not performed in the global process event log generated in step 4, and extracts the original standardized activity identifier values ​​from these event records. Using the extracted original standardized activity identifier values ​​as indexes, the cloud computing server searches for the process node corresponding to that original standardized activity identifier value within the process node set of the cloud process topology model. For each identified process node, the cloud computing server calculates a deviation metric. The deviation metric is calculated as follows: The frequency attribute values ​​of all preceding directed edges pointing to the process node in the cloud process topology model are summed to obtain the total preceding flow frequency; the frequency attribute values ​​of all succeeding directed edges emanating from the process node in the cloud process topology model are summed to obtain the total succeeding flow frequency; the absolute value of the difference between the total preceding flow frequency and the total succeeding flow frequency is calculated, and this absolute value is used as the deviation metric for the process node. The deviation metric quantifies the degree of connection and balance of the process node within the overall process structure. A larger value indicates a greater frequency gap between the node's upstream and downstream activities, and a higher probability of deviation between its position in the cloud model and the actual execution on the endpoint.

[0102] Step 6: End-side deviation constraint verification and automated execution.

[0103] The financial system server, human resources management system server, and supply chain management system server each independently receive cloud-based data packets from the cloud computing server. Each endpoint parses the received cloud-based data packets and extracts 17 activity flow relationships contained within them.

[0104] Each endpoint reads the enterprise process execution behavior rule set stored locally. As mentioned earlier, each behavior rule in the enterprise process execution behavior rule set is pre-configured with a flow relationship marker field that is not allowed to be executed. This field records cross-activity flow relationship pairs that are prohibited from being directly connected within the enterprise due to compliance requirements or system technical limitations.

[0105] The endpoint node sequentially traverses each of the 17 activity flow relationships, performing a conflict check on each one. The conflict check is performed as follows: the endpoint node checks whether the flow relationship pair consisting of the standardized activity identifiers of the source node and the target node is identical to a flow relationship pair defined by the "disallowed flow relationship flag" field of any behavior rule in the locally stored enterprise process execution behavior rule set. If the flow relationship pairs are identical, a conflict is determined to exist; otherwise, no conflict is determined to exist.

[0106] For activity flow relationships that are determined to have no conflicts, the endpoint adds the activity flow relationship to the tail of the local automated execution queue. The local automated execution queue is a first-in, first-out (FIFO) queue data structure maintained in the endpoint's memory, used to temporarily store activity flow relationship tasks to be executed. The endpoint has a queue scheduling timer with a period of 30 seconds. At the end of each 30-second queue scheduling cycle, the endpoint's scheduling thread retrieves activity flow relationship task items sequentially from the head of the local automated execution queue. The scheduling thread checks the business activity represented by the standardized activity identifier corresponding to the source node in the activity flow relationship, and the actual completion status of the current business object instance in the business system running on the endpoint. The check is performed by calling the status query interface provided by the business system. If the actual completion status is "completed," the endpoint sends an execution instruction to the business system for the business activity represented by the standardized activity identifier corresponding to the target node, driving the business system to automatically complete the subsequent activity. If the actual completion status is "incomplete," the endpoint puts the activity flow relationship task item back to the tail of the local automated execution queue, waiting for the next 30-second queue scheduling cycle to check again.

[0107] For activity flow relationships that are determined to be conflicting, the endpoint node does not add the activity flow relationship to the local automated execution queue. Instead, the endpoint node uploads the conflict information corresponding to the activity flow relationship to the cloud computing server through a secure transmission channel. The conflict information includes three fields: the standardized activity identifier corresponding to the source node of the activity flow relationship, the standardized activity identifier corresponding to the target node of the activity flow relationship, and the endpoint node identifier.

[0108] The purpose of the edge-side deviation constraint verification step is to add a verification step based on the edge-side local compliance rule set before the automated execution rules issued by the cloud actually drive the edge-side business system. This ensures that the automated operation to be executed will not conflict with the permission configuration, interface restrictions or internal control requirements of the edge-side business system, thereby avoiding automated execution failure or compliance risks.

[0109] Step 7: The cloud corrects the reliability weight parameters of the process nodes based on the conflict feedback from the end side.

[0110] The cloud computing server maintains a process node reliability weight parameter for each process node in the cloud process topology model within its data storage. The initial value of all process node reliability weight parameters is set to 1.0. The process node reliability weight parameter characterizes the degree of trustworthiness with which the activity represented by that process node is accepted and executed in the actual business environment on the edge.

[0111] When the cloud computing server receives conflict information from the endpoint nodes, it parses the standardized activity identifier corresponding to the source node in the conflict information and locates the process node corresponding to that standardized activity identifier in the cloud process topology model. The cloud computing server multiplies the process node reliability weight parameter of the located process node by a decay coefficient of 0.95 to obtain the decayed reliability weight parameter. Multiplying by the decay coefficient represents the normal decay processing of node reliability due to the conflict feedback from the endpoint execution.

[0112] The cloud computing server retrieves the deviation metric value calculated and persistently stored for this process node in step 5 from the data storage. The cloud computing server performs max-min normalization on the deviation metric value, ensuring that the normalized deviation metric value ranges between 0 and 1. The normalization process involves comparing the deviation metric values ​​of all process nodes for which deviation metric values ​​have been calculated, determining the minimum and maximum values, and then mapping each deviation metric value to the 0-1 interval using a normalization formula. The cloud computing server multiplies the normalized deviation metric value by a penalty coefficient of 0.05 to obtain the penalty weight value. The penalty coefficient of 0.05 controls the magnitude of a single correction to the node reliability parameter by the deviation metric.

[0113] The cloud computing server adds the decayed reliability weight parameter to the penalty weight value to obtain the adjusted process node reliability weight parameter, and then uses the adjusted process node reliability weight parameter to update the corresponding record of the process node in the data storage.

[0114] When the next process mining cycle begins, the cloud computing server corrects the flow frequency statistics step during the fuzzy mining-based process discovery algorithm execution in step 4. The correction method is as follows: when calculating the flow frequency attribute value of each directed edge in a process, the reliability weight parameter of the process node corresponding to the source node of that directed edge is used as a weighting factor for the flow frequency count. That is, the contribution of a directed flow relationship record to the flow frequency attribute is no longer 1, but 1 multiplied by the reliability weight parameter of the source node. This mechanism ensures that flow relationships associated with process nodes that frequently cause conflicts on the end-side and have low reliability weight parameters will have their flow frequency attribute value reduced in the subsequently generated cloud process topology model. This reduction in the flow frequency attribute value may cause the flow relationship to drop in the flow frequency ranking in step 5, thus being excluded in the next cloud-based automated execution rule extraction, achieving adaptive optimization of the cloud process model to end-side execution feedback.

[0115] Step 8: Closed-loop iterative execution.

[0116] The system continuously repeats steps 3 through 7 during operation. Each cycle includes four core components: edge data collection, verification, and uploading; cloud-based process model generation and rule distribution; edge deviation constraint verification and execution; and cloud-based weight parameter correction. The inputs and outputs of each component are tightly coupled, with the output of the preceding step serving as the input for the subsequent step. Through multiple iterations, the process knowledge reflected in the cloud-based process topology model gradually approximates the actual executable business process on the edge, conforming to enterprise specifications and constraints. The accuracy of the cloud-based automated execution rules and the success rate of edge execution continuously improve with the number of iterations.

[0117] The method described in this specific embodiment achieves bidirectional information flow and closed-loop optimization between cloud analysis and edge execution by performing local preprocessing and behavioral rule verification at the edge node, performing global process mining and automated rule generation in the cloud, and feeding back conflict information to the cloud for model correction after performing deviation constraint verification on the edge. The dual verification mechanism composed of edge behavioral rule verification and deviation constraint verification effectively solves the mismatch problem between cloud process mining results and actual edge execution capabilities in existing technologies. The edge-side local deletion of user identity identifiers, hash desensitization of business object identifiers, and mask replacement of compliance activity identifiers significantly reduce the privacy leakage risk caused by sensitive data outbound transmission and centralized storage while meeting the needs of cloud-based global analysis. The mechanism by which the cloud corrects the reliability weight parameters of process nodes based on edge conflict feedback empowers the system with the ability to continuously learn and autonomously optimize from operational feedback.

[0118] Example

[0119] This specific implementation provides a cloud-based collaborative enterprise internal process automation management method. This method is applied to an enterprise internal process execution environment consisting of multiple business systems. Through the collaborative interaction between the cloud computing server and the end-side nodes, it realizes the automated mining, verification, execution and optimization of cross-system business processes.

[0120] This embodiment is applied within a medium-sized manufacturing enterprise, which has three core business systems deployed: a financial system, a human resources management system, and a supply chain management system. These three systems run on independent servers, forming three endpoints of the enterprise's internal process execution environment: the financial system server, the human resources management system server, and the supply chain management system server. The enterprise's routine business processes, such as procurement and payment processes, employee onboarding processes, and production material requisition processes, all require traversing at least two of these three systems to complete. This embodiment aims to automate the execution of high-confidence process steps through cloud-based collaborative analysis of these cross-system process events, while simultaneously protecting sensitive endpoint data and eliminating discrepancies between cloud-based data mining results and endpoint execution capabilities.

[0121] Step 1: Deploy the process event collection program and continuously collect process execution events.

[0122] First, a process event acquisition program is deployed in the operating system environments of the financial system server, the human resources management system server, and the supply chain management system server. This process event acquisition program is an independently running background process that continuously collects process execution events occurring on the server in real time by calling the application programming interfaces exposed by the business system on the server or by listening to the database change logs of the business system.

[0123] Each collected process execution event contains the following 5 types of event attribute data:

[0124] 1. Event occurrence time: Record the precise time when the process execution event occurred, in the format of "year-month-day hour:minute:second".

[0125] 2. Event Type Identifier: Records the event type code defined internally by the business system. For example, the internal code corresponding to the "Create Payment Application Form" event in the financial system is "FIN_AP_CREATE".

[0126] 3. Event Initiator Identifier: Records the user information that triggered the event, in the format of "User Identifier-Role Identifier", such as "zhang.san-FIN_ACCOUNTANT", where "zhang.san" is the user identification part and "FIN_ACCOUNTANT" is the role identification part, and the two parts are separated by a hyphen "-".

[0127] 4. Business object identifier associated with the event: A unique identifier of the core business object operated by the process execution event, such as payment application number "AP202410230001", employee number "EMP00842" or purchase order number "PO202410210035".

[0128] 5. Three data fields identified by the event: These are the names of the database table fields whose data changes occurred during the execution of the event. For example, the payment application event operated on the three fields "ap_amount", "ap_vendor_id", and "ap_status".

[0129] The process event acquisition program continuously executes the above acquisition operations to ensure that all process execution events occurring on the end-side nodes are captured in real time, and that the acquisition programs on different end-side nodes run independently and do not communicate with each other, in order to meet the enterprise's security requirements for the isolation of various business systems.

[0130] Step 2: Perform local preprocessing on process execution events to form an edge-side local event stream.

[0131] After collecting the original process execution events, the process event acquisition program immediately performs local preprocessing on the attribute data of each process execution event. The specific preprocessing process is as follows.

[0132] First, the process event acquisition program reads the event type identifier from the process execution events. Internally, the program maintains a standardized activity identifier mapping table pre-stored locally on the endpoint nodes. This table defines the mapping relationships for 87 business activity types within the enterprise. For example, the event type identifier "FIN_AP_CREATE" in the financial system is mapped to the standardized activity identifier "CREATE_PAYMENT_APPLICATION"; the event type identifier "HR_ONBOARD_INIT" in the human resources system is mapped to the standardized activity identifier "INITIATE_EMPLOYEE_ONBOARDING"; and the event type identifier "SCM_INV_UPDATE" in the supply chain system is mapped to the standardized activity identifier "UPDATE_INVENTORY_QUANTITY". These 87 standardized activity identifiers constitute a unified activity semantic space spanning the three business systems, used to mask the differences in event naming methods between different business systems during subsequent cloud analysis.

[0133] Secondly, the process event acquisition program reads the event occurrence time from the process execution events and detects the local system time zone setting of the endpoint, converting the event occurrence time from the endpoint's local time zone to Coordinated Universal Time (UTC) format. For example, an event with a local time of "2024-10-23 14:35:22" in Beijing has a corresponding UTC time of "2024-10-23 06:35:22".

[0134] Next, the process event acquisition program reads the event initiator identifier from the process execution event, locates the hyphen "-" connector in the string, extracts the role identifier portion after the connector as the event initiator role identifier, and deletes the user identity identifier portion before the connector. For example, the event initiator identifier "zhang.san-FIN_ACCOUNTANT" is processed to retain only the role identifier "FIN_ACCOUNTANT". This operation is completed locally on the client side, ensuring that the employee's personal identity information does not leave the client node.

[0135] Then, the process event acquisition program reads the business object identifier associated with the process execution event. The program calls the local cryptographic algorithm library on the endpoint node and uses the SHA-256 hash algorithm to hash the business object identifier string associated with the event, obtaining a 256-bit hash value. The program converts this hash value into a 64-bit hexadecimal string and extracts the first 16 characters as the de-identified business object hash value. For example, the business object identifier "AP202410230001" after SHA-256 hashing has a hexadecimal string prefix of "a3f5c89d1e7b4206...", and the first 16 characters "a3f5c89d1e7b4206" are used as the business object hash value. This operation allows the cloud computing server to distinguish different business object instances through the hash value for process instance tracking, but it cannot deduce the specific business object number from the hash value.

[0136] Finally, the process event acquisition program reads the three data field identifiers operated on by the events in the process execution events, and combines the converted event occurrence time (UTC time), the mapped standardized activity identifier, the extracted event initiator role identifier, and the de-identified business object hash value, along with the original values ​​of the three data field identifiers, to form a structured local event record on the client side. This local event record on the client side contains the following fields: event timestamp, standardized activity identifier, event initiator role identifier, business object hash value, and set of data field identifiers. The process event acquisition program continuously appends such event records to the local file storage or lightweight embedded database of the client-side node according to the order of event timestamps, forming a local event stream on the client side.

[0137] Step 3: Perform edge-side behavior rule validation and upload edge-side validation result data.

[0138] Each endpoint node is equipped with a behavior rule validation engine. This engine stores a set of enterprise process execution behavior rules, pre-distributed to each endpoint node by the cloud computing server during system initialization. This set contains 37 behavior rules. Each rule consists of three parts: preceding activity conditions, current activity conditions, and timing constraints. The preceding activity conditions define the range of standardized activity identifiers corresponding to event records that must have occurred before the event record being validated. The current activity conditions define the range of standardized activity identifiers corresponding to the event record being validated itself. The timing constraints define the maximum allowed time interval, in seconds, between the occurrence of the preceding activity and the occurrence of the current activity.

[0139] Let's take Rule 12 as an example. This rule governs approval actions in the payment process. The prerequisite activity condition is limited to the standardized activity identifier "CREATE_PAYMENT_APPLICATION", the current activity condition is limited to the standardized activity identifier "APPROVE_PAYMENT_APPLICATION", and the timing constraint is a time difference threshold of less than or equal to 7200 seconds. This rule means that a payment approval activity must occur within 7200 seconds of the payment request creation activity; otherwise, it will be considered abnormal behavior.

[0140] The process event acquisition program has an internal 3-minute timer. Whenever the timer is triggered, the process event acquisition program reads all new event records added since the last cloud upload operation from the local event stream storage on the client side, and arranges these event records in chronological order according to their event timestamps to form an event record sequence.

[0141] The process event acquisition program transmits the entire event record sequence to the behavior rule validation engine. The behavior rule validation engine sequentially reads each event record in the event record sequence as the currently validated event record. For the currently validated event record, the behavior rule validation engine traces back through the event record sequence to all event records preceding it, forming the actual preceding activity sequence. The behavior rule validation engine compares the standardized activity identifier of each event record in the actual preceding activity sequence with the preceding activity conditions of each of the 37 behavior rules, and simultaneously compares the standardized activity identifier of the currently validated event record with the current activity conditions of the same rule. If at least one event record in the actual preceding activity sequence has a standardized activity identifier falling within the range defined by the preceding activity conditions of a certain behavior rule, and the standardized activity identifier of the currently validated event record also falls within the range defined by the current activity conditions of the same behavior rule, then the time difference between the event timestamp of the event record that satisfies the conditions in the actual preceding activity sequence and the event timestamp of the currently validated event record is further calculated. If the time difference is less than or equal to the time difference threshold defined by the timing constraint of the same behavior rule, then it is determined that the currently verified event record and the behavior rule simultaneously satisfy the matching relationship.

[0142] If at least one event record in the event record sequence is determined to simultaneously satisfy a matching relationship with any behavior rule, the behavior rule validation engine will mark the entire event record sequence as a compliant sequence. If none of the event records in the event record sequence simultaneously satisfy a matching relationship with any of the 37 behavior rules, the behavior rule validation engine will mark the entire event record sequence as an abnormal sequence.

[0143] Subsequently, the behavior rule validation engine performs differentiated masking processing on event record sequences marked as compliant sequences and event record sequences marked as anomalous sequences. For each event record in a compliant sequence, the behavior rule validation engine replaces the value of its standardized activity identifier field with a pre-defined fixed mask string "MASKED". This fixed mask string is 8 characters long and does not carry any semantic distinguishing information to the cloud computing server. For each event record in an anomalous sequence, the behavior rule validation engine does not replace its standardized activity identifier field, retaining its original standardized activity identifier value.

[0144] The compliant sequence event records and abnormal sequence event records, after the above processing, together constitute the edge-side verification result data. The process event acquisition program uploads the edge-side verification result data to the cloud computing server in JSON structured data format through a secure transmission channel based on the TLS 1.3 protocol. Since the activity identifiers in the compliant sequence have been replaced with meaningless mask strings, the cloud computing server can only obtain the original values ​​of the activity identifiers in the abnormal sequence for process deviation analysis. This satisfies the needs of global cloud analysis while maximizing the protection of data privacy in normal internal business processes.

[0145] Step 4: Merge event logs in the cloud and generate a cloud-based process topology model.

[0146] The cloud computing server continuously listens on a pre-defined communication port, receiving endpoint verification result data uploaded by the financial system server, human resource management system server, and supply chain management system server. The cloud computing server first parses each received endpoint verification result data, extracting the event timestamp field, standardized activity identifier field, and business object hash value field for each event record from the JSON data packet. Subsequently, the cloud computing server aggregates all event records from the three endpoint nodes, globally sorts them according to the ascending value of the event timestamp field, and merges them into a single global process event log.

[0147] The cloud computing server executes a fuzzy mining-based process discovery algorithm on the global process event logs to generate a cloud-based process topology model. The specific execution process of this algorithm is as follows:

[0148] First, the cloud computing server traverses the global process event log, using the hash value of the business object in the event record as the unique identifier of the process instance, and groups event records with the same business object hash value into the same process instance group. For example, all event records with the business object hash value "a3f5c89d1e7b4206" are considered to belong to the same procurement payment process instance.

[0149] Second, for each process instance group, the cloud computing server sorts the event records within the group according to their event timestamps. In the sorted sequence, the cloud computing server processes each pair of time-adjacent event records sequentially, using the standardized activity identifier of the preceding event record as the source node and the standardized activity identifier of the following event record as the target node, generating a directed flow relationship record from the source node to the target node. For example, in a certain process instance, if an event record with the standardized activity identifier "CREATE_PAYMENT_APPLICATION" is immediately followed by an event record with the standardized activity identifier "APPROVE_PAYMENT_APPLICATION", then a directed flow relationship from "CREATE_PAYMENT_APPLICATION" to "APPROVE_PAYMENT_APPLICATION" is recorded.

[0150] Third, after traversing all adjacent event record pairs for all process instance groups in the complete global process event log, the cloud computing server obtains a large number of directed flow relationship records. The cloud computing server then aggregates and statistically analyzes all these directed flow relationship records. For each unique directed flow relationship from the source node to the target node, the cloud computing server calculates its total occurrence count across all process instances and uses this total count as the flow frequency attribute value of the directed edge in that process. Simultaneously, the cloud computing server collects the time differences between the source node event timestamp and the target node event timestamp corresponding to this directed flow relationship in all process instances, calculates the arithmetic mean of these time differences, and uses this arithmetic mean as the average flow time attribute value of the directed edge in that process.

[0151] Fourth, the cloud computing server aggregates all different source and target nodes encountered during the statistical process into a process node set, and aggregates all statistically analyzed directed flow relationships into a process directed edge set. Each element in the process node set is a process node, corresponding to a standardized activity identifier. Each element in the process directed edge set is a process directed edge, and each process directed edge is accompanied by flow frequency and average flow time attributes. The process node set and the process directed edge set together constitute the cloud-based process topology model for this round.

[0152] Step 5: Extract the edge side from the cloud-based automated execution rules and calculate the deviation metric for abnormal activities.

[0153] The cloud computing server first traverses the set of directed edges in the cloud process topology model generated in step 4, extracts the flow frequency attribute value of each directed edge, and constructs a flow frequency array consisting of the directed edge identifier and the corresponding flow frequency attribute value. The cloud computing server uses a quicksort algorithm to sort the elements in the flow frequency array in descending order according to the numerical value of the flow frequency attribute value.

[0154] After sorting, the cloud computing server selects the directed edge identifiers corresponding to the 17 directed edges located at positions 1 to 17 of the sorted array. Based on these 17 selected directed edge identifiers, the cloud computing server obtains the standardized activity identifiers corresponding to the source node and the target node of each directed edge from the cloud process topology model. The cloud computing server combines the standardized activity identifiers of the source node and the target node into an activity flow relationship. The set of 17 activity flow relationships constitutes the cloud-based automated execution rule for this round. The selection of 17 as the threshold is based on the fact that, in daily enterprise operations, the top 17 high-frequency flow paths typically cover more than 80% of the daily business process activity volume, ensuring that the automated execution rule has high business coverage and execution value.

[0155] The cloud computing server encapsulates these 17 activity flow relationships into a cloud-deployed data packet, and simultaneously distributes the cloud-deployed data packet to the financial system server, human resource management system server, and supply chain management system server through a secure transmission channel.

[0156] Simultaneously, the cloud computing server calculates the deviation metric for abnormal activities. In the global process event log generated in step 4, the cloud computing server locates all event records where the standardized activity identifier field value is the original value that has not been replaced, i.e., not masked. These event records all originate from abnormal sequences in the end-side verification result data uploaded by each end-side node. The cloud computing server extracts the original value of the standardized activity identifier from these event records and uses this original value as an index to find the corresponding process node in the process node set of the cloud process topology model.

[0157] For each process node found, the cloud computing server calculates its deviation metric value. The formula for calculating the deviation metric value is as follows:

[0158]

[0159] Where (v) represents the current computational process node; This represents the set of all preceding directed edges pointing to process nodes (v) in the cloud process topology model; This represents the set of all subsequent directed edges originating from process node (v) in the cloud process topology model; (f(e)) represents the flow frequency attribute value of directed edge (e). This refers to the deviation metric of a process node (v), which physically quantifies the structural stability of that node within the overall process model. A larger deviation metric indicates a more unbalanced connection between the node's upstream and downstream components in the process, and a higher likelihood that its position in the cloud model will deviate from the actual execution mode on the endpoint.

[0160] Step 6: End-side deviation constraint verification and automated execution

[0161] After receiving the cloud-based data packets from the cloud computing server, the financial system server, human resources management system server, and supply chain management system server each independently execute deviation constraint verification and automated execution processes.

[0162] First, the endpoint parses the data packets received from the cloud and extracts the 17 activity flow relationships contained therein.

[0163] Next, the endpoint reads a local storage copy of the enterprise process execution behavior rule set described in step 3. In this set of enterprise process execution behavior rules, each behavior rule, in addition to containing the preceding activity conditions, current activity conditions, and timing constraints, also has a pre-configured field for marking disallowed flow relationships. This field records direct cross-activity flow relationships explicitly prohibited by internal compliance policies or system technical restrictions. For example, a behavior rule in the supply chain system marks the flow from "UPDATE_INVENTORY_QUANTITY" to "APPROVE_SUPPLIER_PAYMENT" as disallowed because the company stipulates that inventory updates and supplier payment approvals must go through the three-way matching process of finance, and cannot be directly skipped.

[0164] The endpoint node sequentially traverses each of the 17 activity flow relationships, performing a conflict check on each one. The conflict check logic is as follows: the endpoint node combines the standardized activity identifier of the source node and the standardized activity identifier of the target node into a flow relationship pair, and then compares this flow relationship pair with the disallowed flow relationship marker field of all 37 behavior rules in the local enterprise process execution behavior rule set. If the flow relationship pair is exactly the same as the flow relationship pair recorded in the disallowed flow relationship marker field of any behavior rule, a conflict is determined to exist. If no exactly the same flow relationship pair is found after traversing all 37 behavior rules, no conflict is determined to exist.

[0165] For activity flow relationships that are determined to have no conflicts, the endpoint adds the activity flow relationship as a task item to the tail of the local automated execution queue maintained in the endpoint's memory. The local automated execution queue uses a first-in, first-out (FIFO) data structure. The endpoint internally has a queue scheduling timer with a period of 30 seconds. At the end of each 30-second queue scheduling period, the endpoint's task scheduling thread sequentially retrieves one activity flow relationship task item from the head of the local automated execution queue. The scheduling thread checks the actual completion status of the business activity represented by the standardized activity identifier of the source node in the activity flow relationship within the endpoint's business system. This check is performed by calling the status query interface provided by the business system, passing in the hash value of the business object to locate the specific business object instance, and querying the completion flag of the source node activity on that business object instance. If the returned status is "Completed," the scheduling thread immediately sends an execution instruction to the business execution interface of the business system for the business activity represented by the standardized activity identifier of the target node, driving the business system to automatically execute the subsequent activity, such as automatically creating an approval task, automatically sending a notification, or automatically updating the document status. If the returned status is "incomplete", the scheduling thread will put the task item related to the activity flow back to the tail of the local automated execution queue and wait for the next 30-second queue scheduling cycle to check again.

[0166] For any conflicting activity flow relationships, the endpoint does not add the activity flow relationship to its local automated execution queue. Instead, it constructs a conflict message. The conflict message contains three fields: the standardized activity identifier of the source node, the standardized activity identifier of the target node, and the node identifier of the endpoint. The endpoint then uploads this conflict message to the cloud computing server via a secure transmission channel.

[0167] Step 7: The cloud platform adjusts the reliability weight parameters of the process nodes based on the conflict feedback from the end side.

[0168] The cloud computing server receives conflict information uploaded from various endpoint nodes. Within its maintained cloud-based process topology model, the cloud computing server sets and persistently stores a process node reliability weight parameter for each process node. This parameter characterizes the degree to which the activity represented by a process node (v) is trusted and executed in the actual business environment on the endpoint. During system initialization, all process node reliability weight parameters are... The initial values ​​of all are set to 1.0.

[0169] When the cloud computing server receives a conflict message, it parses the message content and extracts the value of the standardized activity identifier field of the source node. The cloud computing server then uses this standardized activity identifier to match the process nodes in the cloud process topology model, locating the specific process node (v) corresponding to that identifier.

[0170] Next, the cloud computing server performs a decay adjustment on the process node reliability weight parameter of process node (v). First, the current process node reliability weight parameter of process node (v) is... Multiplying by the attenuation factor of 0.95 yields the attenuated reliability weight parameter. The attenuation factor of 0.95 ensures that the influence of the corresponding node gradually weakens after a conflict feedback occurs at the edge.

[0171] Then, the cloud computing server reads the deviation metric value calculated and stored for this process node (v) in step 5 from the data storage. To integrate deviation metrics with weight adjustments, the cloud computing server performs max-min normalization on the deviation metrics of all process nodes with deviation metrics. The normalization calculation formula is as follows:

[0172]

[0173] in, This represents the minimum deviation metric value among all process nodes that have calculated deviation metric values. This represents the maximum deviation metric value among all process nodes that have calculated deviation metrics. Normalization then performs a process to normalize the deviation metric value. The value range is between 0 and 1.

[0174] The cloud computing server will normalize the deviation metric. Multiply by the penalty factor of 0.05 to calculate the penalty weight value. The penalty factor of 0.05 is used to control the magnitude of a single correction to node reliability by the deviation metric.

[0175] Finally, the cloud computing server sums the decayed reliability weight parameter with the penalty weight value to obtain the adjusted reliability weight parameter of process node (v). The calculation formula is as follows:

[0176]

[0177] Cloud computing servers use the calculated results Update the stored value of the process node reliability weight parameter for process node (v).

[0178] When the next process discovery cycle begins, i.e., when steps 3 to 7 are repeated up to step 4, the cloud computing server, during the execution of the fuzzy mining-based process discovery algorithm, will use the current process node reliability weight parameter of each process node as a weighting factor. Specifically, when counting the flow frequency of each directed edge in step 4, for a directed flow relationship record from process node (u) to process node (v), its contribution to the flow frequency is no longer a simple increment of 1, but multiplied by the process node reliability weight parameter of the source node (u). That is, the weighted frequency count of this directed transfer relationship is... This mechanism causes the flow relationships involved in process nodes that frequently cause conflicts on the edge and have low reliability weight parameters to have their flow frequency attribute value in the subsequently generated cloud process topology model reduced accordingly. They may even fall out of the top 17 in the sorting selected in step 5, thus being removed from the cloud automated execution rules, enabling the cloud model to adaptively adjust to edge execution feedback.

[0179] Step 8: Closed-loop iteration

[0180] The system continuously repeats steps 3 through 7, forming a complete closed loop from edge data collection and verification, cloud process mining and rule distribution, edge execution verification and conflict feedback, to cloud weight correction and model updates. As the system's operating cycle increases, the cloud process topology model will become increasingly closer to the actual and feasible business process execution mode on the edge, and the accuracy of the automated execution rules distributed by the cloud and the success rate of edge execution will continuously improve.

[0181] To verify the beneficial effects of this embodiment, the following comparative example was set up. The comparative example employs a conventional cloud-based one-way process discovery and automated execution method. In this example, the endpoint nodes are only responsible for collecting raw process event data; they do not perform activity identifier masking on the event data, nor do they perform local behavior rule verification on the endpoints. All raw event data is uploaded to the cloud computing server. The cloud computing server executes the same fuzzy mining-based process discovery algorithm on all raw event data, generates a process topology model, and similarly selects the top 17 activity flow relationships by frequency of flow as automated execution rules, which are then distributed to the endpoint nodes for execution. After receiving the rules, the endpoint nodes do not perform deviation constraint verification between the rules and local behavior rules; they directly attempt to call the business system interface to execute all distributed rules. In this comparative example, the cloud does not receive conflict feedback from the endpoints and does not correct the reliability weight parameters of the process nodes.

[0182] Within the same enterprise process environment, the method of this embodiment and the method of the comparative example were run separately for 30 consecutive calendar days. After the run, the following two key performance indicators were statistically analyzed:

[0183] 1. Automated execution deviation rate: refers to the percentage of all rule entries issued by the cloud that fail to execute when the end node attempts to execute automated rules issued by the cloud due to conflicts between the flow relationship required by the rule and the limitations or compliance requirements of the actual business system on the end.

[0184] 2. Sensitive Data Leakage Risk Index: Using the number of un-de-identified sensitive fields uploaded to the cloud in the comparative example as a baseline value of 100, calculate the relative percentage of the number of similar sensitive fields uploaded to the cloud in the method of this embodiment.

[0185] The comparison results are shown in the table below:

[0186] Performance indicators Comparative Example This embodiment Automated execution deviation rate 18.7% 2.1% Sensitive data breach risk index 100 6.5

[0187] As shown in the table above, the method in this embodiment, through a dual verification mechanism consisting of the end-side behavior rule verification in step 3 and the end-side deviation constraint verification in step 6, significantly reduces the automated execution deviation rate from 18.7% to 2.1%, thus significantly improving the reliability and success rate of process automation. Simultaneously, through the user identity deletion in step 2, the hash desensitization of business object identifiers, and the compliance activity mask replacement operation in step 3, the amount of sensitive data uploaded to the cloud and potentially exposed to the cloud environment is reduced by more than 93%, and the sensitive data leakage risk index is reduced to 6.5, effectively balancing the needs of data privacy protection and global process analysis. Furthermore, the cloud weight correction mechanism in step 7 enables continuous adaptive optimization of the system during operation, a closed-loop evolution capability that is not present in other implementations.

[0188] This invention encompasses any substitutions, modifications, equivalent methods, and solutions made within the spirit and scope of this invention. To provide the public with a thorough understanding of this invention, specific details are described in detail in the following preferred embodiments; however, those skilled in the art will fully understand the invention even without these details. Furthermore, to avoid unnecessary misunderstanding of the essence of this invention, well-known methods, processes, procedures, components, and circuits are not described in detail.

[0189] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A cloud-based collaborative method for automating enterprise internal processes, characterized in that: Includes the following steps: Step 1: Deploy a process event collection program on the endpoint node to continuously collect process execution events; Step 2: The process event acquisition program performs local preprocessing on the acquired process execution events to form a local event stream on the endpoint; Step 3: Each endpoint calls the locally deployed behavior rule verification engine to perform behavior rule verification on the event record sequence in the newly added endpoint local event stream; The activity identifiers in the event record sequences that conform to the rules after verification are replaced with mask values, while the activity identifiers in the event record sequences that do not conform to the rules are retained in their original values. The processed event record sequences are then uploaded to the cloud computing server as the end-side verification result data. Step 4: The cloud computing server merges the end-side verification result data received from each end-side node in chronological order to form a global process event log, and executes the process mining algorithm to generate a cloud process topology model; Step 5: The cloud computing server extracts the directed edges of the flow from the cloud process topology model and sorts them according to the flow frequency. The directed edges of the flow that are ranked first are selected and mapped to the cloud automated execution rules and sent to the end nodes. At the same time, the activity calculation deviation metric value is retained for the activity whose original activity identifier value is retained. Step 6: After receiving the automated execution rules from the cloud, each end node performs deviation constraint verification against the locally stored set of enterprise process execution behavior rules; Flow relationships that do not conflict after verification are added to the local automated execution queue and driven to execute; Conflict information corresponding to conflicting flow relationships is uploaded to the cloud computing server; Step 7: After receiving the conflict information, the cloud computing server adjusts the reliability weight parameter of the process node in the cloud process topology model according to the deviation metric value of the process node corresponding to the conflict information, and corrects the process mining results according to the adjusted weight parameter in the next round of process mining. Step 8: Repeat steps 3 through 7.

2. The enterprise internal process automation management method based on cloud collaboration according to claim 1, characterized in that, The endpoint nodes mentioned in step 1 include the financial system server, the human resources management system server, and the supply chain management system server; each process execution event includes the event occurrence time, event type identifier, event initiator identifier, business object identifier associated with the event, and three data field identifiers operated by the event; the local preprocessing mentioned in step 2 includes mapping the event type identifier to a standardized activity identifier, converting the event occurrence time to UTC format, deleting the user identity identifier portion from the event initiator identifier, and performing hash desensitization processing on the business object identifier; in step 3, a behavior rule verification is performed every 3 minutes; the enterprise process execution behavior rule set stored internally by the behavior rule verification engine contains 37 behavior rules; in step 5, the top 17 sorted directed edges are selected and mapped to cloud-based automated execution rules; the scheduling cycle of the local automated execution queue mentioned in step 6 is 30 seconds; The specific process of the process event acquisition program in step 2 performing local preprocessing on the acquired process execution events is as follows: The process event acquisition program reads the event type identifier from the process execution event and maps the event type identifier to the corresponding standardized activity identifier according to the standardized activity identifier mapping table pre-stored locally on the end node. The standardized activity identifier mapping table contains mapping relationships for 87 types of internal business activities of an enterprise, and each type of internal business activity of an enterprise corresponds to one standardized activity identifier. The process event acquisition program reads the event occurrence time from the process execution event and converts the event occurrence time from the local time zone of the end node to Coordinated Universal Time (UTC) format; The process event acquisition program reads the event initiator identifier in the process execution event, identifies the position of the connector between the user identity identifier and the role identifier in the event initiator identifier, extracts the role identifier after the connector as the event initiator role identifier, and deletes the user identity identifier before the connector. The process event acquisition program reads the business object identifier associated with the process execution event, performs a hash calculation on the business object identifier associated with the event using the SHA-256 hash algorithm, and takes the first to the 16th characters of the hash calculation result string as the de-identified business object hash value; The process event acquisition program reads the three data field identifiers operated on by the event in the process execution event, combines the three data field identifiers operated on by the event with the converted event occurrence time, the mapped standardized activity identifier, the extracted event initiator role identifier, and the desensitized business object hash value into an event record, and writes the event record into the local event stream on the end side in the order of the event occurrence time.

3. The enterprise internal process automation management method based on cloud collaboration according to claim 2, characterized in that, The specific process of behavior rule validation by the behavior rule validation engine in step 3 is as follows: The behavior rule verification engine internally stores a set of enterprise process execution behavior rules pre-distributed to the edge nodes by the cloud computing server. The set of enterprise process execution behavior rules contains 37 behavior rules, each of which consists of a preceding activity condition, a current activity condition, and a timing constraint condition. The preceding activity condition is used to limit the value range of the standardized activity identifier corresponding to the event record that appears before the event record being verified in the process execution event sequence. The current activity condition is used to limit the value range of the standardized activity identifier corresponding to the event record being verified. The timing constraint condition is used to limit the time difference threshold between the occurrence time of the preceding activity condition and the occurrence time of the current activity condition. The behavior rule verification engine extracts all new event records added since the last cloud upload operation from the local event stream on the client side, and arranges them in chronological order of event timestamps to form an event record sequence. The behavior rule verification engine reads each event record in the event record sequence in turn, takes the event record as the current event record to be verified, and checks whether the standardized activity identifiers of all event records preceding the current event record in the event record sequence, as well as the standardized activity identifier of the current event record to be verified, simultaneously satisfy a matching relationship with any behavior rule in the enterprise process execution behavior rule set. The simultaneous satisfaction of the matching relationship means that: at least one event record in the actual preceding activity sequence has a standardized activity identifier that is within the value range limited by the preceding activity condition of the behavior rule; the standardized activity identifier of the current event record to be verified is within the value range limited by the current activity condition of the same behavior rule; and the time difference between the event timestamp of the last event record in the actual preceding activity sequence that satisfies the preceding activity condition and the event timestamp of the current event record to be verified is less than or equal to the time difference threshold limited by the timing constraint condition of the same behavior rule. If at least one event record in the event record sequence is determined to simultaneously satisfy a matching relationship with any behavior rule in the behavior rule set, then the event record sequence is determined to comply with the client-side rule constraints, and the behavior rule verification engine marks the event record sequence as a compliant sequence; if all event records in the event record sequence do not simultaneously satisfy a matching relationship with any behavior rule in the behavior rule set, then the event record sequence is determined to not comply with the client-side rule constraints, and the behavior rule verification engine marks the event record sequence as an abnormal sequence.

4. The enterprise internal process automation management method based on cloud collaboration according to claim 3, characterized in that, The specific process described in step 3, which involves replacing the standardized activity identifier in the event record sequence that conforms to the rule constraints after verification, with the mask value, is as follows: The behavior rule verification engine reads each event record in the event record sequence marked as a compliance sequence and replaces the field value of the standardized activity identifier field in each event record with a pre-set fixed mask string; the fixed mask string is a string with a length of 8 characters, and the fixed mask string does not carry any semantic differentiation information of the enterprise's internal business activity type to the cloud computing server; The behavior rule verification engine reads each event record in the event record sequence marked as an abnormal sequence, and keeps the value of the standardized activity identifier field in each event record as the original value of the standardized activity identifier before replacement, without performing mask string replacement operation; The behavior rule verification engine merges the event records in the compliant sequence after the mask string replacement operation and the event records in the abnormal sequence without the mask string replacement operation to form the edge verification result data. The process event acquisition program uploads the end-side verification result data to the cloud computing server in structured data format through a secure transmission channel based on the transport layer security protocol.

5. The enterprise internal process automation management method based on cloud collaboration according to claim 4, characterized in that, The specific process of generating the cloud process topology model by the cloud computing server in step 4 is as follows: The cloud computing server receives the edge verification result data uploaded by the financial system server, human resource management system server and supply chain management system server, parses the event records in each edge verification result data, and extracts the event timestamp field value, standardized activity identifier field value and business object hash value field value of each event record; The cloud computing server merges and sorts all event records from the three endpoint nodes in ascending order of event timestamp field values ​​to form a global process event log. The cloud computing server executes a fuzzy mining-based process discovery algorithm on the global process event log. The fuzzy mining-based process discovery algorithm sequentially scans the event record sequence arranged in chronological order in the global process event log, uses the business object hash value field value as the unique identifier of the process instance, and groups the event records belonging to the same process instance. In each group of event records belonging to the same process instance, for two event records that are adjacent in time, the standardized activity identifier field value of the previous event record is used as the source node, and the standardized activity identifier field value of the next event record is used as the target node, recording a directed flow relationship from the source node to the target node. The process discovery algorithm based on fuzzy mining traverses all directed flow relationships in all process instances, counts the total number of occurrences of each directed flow relationship in all process instances, and uses the total number of occurrences as the flow frequency of that directed flow relationship; for each directed flow relationship, it calculates the arithmetic mean of the time difference between the occurrence time of the source node and the occurrence time of the target node in all process instances, and uses the arithmetic mean of the time difference as the average flow time of that directed flow relationship. The process discovery algorithm based on fuzzy mining takes the set of all source nodes and target nodes as the process node set and the set of all directed flow relationships as the process directed edge set. The process node set and the process directed edge set together constitute the cloud process topology model. Each process directed edge in the cloud process topology model contains a flow frequency attribute value and an average flow time attribute value.

6. The enterprise internal process automation management method based on cloud collaboration according to claim 5, characterized in that, The process described in step 5, where the cloud computing server extracts the directed edges of the flow from the cloud process topology model and sorts them by flow frequency, is as follows: The cloud computing server traverses the set of directed edges in the cloud process topology model, extracts the flow frequency attribute value of each directed edge, and constructs a flow frequency array consisting of the directed edge identifier and the flow frequency attribute value. The cloud computing server uses a quicksort algorithm to sort the flow frequency attribute values ​​in the flow frequency array in descending order of value. After sorting, it selects the directed edge identifiers corresponding to the 17 directed edges in the flow frequency array that are at the 1st to 17th positions in the sorting position. Based on the 17 selected directed edge identifiers, the cloud computing server obtains the standardized activity identifiers corresponding to the source node and the target node of each directed edge from the cloud process topology model. It then forms an activity flow relationship by combining the standardized activity identifiers corresponding to the source node and the target node, and uses the set of 17 activity flow relationships as the cloud automated execution rules. The cloud computing server encapsulates the cloud-based automated execution rules into cloud-based data packets, and sends these data packets simultaneously to the financial system server, human resource management system server, and supply chain management system server through a secure transmission channel.

7. The enterprise internal process automation management method based on cloud collaboration according to claim 6, characterized in that, The process described in step 5, where the cloud computing server calculates the deviation metric for activities in the cloud process topology model that retain the original standardized activity identifier values, is as follows: In the global process event log formed in step 4, the cloud computing server locates all event records that were marked as abnormal sequences in step 3 and did not undergo mask string replacement, and extracts the original value of the standardized activity identifier from the event records; the cloud computing server uses the extracted original value of the standardized activity identifier as an index to search for the process node corresponding to the original value of the standardized activity identifier in the process node set of the cloud process topology model; The cloud computing server calculates the deviation metric of the found process node. The deviation metric is calculated as follows: the flow frequency attribute values ​​of all preceding directed edges pointing to the process node in the cloud process topology model are summed to obtain the sum of preceding flow frequencies; the flow frequency attribute values ​​of all succeeding directed edges emanating from the process node in the cloud process topology model are summed to obtain the sum of succeeding flow frequencies; the absolute value of the difference between the sum of preceding flow frequencies and the sum of succeeding flow frequencies is calculated, and the absolute value of the difference is used as the deviation metric of the process node.

8. The enterprise internal process automation management method based on cloud collaboration according to claim 7, characterized in that, The specific process of verifying the deviation constraint between the cloud-based automated execution rules and the enterprise process execution behavior rule set pre-stored locally on the edge node in step 6 is as follows: The edge node parses the received data packets sent from the cloud and extracts 17 activity flow relationships contained in the data packets sent from the cloud; the edge node reads the enterprise process execution behavior rule set stored locally, and each behavior rule in the enterprise process execution behavior rule set is pre-configured with a flow relationship mark field that is not allowed to be executed; The endpoint node sequentially traverses each of the 17 activity flow relationships and performs a conflict check on each activity flow relationship. The conflict check is performed as follows: the endpoint node checks whether the flow relationship pair consisting of the standardized activity identifier corresponding to the source node and the standardized activity identifier corresponding to the target node in the activity flow relationship is the same as the flow relationship pair defined by the disallowed flow relationship marker field of any behavior rule in the locally stored enterprise process execution behavior rule set; if the flow relationship pairs are the same, a conflict is determined to exist. If the transfer relationships are different, then it is determined that there is no conflict; For activity flow relationships that are determined to have no conflicts, the end node adds the activity flow relationship to the tail of the local automated execution queue. The local automated execution queue adopts a first-in-first-out queue structure, and the queue scheduling cycle is 30 seconds. When each queue scheduling cycle arrives, the end node takes out the activity flow relationship from the head of the local automated execution queue in sequence and checks the actual completion status of the business activity represented by the standardized activity identifier corresponding to the source node in the activity flow relationship in the business system running on the end node. If the actual completion status is "completed", the edge node sends an execution instruction to the business system for the business activity represented by the standardized activity identifier corresponding to the target node; If the actual completion status is incomplete, the end node will put the activity flow relationship back to the tail of the local automated execution queue; For any conflicting activity flow relationships, the endpoint node uploads the conflict information corresponding to the activity flow relationship to the cloud computing server through a secure transmission channel. The conflict information includes the standardized activity identifier corresponding to the source node of the activity flow relationship, the standardized activity identifier corresponding to the target node of the activity flow relationship, and the endpoint node identifier.

9. The enterprise internal process automation management method based on cloud collaboration according to claim 8, characterized in that, The specific process of adjusting the reliability weight parameters of the process nodes on the cloud computing server in step 7 is as follows: In the cloud computing server, a process node reliability weight parameter is maintained for each process node in the cloud process topology model. The initial value of all process node reliability weight parameters is 1.

0. After receiving the conflict information uploaded by the end node, the cloud computing server parses the standardized activity identifier corresponding to the source node in the conflict information and locates the process node corresponding to the standardized activity identifier of the source node in the cloud process topology model. The cloud computing server multiplies the reliability weight parameter of the located process node by an attenuation coefficient of 0.95 to obtain the attenuated reliability weight parameter. The cloud computing server performs maximum and minimum normalization on the deviation metric value calculated in step 5, so that the normalized deviation metric value is between 0 and 1. The cloud computing server multiplies the normalized deviation metric by a penalty coefficient of 0.05 to obtain the penalty weight value; The cloud computing server adds the decayed reliability weight parameter to the penalty weight value to obtain the adjusted reliability weight parameter of the process node; During the next round of process mining, when the cloud computing server executes the process discovery algorithm based on fuzzy mining, it uses the reliability weight parameter of the process node corresponding to the source node of the process directed edge as a weighting factor for the flow frequency count when counting the flow frequency attribute value of each process directed edge. This results in a corresponding decrease in the flow frequency attribute value of the flow relationship involved by process nodes with lower reliability weight parameters in the cloud process topology model.

10. A cloud-based collaborative enterprise internal process automation management system, characterized in that, The application describes a cloud-based collaborative enterprise internal process automation management method as described in any one of claims 1 to 9, wherein the cloud-based collaborative enterprise internal process automation management system includes a cloud computing server, a financial system server, a human resource management system server, and a supply chain management system server. The financial system server, human resource management system server, and supply chain management system server are all equipped with process event collection programs and locally deployed behavior rule verification engines. The financial system server, human resource management system server, and supply chain management system server all store a set of enterprise process execution behavior rules containing 37 behavior rules pre-issued by the cloud computing server, as well as a pre-stored standardized activity identifier mapping table. The process event acquisition program is used to collect process execution events that occur on the local end node. The collected process execution events are preprocessed locally to form an end-side local event stream. Every 3 minutes, the locally deployed behavior rule verification engine is called to perform behavior rule verification on the event record sequence in the newly added end-side local event stream. The standardized activity identifier in the event record sequence that meets the rule constraints after verification is replaced with a mask value. The standardized activity identifier in the event record sequence that does not meet the rule constraints after verification retains the original value. The processed event record sequence is uploaded to the cloud computing server as the end-side verification result data. The cloud computing server is used to receive end-side verification result data from the financial system server, human resource management system server, and supply chain management system server. It merges the end-side verification result data according to the event timestamp to form a global process event log. It executes a process discovery algorithm based on fuzzy mining on the global process event log to generate a cloud process topology model. It extracts the flow directed edges from the cloud process topology model and sorts them according to the flow frequency. Then, it selects the top 17 flow directed edges to map as cloud automated execution rules and sends them to the financial system server, human resource management system server, and supply chain management system server. It calculates the deviation measurement value for activities in the cloud process topology model that retain the original standardized activity identifier value. Each end-side node in the financial system server, human resource management system server, and supply chain management system server is also used to perform deviation constraint verification between the cloud-based automated execution rules and the locally pre-stored enterprise process execution behavior rule set after receiving the cloud-based automated execution rules. The activity flow relationship in the cloud-based automated execution rules that do not conflict after verification is added to the local automated execution queue and drives the business system running on the end-side node to execute. The conflict information corresponding to the activity flow relationship that conflicts after verification is uploaded to the cloud computing server. The cloud computing server is also used to receive conflict information, adjust the reliability weight parameters of the process nodes in the cloud process topology model according to the deviation metric value of the process nodes corresponding to the conflict information, and correct the mining results of the process discovery algorithm based on fuzzy mining in the next round of process mining according to the adjusted reliability weight parameters of the process nodes.

Images