Index early warning processing method and device

Abstract

The application discloses a kind of index early warning processing method and equipment, it is related to business management technical field.The method comprises: determining business index according to the business data of each business module, and detecting business index according to preset early warning rule;In the case where business index meets the early warning trigger condition specified by early warning rule, generate the early warning instance of business index;Early warning instance is sent to the management account specified by early warning rule, to configure and send the task information of early warning instance to task execution module by management account, and the follow-up task of early warning instance is created according to task information by task execution module, and the follow-up task is issued to corresponding execution account.The application forms the closed-loop management and control from early warning trigger to risk disposal, solves the problem that risk disposal is easy to miss and delay in the prior art, and improves the reliability of business management.

Description

Technical Field

[0001] This application relates to the field of business management technology, and in particular to a method and device for indicator early warning processing. Background Technology

[0002] Currently, the digital transformation of the retail industry is gradually moving from basic information infrastructure construction to a higher level of intelligent operation. As the core terminal of the retail industry, retail stores encompass multiple interconnected business processes, including contract signing, customer follow-up, performance target achievement, and daily task execution. These processes are all linked; any deviation or abnormality in any one of them can trigger a chain reaction, leading to declining store performance, customer loss, and ultimately impacting the overall operational efficiency of the retail system.

[0003] In existing technologies, risk warning systems are typically used to determine warning conditions for various business data. When these conditions are met, a warning notification is generated to provide an initial warning of business risks. However, this risk warning system stops at the basic level of rule triggering and warning notification push. After the warning notification is issued, there is no systematic correlation and tracking mechanism between it and subsequent risk handling actions. A closed-loop control from warning triggering to risk handling is not formed, making it difficult to confirm that the risks corresponding to the warnings have been effectively and promptly handled. This can easily lead to omissions and delays in risk handling, affecting the reliability of business management. Summary of the Invention

[0004] This application provides an indicator early warning processing method and device to form a closed-loop control from early warning triggering to risk handling, which solves the problem of easy omission and delay in risk handling in the prior art and improves the reliability of business management.

[0005] Firstly, this application provides a method for indicator early warning processing, including: Business indicators are determined based on the business data of each business module, and the business indicators are detected according to the preset early warning rules. If the business indicator meets the warning triggering conditions specified by the warning rule, an warning instance for the business indicator is generated. The warning instance is sent to the management account specified by the warning rule, so that the management account can configure and send the task information of the warning instance to the task execution module. The task execution module creates a follow-up task for the warning instance based on the task information and sends the follow-up task to the corresponding execution account.

[0006] Secondly, this application provides an indicator early warning processing device, comprising: One or more processors; A memory that stores one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the indicator warning processing method as described in the first aspect.

[0007] In this application, by introducing task configuration for the management account and task assignment for the execution account after generating an early warning instance, a closed-loop control system is formed from early warning triggering to risk handling. This ensures that each risk issue can be detected and handled in a timely manner, improving the reliability of business control. Through the generation and issuance of follow-up tasks for early warning instances, real-time tracking and management of risk handling are achieved, effectively avoiding omissions and delays in risk handling and ensuring the stable operation of retail store businesses. Attached Figure Description

[0008] Figure 1 This is a flowchart of an indicator early warning processing method provided in an embodiment of this application; Figure 2 This is a flowchart of detecting business indicators based on early warning rules, provided in an embodiment of this application; Figure 3 This is a schematic diagram of the early warning rule processing flow provided in the embodiments of this application; Figure 4 This is a flowchart of creating an early warning rule provided in an embodiment of this application; Figure 5 This is a flowchart illustrating the generation of early warning instances provided in an embodiment of this application; Figure 6 This is a schematic diagram of the closed-loop control link for early warning triggering and task assignment provided in the embodiments of this application; Figure 7 This is a schematic diagram illustrating the process of generating and deactivating early warning instances provided in the embodiments of this application; Figure 8 This is a schematic diagram of the structure of an indicator early warning processing device provided in an embodiment of this application. Detailed Implementation

[0009] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. A process can be terminated when its operation is completed, but it may also have additional steps not included in the drawings. A process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0010] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0011] In common existing implementations, a risk warning system is typically used to determine warning conditions for various business data. When these conditions are met, a warning notification is generated, providing an initial warning of business risks. However, this risk warning system stops at the basic level of rule triggering and warning notification push. After the warning notification is issued, there is no systematic correlation and tracking mechanism between it and subsequent risk handling actions. This lack of a closed-loop control from warning triggering to risk handling makes it difficult to confirm that the risks corresponding to the warnings are effectively and promptly addressed, easily leading to omissions and delays in risk handling, affecting the reliability of business management. Furthermore, the risk warning system determines warning conditions according to a preset detection frequency. If a business risk cannot be resolved in a short time, the corresponding warning notification will be repeatedly pushed, easily causing notification fatigue for managers. Under this fatigue, managers tend to ignore all warnings, while truly important warnings requiring intervention are drowned out by ordinary warnings, resulting in missed risk handling. Additionally, warning notifications typically include a text notification that only informs managers of the time and business indicator anomalies, but does not inform them of the root cause of the anomaly. Therefore, managers need to repeatedly jump between multiple business modules to search for relevant information to locate the root cause, leading to delays in risk handling. Furthermore, the need for manual intervention to lift warnings poses a risk of arbitrary cancellation and lacks a controllable and reliable automated lifting mechanism. Finally, the retail operations system comprises multiple levels of roles, including headquarters management, regional distributors, and store managers. Headquarters management focuses on overall performance deviations, regional distributors on store process execution efficiency, and store managers on the timeliness of frontline customer service. Therefore, the focus and response pace of each level of roles differ significantly, and a single warning rule cannot match the differentiated focus and response pace of each role.

[0012] To address the aforementioned issues, this embodiment provides an indicator-based early warning processing method to form a closed-loop control from early warning triggering to risk handling, thereby improving the reliability of business management. By suppressing duplicate early warnings for risks originating from the same source and filtering them based on window and / or task handling status, an early warning escalation mechanism can be used to upgrade recurring risks to ensure that serious risks are given priority attention. This significantly reduces invalid alarms while ensuring that no serious risks are overlooked. Early warning notifications can carry a two-tiered evidence set with summaries and details, eliminating the need for managers to repeatedly query risk-related data across multiple business modules, thus improving the efficiency of managers in locating the root causes of risks and issuing risk handling tasks. Based on actual business data, the system automatically determines whether the early warning meets the conditions for cancellation, and automatically executes the early warning cancellation operation, forming a fully automated closed-loop control from early warning triggering to cancellation. This eliminates the arbitrariness caused by manual cancellation and removes interference from resolved issues remaining in the early warning list. Performance-related early warnings, process-related early warnings, and asset-related early warnings are sent to headquarters management, distributors, and store managers respectively, ensuring that the business risks involved in the early warning instance match the business responsibilities of the recipients. This achieves precise distribution of risk warnings, thereby improving the efficiency of risk warning processing.

[0013] The indicator early warning processing method provided in this embodiment can be executed by an indicator early warning processing device. This device can be implemented through software and / or hardware, and can consist of two or more physical entities, or a single physical entity. For example, the indicator early warning processing device can be a risk early warning system or a server running a risk early warning system. In the retail industry, risk early warning systems are suitable for retail digital management platforms, covering business scenarios such as chain store operation management, distributor channel management, and business target and indicator management. In addition, risk early warning systems are also suitable for traffic and conversion early warnings in online e-commerce operations, work order timeout and satisfaction warnings in after-sales service, inventory backlog and stockout warnings in supply chain management, and other operation control scenarios driven by multi-source business indicators.

[0014] The indicator warning processing device is equipped with at least one type of operating system, including but not limited to Android, Linux, and Windows. The device can install at least one application based on the operating system; this application can be a built-in application of the operating system or an application downloaded from a third-party device or server. In this embodiment, the indicator warning processing device has at least one application capable of executing indicator warning processing methods.

[0015] For ease of understanding, this embodiment uses a risk warning system as the main body of the indicator warning processing method for description.

[0016] Figure 1A flowchart of an indicator early warning processing method provided in an embodiment of this application is given. (Reference) Figure 1 The specific methods for handling early warnings for this indicator include: S110. Determine business indicators based on the business data of each business module, and detect the business indicators according to the preset early warning rules.

[0017] The business modules are components that handle various business processes, such as the contract transaction module, customer management module, target management module, and task execution module. The target management module manages whether various regions, areas, stores, and employees have achieved their business targets. It can assign corresponding task instances to each entity, and the completion status of business targets can be confirmed through the execution progress of these task instances. The task execution module manages temporarily issued urgent tasks, such as the follow-up tasks mentioned in this embodiment, and the task instances are controlled by the target management module.

[0018] Business metrics are key data items or statistics extracted from the raw business data of the business modules to measure the status of business operations, such as contract signing conversion rate, customer follow-up response timeliness, number of backlogged customers without follow-up, business target completion rate, and task execution progress.

[0019] Early warning rules are rules for determining whether there are risk issues for the corresponding business indicators. They may include early warning triggering conditions, information of the management account receiving the early warning instance, early warning instance type, risk level, etc.

[0020] For example, a business module can collect its own generated business data in real time, store the business data in a business database, and then periodically synchronize the business data in the business database to the risk warning system. Upon receiving the business data, the risk warning system cleans, integrates, and calculates the data to obtain standardized business indicators. Then, based on the warning rules corresponding to the business indicators, it performs warning detection on the business indicators to determine whether the business indicators meet the warning trigger conditions specified in the warning rules.

[0021] Alternatively, the risk warning system may execute indicator warning processing methods according to a preset warning frequency. Each time an indicator warning processing method is executed, the risk warning system retrieves newly generated business data from the business database of the business module, cleans, integrates, and calculates the business data to obtain standardized business indicators. Then, according to the warning rules corresponding to the business indicator, the system performs warning detection on the business indicator to determine whether the business indicator meets the warning trigger conditions specified by the warning rules.

[0022] In one embodiment, the risk warning system can collect business data from various business modules, including at least two of the following: a contract transaction module, a customer management module, a target management module, and a task execution module. Based on a preset standard indicator structure, the system transforms the business data to obtain corresponding business indicators. The standard indicator structure includes the indicator name, indicator value, collection timestamp, and attribution object. For example, the risk warning system establishes stable connections with at least two business modules via an API interface or a direct database connection, collects business data from the connected business modules according to a preset detection frequency, and preprocesses the business data. Then, according to the calculation rules of various business indicators, the data values ​​of the corresponding business data are processed to obtain the indicator values ​​of the corresponding business indicators. The collection time and attribution object of the business data, along with the indicator name and indicator value of the corresponding business indicator, are saved as a standard indicator structure to obtain the corresponding business indicator. Here, the attribution object refers to the subject corresponding to the business data, such as a region, area, store, or employee. For example, the risk warning system obtains all contract order data of store A for the current month from the contract transaction module, and the indicator name corresponding to the contract order data is the total amount of contract signed in the current month. The contract amount of all contract order data is added up to obtain the corresponding indicator value. The collection timestamp is the contract order time, and the object is store A.

[0023] This embodiment connects to at least two business modules through a risk warning system, uniformly collects and processes heterogeneous data from each business module, and then completes the conversion of business data into business indicators based on a standard indicator structure to generate business indicators with a unified format, which facilitates efficient early warning detection.

[0024] It should be noted that when the risk warning system is integrated with multiple business modules, it will acquire various types of business data, thereby generating various types of business indicators. These business indicators can be categorized into performance-based, process-based, and asset-based indicators according to the roles' business focus dimensions. Performance-based indicators reflect operational results, such as sales revenue, target completion rate, and profit margin. These originate from the contract transaction module and target management module, corresponding to the focus of headquarters management. Process-based indicators reflect the efficiency of operational execution, such as store task execution progress and customer follow-up rate. These originate from the task execution module and customer management module, corresponding to the focus of regional distributors. Asset-based indicators reflect the basic operational status of frontline stores, such as customer information response timeouts and unallocated customer backlogs. These mainly originate from the customer management module, corresponding to the focus of store managers. The risk warning system can perform warning detection for these three types of business indicators to generate three types of warnings. These warnings are then pushed to headquarters management, regional distributors, and store managers, respectively, with these three levels of roles responsible for the three main management lines of result monitoring, process monitoring, and asset monitoring within the operational system.

[0025] In this embodiment, after generating business indicators, the risk warning system can determine the corresponding business category, which includes performance-based, process-based, and asset-based indicators. Specifically, the management account specified in the warning rules for performance-based indicators is the headquarters management account; for process-based indicators, it is the regional management account; and for asset-based indicators, it is the store management account. The headquarters management account is used by the headquarters management team, the regional management account by regional distributors, and the store management account by store managers. The risk warning system pre-establishes a mapping relationship between business indicators and business categories, and then determines whether a business indicator is a performance-based, process-based, or asset-based indicator based on this mapping relationship. When a business indicator is a performance-based indicator, the corresponding warning instance is pushed to the headquarters management account according to the warning rules; when a business indicator is a process-based indicator, the corresponding warning instance is pushed to the regional management account; and when a business indicator is an asset-based indicator, the corresponding warning instance is pushed to the store management account, ensuring that the warning instances for each type of business indicator accurately match the focus of each level of role. This embodiment categorizes business metrics based on the business focus dimensions of roles at different levels, thereby accurately pushing early warning instances of various business metrics to the management accounts of roles with matching focus points. This achieves hierarchical control of business metrics and solves the problem that a single early warning rule cannot adapt to the differentiated needs of multiple levels. Roles at each level can focus on the early warnings of the metrics they are concerned about and carry out targeted actions, improving the timeliness and accuracy of early warning processing and ensuring the efficient operation of the system.

[0026] After converting business data into business metrics, the risk warning system can obtain the corresponding warning rules for these metrics. Based on these rules, the system can then analyze the business metrics to determine if their values ​​meet the warning trigger conditions. Optionally, if the business metrics are categorized into performance, process, and asset categories, the system can select the corresponding rule base based on the category. In other words, the risk warning system stores the warning rules for each category separately and retrieves the corresponding rule from the relevant rule base, thereby improving the efficiency of rule lookup.

[0027] The warning trigger condition in the warning rule can be either greater than the maximum value of the indicator or less than the minimum value of the indicator. The business indicator is determined to meet the warning trigger condition if its value is greater than the maximum value, or if its value is less than the minimum value.

[0028] Optionally, the same business metric may exhibit different characteristics across different units. For instance, different stores may experience varying customer traffic due to their locations, leading to different performance results. To address this, different early warning rules can be set for the same business metric across different units. These rules define a detection range, specifying the units covered by the rule. By matching the business metric's name and its associated object with the metric name and detection range in each early warning rule, the appropriate early warning rule for each business metric can be determined, and then early warning detection can be performed based on that matching rule.

[0029] In addition to setting the maximum or minimum value of an indicator, the warning trigger condition in the warning rule can also be set as a conditional expression. The conditional expression includes the indicator name, comparison operator, and indicator threshold. The comparison operator is used to compare the indicator value corresponding to the indicator name with the indicator threshold, or to calculate the total indicator value corresponding to multiple indicator names and compare it with the indicator threshold. For example, Figure 2 This is a flowchart illustrating the detection of business metrics based on early warning rules, provided in an embodiment of this application. For example... Figure 2 As shown, the steps for detecting business indicators based on early warning rules specifically include S1101-S1103: S1101. Based on the detection range and indicator name in the preset early warning rules, determine the matching business indicators corresponding to the early warning rules.

[0030] For example, the detection scope and indicator name in the early warning rule are matched with the belonging object and indicator name in each business indicator to determine at least one matching business indicator corresponding to the early warning rule.

[0031] S1102. Based on the index values ​​of the matching business indicators and the index thresholds in the conditional expression, determine whether the comparison operators in the conditional expression are true.

[0032] For example, the indicator values ​​of the matching business metrics and the indicator thresholds in the conditional expression are substituted into the comparison operator of the conditional expression to determine whether the comparison operator's size logic is true. Specifically, if the comparison operator is used to compare the value of a single business metric with the indicator threshold, then the indicator value of the business metric is directly compared with the indicator threshold to determine if the size logic is true. For example, if the indicator value of the matching business metric is 80%, the indicator threshold of the warning rule is 70%, and the comparison operator is "business metric > indicator threshold", then the size logic of the comparison operator is determined to be true. If the comparison operator is used to compare the total indicator value calculated from the values ​​of multiple business metrics with the indicator threshold, then the total indicator value of the multiple business metrics is calculated according to the calculation formula in the comparison operator, and then the total indicator value is compared with the indicator threshold to determine if the size logic is true. For example, if the matching business metrics include business metric A and business metric B, with values ​​of 80 and 85 respectively, and the indicator threshold of the warning rule is 150, and the comparison operator is "business metric A + business metric B < indicator threshold", then the size logic of the comparison operator is determined to be false.

[0033] S1103. If the comparison operator is true, then the matching business indicator is determined to meet the early warning triggering condition; otherwise, the matching business indicator is determined not to meet the early warning triggering condition.

[0034] For example, if the comparison operator's size logic is true, it indicates that the business metric has deviated from the expected normal range, indicating a risk issue that requires triggering an alert instance. Therefore, it can be determined that the matching business metric meets the alert triggering conditions of the alert rules to proceed to the subsequent risk handling process. If the comparison operator's size logic is false, it indicates that the business metric has not deviated from the expected normal range, indicating no risk issue and therefore no need to trigger an alert instance. Therefore, it can be determined that the matching business metric does not meet the alert triggering conditions of the alert rules to avoid proceeding to the subsequent risk handling process.

[0035] This embodiment accurately matches the corresponding business indicators by defining the detection scope and indicator name of the early warning rules, avoiding false and missed early warnings and ensuring the accuracy of early warning detection. The comparison operators for early warning trigger conditions support joint early warnings for multiple indicators, making it suitable for complex business risk assessment scenarios and enabling early warning rules to flexibly adapt to diverse business needs.

[0036] It should be noted that some business metrics are not generated over a long period, but rather at specific time points. For example, some performance-related business metrics are only collected at the end of the month or year. Therefore, the corresponding alert rules for these business metrics do not need to be executed continuously for an extended period, but only after the corresponding business metrics are collected. To address this, an activation period can be set for each alert rule. This ensures that the alert rule is active when the current time falls within its activation period, and that the active alert rule can be used to detect and issue alerts for the corresponding business metrics.

[0037] When an alert rule is active, it will perform alert detection on the matching business indicators according to the preset alert frequency. If the risk issues of some business indicators cannot be resolved in a short period of time, the alert instance corresponding to the business indicator will be generated according to the corresponding alert frequency, resulting in the management account frequently receiving alert instances for the same business indicator, and the alert noise is high.

[0038] In one embodiment, to control the generation frequency of early warning instances for the same business metric, a suppression period can be set in the early warning rule to extend the generation time interval of early warning instances and reduce invalid early warnings. Specifically, when the business metric meets the early warning triggering conditions specified by the early warning rule, the existence duration of the latest early warning instance corresponding to the early warning rule is determined; if the existence duration does not exceed the suppression period of the early warning rule, the generation operation of the early warning instance is skipped; if the existence duration exceeds the suppression period of the early warning rule, the generation operation of the early warning instance is executed.

[0039] The suppression period can be understood as the shortest time interval between two consecutively generated warning instances under the same warning rule. The latest warning instance is the warning instance whose generation time is closest to the current time and is not in a deactivated state. The existence duration is the time interval from the generation of the latest warning instance to the present. For example, a warning rule can correspond to a list of warning instances. The list stores the warning instances generated by the warning rule and sorts them from top to bottom according to the order of generation. Once a warning instance is deactivated, it is deleted from the list. After determining that the business indicator meets the warning conditions specified by the warning rule, the generation time of the latest warning instance can be queried from the last row of the warning instance list. The existence duration of the latest warning instance is obtained by subtracting the generation time from the current time. This existence duration is compared with the suppression period in the warning rule. If the existence duration does not exceed the suppression period, it means that there is no need to regenerate the warning instance, thus automatically skipping the generation operation of the warning instance to avoid frequent pushes of similar warning instances to the management account and effectively reduce warning noise. If the duration of the issue exceeds the suppression period, it indicates that the management account needs to be prompted again to address the risk issue related to the corresponding business indicator. This will trigger the generation of a new warning instance, which will then be sent to the management account to promptly notify the administrator to address the risk issue and prevent it from being overlooked. The warning instance generation process can be found in step S120.

[0040] This embodiment optimizes the push rhythm of early warning instances by setting the suppression period in the early warning rules. This ensures that new early warnings are continuously pushed when business indicators are continuously abnormal to remind administrators to pay attention to unresolved risks, while avoiding repeated pushes in a short period of time to prevent notification fatigue for administrators. This achieves a precise match between the early warning push rhythm and the risk handling rhythm, and improves the rationality of business control.

[0041] In this embodiment, the suppression period in the early warning rules can be set by the manager according to actual needs, or it can be set by the risk early warning system according to the business indicator category matched by the early warning rules. For example, the risk early warning system can set three suppression periods for performance-related business indicators, process-related business indicators, and asset-related business indicators respectively. The suppression period corresponding to performance-related business indicators is longer than that corresponding to process-related business indicators, and the suppression period corresponding to process-related business indicators is longer than that corresponding to asset-related business indicators, so that the early warning rhythm of performance-related business indicators matches the performance assessment rhythm, the early warning rhythm of process-related business indicators matches the customer follow-up rhythm, and the early warning rhythm of asset-related business indicators matches the store's emergency handling rhythm.

[0042] In another embodiment, after a follow-up task is assigned by the administrator to the executor, the executor needs to spend a certain amount of time processing the task. If an alert instance is sent to the administrator during the executor's task processing, it may cause duplicate configuration of the follow-up task and affect the processing of important alerts. To address this, a processing time can be reserved for the follow-up task. During this processing time, an alert silence mechanism can be introduced to avoid generating alert instances and follow-up tasks again in the short term. Specifically, if the business indicator meets the alert triggering conditions specified by the alert rule, the status of the latest follow-up task corresponding to the alert rule is determined; if the distribution time of the latest follow-up task has not reached the preset time, the alert instance generation operation is skipped; if the distribution time of the latest follow-up task has reached the preset time and remains in an unprocessed state, the alert instance generation operation is performed.

[0043] The latest follow-up task is the one closest in time to the current moment corresponding to the warning instance of the warning rule. If no corresponding follow-up task exists for the warning rule, the warning instance generation operation is executed directly. The status of a follow-up task includes unprocessed and processed states. A processed state for the latest follow-up task indicates that the person executing the latest follow-up task is already executing or has completed the task. The issuance duration is the time interval from when the latest follow-up task was issued to the executor to the current moment. It can be understood that a follow-up task is an instruction issued by the manager to address the risk issues of the business indicators corresponding to the warning rule, and the latest follow-up task is the most recently issued instruction. The status of the latest follow-up task directly indicates whether someone has recently addressed the risk issues of this business indicator. Comparing the issuance duration of the latest follow-up task with the preset duration directly indicates whether the current follow-up task is still within the reserved processing time period. Combined with the status of the latest follow-up task, it can be determined whether the current follow-up task has been processed after exceeding the reserved processing time period, and thus whether to continue generating warning instances.

[0044] For example, an alert rule can correspond to a follow-up task list. This list stores the follow-up tasks for each alert rule, sorted from top to bottom according to their creation order. The list also associates the identifiers of the follow-up tasks with the corresponding alert instances. Once an alert instance is deactivated, the follow-up task is removed from the list. After determining that the business metrics meet the alert conditions specified by the alert rule, the latest follow-up task's delivery time and status can be queried from the last row of the follow-up task list. The delivery duration is obtained by subtracting the delivery time from the current time. If the delivery duration of the latest follow-up task is less than the preset duration, it indicates that the latest follow-up task is still within the reserved processing time period. Therefore, an alert silence mechanism can be triggered to skip the generation of alert instances, avoiding the repeated generation of similar follow-up tasks in a short period and saving human resources. If the latest follow-up task has been issued for a preset period of time and remains unprocessed, it indicates that the latest follow-up task has not been followed up and processed by the corresponding personnel after the reserved processing time period has expired. At this time, the operation of generating an early warning instance can continue to be performed. The newly generated early warning instance will remind the manager that the corresponding risk issue has not been processed. The manager can then decide whether to reassign a new follow-up task or remind the relevant personnel to process the follow-up as soon as possible to ensure that the risk issue is dealt with in a timely manner.

[0045] This embodiment utilizes the issuance duration and status of the latest follow-up task to determine whether it has been processed promptly by relevant personnel within the reserved processing time period. If it is determined that the latest follow-up task is still within the reserved processing time period, a warning silence mechanism is triggered to skip the generation of warning instances, avoiding the repeated generation of similar follow-up tasks in a short period, saving manpower, and reducing warning noise. If it is determined that the latest follow-up task has not been processed within the reserved processing time period, a warning instance is generated. This warning instance serves as a reminder to management personnel that the risk issue has not been addressed, ensuring that the risk issue is resolved in a timely manner.

[0046] Furthermore, the risk warning system can simultaneously set a suppression period and a silent response mechanism to achieve warning noise reduction in both time and behavioral dimensions, thereby improving the rationality of business control. In addition to the suppression period, time-dimensional warning noise reduction can also be achieved through special periods such as statutory holidays, meaning that no warning instances are generated during the current time period.

[0047] If risks associated with business metrics remain unresolved for an extended period, it indicates that the administrator responsible for issuing the alert instance has failed to promptly assign follow-up tasks, or that the assigned tasks are ineffective in resolving the risk. In such cases, higher-level administrators need to intervene and address the risk to prevent prolonged delays and potentially more serious problems. To address this, the alert rule can be upgraded once a certain number of alert instances have accumulated or the instances have existed for a certain duration. This upgrade will then forward the alert instances generated by the alert rule to a higher-level management account.

[0048] In this embodiment, an upgrade cycle can be added to the warning rules. The upgrade cycle is used to determine whether the warning rule meets the upgrade conditions, and the warning rule is upgraded when the upgrade conditions are met. Specifically, the business indicators are first detected for warning based on the warning trigger conditions of the warning rule. If the business indicators meet the warning trigger conditions specified by the warning rule, and the existence duration of the warning instance corresponding to the warning rule exceeds the upgrade cycle of the warning rule, the warning level of the warning rule is increased. The management account specified by the warning rule is determined according to the warning level of the warning rule. The existence duration is the time interval from the generation of the warning instance that has not been cleared. The unprocessed duration is the time interval from the generation of the unprocessed warning instance to the present. When the existence duration of the warning instance exceeds the upgrade cycle of the warning rule, it indicates that the risk problem of the business indicator corresponding to the warning rule has not been resolved for a long time. At this time, the warning level of the warning rule can be increased by one level from the existing level. For example, if the initial level of the warning rule is level one, it will be upgraded to level two after one upgrade, and so on, until the highest level is reached.

[0049] After upgrading the alert level of an alert rule, the account of the corresponding level of management personnel can be selected as the management account to receive alert instances. For example, after the alert level of an alert rule is upgraded to level two, the alert instances generated based on the alert rule can be sent to the management account of the level two management layer. In this embodiment, if an alert instance remains unresolved for an extended period, the alert level of the corresponding alert rule will be upgraded, thereby pushing subsequently generated alert instances to higher-level management personnel, preventing the risk from worsening due to prolonged delays.

[0050] In one embodiment, the early warning rule can simultaneously set a suppression period and an escalation period, and activate an early warning silence mechanism to improve the early warning system of the risk warning system, significantly reducing invalid alarms while ensuring that warnings of serious risk issues are not missed. For example, Figure 3 This is a schematic diagram of the early warning rule processing flow provided in an embodiment of this application. For example... Figure 3As shown, after determining the business metrics that match the early warning rules, it is judged whether the business metrics meet the early warning triggering conditions of the early warning rules. If not, no early warning instance is generated and the process waits for the next processing. If the business metrics meet the early warning triggering conditions, it is further judged whether the existence duration of the latest early warning instance is greater than the suppression period of the early warning rule. If the existence duration is not greater than the suppression period, no early warning instance is generated and the process waits for the next processing. If the existence duration is greater than the suppression period, it is further judged whether the delivery duration of the latest follow-up task has reached the preset duration and whether the status is unprocessed. If the delivery duration of the latest follow-up task is less than the preset duration, no early warning instance is generated and the process waits for the next processing. If the delivery duration of the latest follow-up task is greater than the preset duration and remains unprocessed, it is further judged whether the existence duration of the early warning instance exceeds the upgrade period. If the existence duration exceeds the upgrade period, the early warning rule level is upgraded, and then an early warning instance is generated based on the new level of the early warning rule. If the existence duration does not exceed the upgrade period, the early warning rule level is not upgraded, and an early warning instance is generated based on the early warning rule.

[0051] The information mentioned above regarding the early warning rules refers to the configuration information of the early warning rules. The risk early warning system provides a front-end rule configuration interface, where administrators can input the configuration information for the early warning rules. Based on this configuration information, the risk early warning rules are created for risk warning purposes. Optionally, administrators can input necessary configuration information for the early warning rules in the rule configuration interface, such as the early warning type, the indicator name in the conditional expression of the early warning trigger condition, the comparison operator, and the indicator threshold. They can also input additional configuration information, such as the suppression period, whether to activate the early warning silence mechanism, the escalation period, and the receiving role. The risk early warning system creates the corresponding early warning rules based on the configuration information.

[0052] Alternatively, the risk warning system can automatically recommend reference ranges for indicator thresholds in the warning trigger conditions based on historical indicator values ​​of past business metrics, to assist managers in configuring reasonable indicator thresholds. For example, Figure 4 This is a flowchart illustrating the creation of early warning rules provided in an embodiment of this application. For example... Figure 4 As shown, the steps for creating an early warning rule specifically include S1401-S1403: S1401. In response to the warning rule configuration operation, obtain the configuration information of the corresponding warning rule. The configuration information includes the indicator name, comparison operator, detection range and warning type.

[0053] The early warning rule configuration operation is triggered when an administrator enters the configuration information for the early warning rule in the rule configuration interface. The risk early warning system responds to this operation by obtaining the configuration information entered by the administrator.

[0054] S1402. Determine the threshold reference range based on the historical index values ​​corresponding to the index name and the comparison operator.

[0055] For example, based on the indicator name, the corresponding historical indicator value is queried in the indicator database, and the maximum or minimum indicator value is obtained from the historical indicator values ​​of the indicator name. The maximum or minimum indicator value is then substituted into the calculation formula of the comparison operator to obtain the corresponding indicator result. The range of preset values ​​fluctuating around the indicator result is used as the threshold reference range.

[0056] S1403. In response to the selection operation of the threshold reference range, obtain the corresponding indicator threshold, and create the corresponding early warning rule based on the indicator threshold and configuration information.

[0057] For example, the threshold reference range is displayed in the rule configuration interface. In response to an administrator's selection of a value within the threshold reference range in the rule configuration interface, that value is determined as the indicator threshold in the early warning trigger condition. A triplet of the indicator threshold, indicator name, and comparison operator is created for the early warning trigger condition. The early warning trigger condition and early warning type are then combined to create an early warning rule. After the early warning rule is created, the risk early warning system can execute the indicator early warning processing method according to a preset detection frequency to detect matching business indicators based on the early warning rule.

[0058] This embodiment generates a threshold reference range for the indicator thresholds of the early warning trigger conditions by using historical indicator values ​​and comparison operators. This provides scientific data support for managers to set early warning trigger conditions, ensuring that the early warning trigger conditions conform to the actual operation rules of the business, reducing the misjudgment or missed judgment of early warnings caused by unreasonable threshold settings, and improving the reliability of early warnings.

[0059] S120. If the business indicator meets the warning triggering conditions specified in the warning rule, generate a warning instance for the business indicator.

[0060] For example, after determining that the business indicators meet the warning trigger conditions of the warning rules, the risk warning system can generate warning instances based on the detection scope, warning type, indicator threshold, indicator name, and indicator value in the warning rules.

[0061] In one embodiment, when generating an early warning instance for a business indicator, data related to business risks can be searched from the business module to which the business indicator belongs. This data is then organized into an evidence set for the early warning instance, allowing managers to quickly locate the root cause of the risk and issue risk mitigation tasks based on the evidence set, thereby improving risk mitigation efficiency. For example, Figure 5 This is a flowchart illustrating the generation of early warning instances provided in an embodiment of this application. For example... Figure 5 As shown, the steps for generating an early warning instance specifically include S1201-S1203: S1201. Obtain related information from each business module based on business metrics. The related information includes related business data of the business metrics and / or similar business metrics of other objects.

[0062] Among them, "related information" refers to a set of relevant data that is associated with the business indicator that triggered the alert, and can assist in analyzing the cause of the alert and supplement the background of the alert. This includes related business data of the business indicator and / or similar business indicators of other objects. Related business data refers to the original or derived business data directly related to the business indicator that triggered the alert, used to trace the root cause of the business indicator's anomaly. For example, if the alert instance triggered by the business indicator "Monthly Signed Sales Amount of Store A" is due to the total monthly signed sales amount not reaching the threshold, its related business data may include all signed sales details of Store A for that month, follow-up records of customers who did not sign sales, task execution records, etc. Similar business indicators of other objects refer to business indicators that belong to the same type as the business indicator that triggered the alert instance but belong to a different object, and are usually used to compare and analyze the degree of anomaly of the business indicators. For example, for the business indicator "Monthly Signed Sales Amount of Store A," similar business indicators of other objects could be the monthly signed sales amounts of other stores.

[0063] For example, after determining that a business indicator meets the early warning trigger conditions, various business data for that indicator can be retrieved in each business module based on its assigned object. For instance, if the business indicator is "Monthly Total Sales for Store A," then all sales details, follow-up records for customers without sales, target achievement records, and task execution records for Store A can be queried in the contract system, customer management module, target management module, and task execution module. Furthermore, other related objects at the same level can be identified based on the business indicator's assigned object, and their corresponding business indicators can be obtained.

[0064] S1202. Generate an evidence set by using business metrics as a summary of the evidence set and related information as details of the evidence set.

[0065] For example, the indicator name, belonging object, indicator value, and collection timestamp of the business indicator are used as a summary of the evidence set to concisely and clearly present the core content of the early warning instance. Related business data and / or similar business indicators of other objects are used as details in the evidence set to help managers quickly locate the root cause of risks.

[0066] S1203. Generate an early warning instance based on the early warning type and evidence set of the early warning rules.

[0067] The alert type defines the risk issues associated with business metrics, allowing managers to intuitively understand these risks. The risk alert system generates alert instances from the alert type and evidence set of the alert rules. Furthermore, the system assigns a unique alert instance identifier and confirms the alert trigger time and status, saving these information to the alert instance as well. Finally, the default status of an alert instance upon initial creation is set to "pending."

[0068] This embodiment adds an evidence set constructed from the correlation information of business indicators to the early warning instance, so that managers can quickly locate the root cause of the risk of business indicators through the evidence set, without having to repeatedly jump between multiple business modules to query the relevant information of the anomaly, avoiding delays in handling due to missing information, and effectively improving the efficiency of risk handling.

[0069] S130. Send the warning instance to the management account specified in the warning rule, so that the management account can configure and send the task information of the warning instance to the task execution module. The task execution module will create a follow-up task for the warning instance based on the task information and send the follow-up task to the corresponding execution account.

[0070] For example, the management account specified by the early warning rule can be determined based on the category of the business indicator corresponding to the early warning rule. For instance, when the early warning rule corresponds to a performance-related business indicator, the management account specified by the early warning rule can be determined to be the headquarters management account; when the early warning rule corresponds to a process-related business indicator, the management account specified by the early warning rule can be determined to be the regional management account; and when the early warning rule corresponds to an asset-related business indicator, the management account specified by the early warning rule can be determined to be the store management account. Furthermore, the management account specified by the early warning rule can also be determined from multiple management accounts of the same level role by combining the detection scope of the early warning rule.

[0071] Optionally, the alert rule includes a receiving role, which indicates the management account to which the alert instance generated by the alert rule is sent. The alert instance can be sent to the corresponding management account based on the receiving role of the alert rule. For example, if the receiving role is a management account of a certain management level at headquarters, the alert instance can be sent directly to that management account.

[0072] In this embodiment, when an administrator logs into a terminal device using an administrator account, the terminal device establishes a communication connection with the risk warning system. The risk warning system associates this communication connection with the administrator account logged into the terminal device. When the risk warning system generates a warning instance corresponding to the administrator account, it pushes the warning instance to the terminal device logged into that administrator account via the communication connection. The terminal device can add the warning instance to the warning instance list displayed on the front-end interface. When an administrator clicks on a warning instance in the warning instance list, they can open the warning instance display page and view the warning type and detailed information in the evidence set for the warning instance.

[0073] If the current administrator account is not logged in, the risk warning system will save the warning instance and the administrator account in the instance database. Subsequently, when an administrator logs into a terminal device using the administrator account, the terminal device retrieves the warning instance associated with the logged-in administrator account from the instance database via the API provided by the risk warning system. The retrieved warning instance is then added to the warning instance list displayed on the front-end interface. When an administrator clicks on a warning instance in the list, they can open the warning instance's display page to view the warning type and detailed information in the evidence set.

[0074] Optionally, the risk warning system can also generate corresponding push messages based on warning instances. These push messages can be SMS messages or WeChat messages, and are sent to the corresponding management accounts so that terminal devices logged into those management accounts can display the push messages.

[0075] Optionally, when a risk issue occurs in one business metric, it may trigger similar risk issues in other business metrics. For example, a backlog warning for customer follow-up at a store might be one of the reasons for a delayed sales target warning. In this case, the two business metrics can be considered to have a causal relationship. To address this, relationships between various business metrics can be established in advance, such as causal relationships and concurrent relationships. When the risk warning system generates multiple warning rule instances that point to the same management account, it determines the relationships between these instances and sends them along with their corresponding relationships to the management account, allowing the management account to view the instances and their relationships. For instance, after iterating through the warning rules to generate multiple warning instances, the system groups these instances according to the management accounts corresponding to the rules. If a group contains more than one instance and there is a relationship between the instances within that group, the group's instances and their corresponding relationships are sent together to the corresponding management account. After receiving the alert instances and their corresponding relationships within the group, the management account will collect and display the alert instances and attach their corresponding relationships to assist managers in issuing follow-up tasks based on the root causes of risk issues and improve the efficiency of handling risk issues.

[0076] Furthermore, the alert instance's display page in the management account includes a jump entry to the task configuration interface of the task execution module. This task configuration interface is used to input the task information corresponding to the alert instance. For example, when an administrator opens the alert instance's display page, they can click the jump entry associated with the alert instance to jump directly to the task configuration interface. The administrator can then input the task information corresponding to the alert instance, such as the user account of the executor, the task deadline, and task requirements. Afterwards, clicking the submit control on the task configuration interface allows the management account to upload the task information entered to the task execution module. This embodiment binds a jump entry to the task configuration interface of the corresponding follow-up task to the alert instance's display page, enabling administrators to enter the task assignment process with a single click from the display page. This simplifies the task assignment operation and improves risk management efficiency.

[0077] Upon receiving the task information corresponding to the alert instance, the task execution module can create a follow-up task for that alert instance based on the user account of the executor, the task deadline, and the task requirements. The follow-up task is then distributed to the corresponding execution account, which executes the task according to its requirements. The execution account is the user account of the person executing the follow-up task.

[0078] Furthermore, after creating a follow-up task, the task execution module can associate the task identifier of the follow-up task with the instance identifier of the corresponding early warning instance and feed it back to the risk early warning system. The instance identifier of the early warning instance is generated by the risk early warning system when the early warning instance is created. When the management account opens the task configuration interface of the early warning instance, the management account sends the instance identifier and task information of the early warning instance to the task execution module. The risk early warning system receives the task identifier of the follow-up task and the instance identifier of the corresponding early warning instance from the task execution module and establishes a mapping relationship between the instance identifier and the task identifier. For example, the risk early warning system can query the corresponding early warning rule based on the instance identifier of the early warning instance, then add the corresponding task identifier to the follow-up task list of that early warning rule, and then associate and save the instance identifier with the task identifier in the follow-up task list, thus completing the update of the follow-up task list corresponding to the early warning rule. Afterwards, the risk early warning system can update the task status of the corresponding task identifier in the follow-up task list to an unprocessed state to indicate that the follow-up task has not yet been completed.

[0079] After the personnel complete the corresponding follow-up task, they can upload the execution result through their execution account. The execution account then transmits the result to the task execution module, which forwards it to the management account that issued the follow-up task. Once the administrator on the management account reviews and approves the result, they send the approval result back to the task execution module, which updates the follow-up task to a processed status. Afterward, the task execution module sends the task identifier and task status of the follow-up task to the risk warning system. The risk warning system receives the task identifier and task status from the task execution module, queries the local follow-up task and local warning instance based on the sent task identifier, and updates the status of the local follow-up task and local warning instance based on the sent task status. For example, the risk warning system queries the list of follow-up tasks corresponding to each warning rule for the task identifier and the associated saved task status and instance identifier. Then, the task status is updated to the processed status. Based on the instance identifier, the status of the associated and saved warning instance is queried in the warning instance list corresponding to the warning rule, and the warning instance status is updated to the processing status. This ensures the consistency of the task status between the risk warning system and the task execution module, and also ensures the consistency between the task status of the risk warning system and the warning instance status.

[0080] Understandably, if a risk warning system has a warning silence mechanism set up, the system needs to determine whether the silence mechanism has been triggered based on the status of the follow-up task corresponding to the warning rule. Maintaining consistency between the risk warning system and the task execution module's task status allows the system to accurately determine whether the silence mechanism has been triggered based on the follow-up task's status, ensuring the reliability of warning instance suppression.

[0081] After the task execution module updates the follow-up task to the processed status, it can also send the task identifier and processed status of the follow-up task to the management account. The management account can then update the status of the local follow-up task and the local alert instance, so that the administrator can query the status of the alert instance and the corresponding follow-up task in real time.

[0082] To more clearly illustrate the closed-loop control process of the risk warning system and task execution module in this embodiment, which achieves warning triggering and task issuance, this embodiment uses... Figure 6 The closed-loop control chain of early warning triggering and task issuance shown is described using the example shown. Figure 6 As shown, the risk warning system collects business data from the business data sources corresponding to the business modules through the indicator collection layer, and converts the business data into business indicators. The warning rule engine determines which warning rule's trigger condition is met based on each business indicator. When the trigger condition is met, a warning instance generation request is generated for the corresponding warning rule and sent to the warning trigger module. The warning trigger module responds to the warning instance generation request, generates the corresponding warning instance, and pushes the warning instance to the corresponding management account. The management account then redirects to the task configuration interface of the corresponding follow-up task based on the warning instance, enters the task information, and pushes the task information to the task execution module. The task execution module creates the corresponding follow-up task based on the task information and assigns the follow-up task to the corresponding execution account. After completing the task, the executor uploads the corresponding execution result, which is then submitted to the task execution module. The task execution module generates an audit notification for the execution result and pushes it to the management account. The management account, after reviewing the execution result and finding no issues, sends an approval notification to the task execution module. The task execution module changes the status of the follow-up task to the processed status, and then synchronizes the task status to the risk warning system. The risk warning system updates the status of the follow-up task in a synchronized manner to confirm that the executor is already handling the risk issues of the business warning, thus forming a closed-loop control from warning triggering to risk handling.

[0083] In this embodiment, the task execution module can use a unified task template for all warning instances, or it can use different task templates for different types of warning instances. If the follow-up task corresponding to a certain warning instance directly leads to the resolution of business metric risks after processing, the task information of the follow-up task can be directly saved as a task template for warning instances of the same type of warning rule, thereby improving task issuance efficiency and risk handling success rate.

[0084] It should be noted that executing a follow-up task does not guarantee the resolution of risks associated with business metrics. Therefore, when a follow-up task transitions to a "processed" status, the corresponding alert instance will not be changed to a "resolved" status, but rather to a "processing" status. This "processing" status serves as a notification to administrators that the follow-up task for the alert instance has been completed. An alert instance generated based on the alert rules corresponding to the business metric will only be changed to a "resolved" status if and only if there are no risks associated with the business metric.

[0085] Optionally, when a business metric does not meet the warning triggering conditions specified in the corresponding warning rule, it indicates that there is no risk issue with the business metric. In this case, the warning instance corresponding to the warning rule can be converted to a deactivated state to indicate that the risk warning for the corresponding business metric has been deactivated.

[0086] Alternatively, a warning cancellation condition can be added to the warning rule. When the current business indicator meets the warning cancellation condition of the warning rule, the warning instance corresponding to the warning rule is converted to a cancelled state, indicating that the risk warning for the corresponding business indicator has been cancelled. In this embodiment, if there are warning instances in an uncancelled state under the warning rule, and the business indicator meets the warning cancellation condition specified by the warning rule, the warning instance corresponding to the warning rule is marked as cancelled. The cancelled state of the warning instance is synchronized to the management account specified by the warning rule, so as to update the status of the local warning instance through the management account. The relevant data of the warning instance is archived and saved, including at least one of the following: the time of generation of the warning instance, the value of the generated indicator, the time of issuance of the corresponding follow-up task, the time of cancellation, and the value of the cancelled indicator.

[0087] For example, Figure 7 This is a schematic diagram illustrating the process of generating and deactivating early warning instances provided in this application's embodiments. For example... Figure 7 As shown, after a certain period of time following the generation of an early warning instance, the next round of early warning detection can be initiated to determine the business metrics that match each early warning rule. After determining the business metrics that match the early warning rule, it can be checked whether there are any unresolved early warning instances. For example, by querying the list of early warning instances corresponding to the early warning rule to see if any already created early warning instances exist. If not, it can be directly determined whether the business metrics meet the early warning triggering conditions specified by the early warning rule. If they do exist, it is further determined whether the business metrics meet the early warning cancellation conditions specified by the early warning rule. If the business metrics meet the early warning cancellation conditions specified by the early warning rule, the early warning instance corresponding to the early warning rule is marked as cancelled, i.e., the early warning instance of the early warning rule is cancelled. If the business metrics do not meet the early warning cancellation conditions specified by the early warning rule, it can be further determined whether the business metrics meet the early warning triggering conditions specified by the early warning rule. If they do, an early warning instance is generated; otherwise, no early warning instance is generated, and the system waits for the next detection.

[0088] The warning cancellation condition can also be a conditional expression, which includes the indicator name, comparison operator, and indicator threshold. The comparison operator in the warning cancellation condition can be the same as or different from the comparison operator in the warning trigger condition. When the comparison operators are the same, the warning cancellation condition for business indicators is easier to achieve than the warning trigger condition. The indicator value of the business indicator is substituted into the comparison operator to calculate the corresponding total indicator value, confirming whether the comparison operator's size logic holds. If the size logic holds, the warning cancellation condition is confirmed, and the warning instance status in the warning instance list corresponding to the warning rule is marked as cancelled, thus clearing the warning instances in the warning instance list. Furthermore, the instance identifier and cancelled status of the warning instance are synchronized to the management account specified by the warning rule. The management account updates the status of all corresponding warning instances to cancelled based on the instance identifier. Afterwards, the management account can delete the cancelled warning instances from the management account's warning instance display list to avoid warning instances remaining in the management account's warning instance list for an extended period and interfering with newly generated warning instances. If the size logic is not true, it is confirmed that the warning cancellation condition has not been met, thus retaining the warning instance status in the warning instance list corresponding to the warning rule, and then determining whether to generate a new warning instance based on the warning trigger condition in the warning rule.

[0089] After a warning instance is lifted, the risk warning system can archive and save the relevant data of the warning instance. This data includes at least one of the following: the warning instance's generation time, the generated indicator value, the time the corresponding follow-up task was issued, the lifting time, and the lifting indicator value. The time the follow-up task was issued can be the time when the risk warning system receives the warning identifier and task identifier sent by the task execution module. The generation time is the timestamp of the data collection for the business indicator corresponding to the warning instance, and the generated indicator value is the indicator value of the business indicator corresponding to the warning instance. The lifting time can be the timestamp of the data collection for the business indicator that meets the warning lifting conditions, and the lifting indicator value is the indicator value of the business indicator that meets the warning lifting conditions. The instance identifier, task identifier, warning rule type, generation time, generated indicator value, the time the corresponding follow-up task was issued, the lifting time, and the lifting indicator value are saved as a single warning instance record, and this record is stored in the instance database. If multiple warning instances exist corresponding to a warning rule, these multiple warning instances can be lifted simultaneously, resulting in multiple warning instance records. These multiple warning instance records will have the same warning rule type, lifting time, and lifting indicator value.

[0090] This embodiment utilizes the release trigger conditions in the early warning rules to automatically release the early warning instances corresponding to the early warning rules, so as to avoid the early warning instances remaining for a long time and affecting the instance management of the risk early warning system and the instance display of the management account, thereby improving the convenience of early warning management.

[0091] In summary, the indicator early warning processing method provided in this application, by introducing task configuration of the management account and task issuance of the execution account after generating an early warning instance, forms a closed-loop control from early warning triggering to risk handling, ensuring that each risk issue can be detected and handled in a timely manner, and improving the reliability of business control. Through the generation and issuance of follow-up tasks for early warning instances, real-time tracking and management of risk handling are achieved, effectively avoiding omissions and delays in risk handling, and ensuring the stable operation of retail store business.

[0092] Figure 8 This is a schematic diagram of the structure of an indicator early warning processing device provided in an embodiment of this application, with reference to... Figure 8 The indicator warning processing device includes a processor 31, a memory 32, a communication device 33, an input device 34, and an output device 35. The number of processors 31 and the number of memories 32 in the indicator warning processing device can be one or more. The processor 31, memory 32, communication device 33, input device 34, and output device 35 of the indicator warning processing device can be connected via a bus or other means.

[0093] The indicator early warning processing device provided above can be used to execute the indicator early warning processing method provided in the above embodiments, and has corresponding functions and beneficial effects.

[0094] This application also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform an indicator warning processing method.

[0095] Storage medium – any type of memory device or storage device. The term “storage medium” is intended to include: mounting media, such as CD-ROM, floppy disk, or magnetic tape devices; computer system memory or random access memory, such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory, such as flash memory, magnetic media (e.g., hard disk or optical storage); registers or other similar types of memory elements, etc. Storage medium may also include other types of memory or combinations thereof. Furthermore, storage medium may reside in a first computer system in which the program is executed, or it may reside in a different second computer system connected to the first computer system via a network (such as the Internet). The second computer system can provide program instructions to the first computer for execution. The term “storage medium” can include two or more storage media residing in different locations (e.g., in different computer systems connected via a network). Storage medium may store program instructions (e.g., specifically implemented as a computer program) executable by one or more processors.

[0096] The storage medium and indicator warning processing device provided in the above embodiments can execute the indicator warning processing method provided in any embodiment of this application. For technical details not described in detail in the above embodiments, please refer to the indicator warning processing method provided in any embodiment of this application.

[0097] The above description is merely a preferred embodiment and the technical principles employed in this application. This application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions that can be made by those skilled in the art will not depart from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application. The scope of this application is determined by the scope of the claims.

Claims

1. A method for handling early warning of indicators, characterized in that, include: Business indicators are determined based on the business data of each business module, and the business indicators are detected according to the preset early warning rules. If the business indicator meets the warning triggering conditions specified by the warning rule, an warning instance for the business indicator is generated. The warning instance is sent to the management account specified by the warning rule, so that the management account can configure and send the task information of the warning instance to the task execution module. The task execution module creates a follow-up task for the warning instance based on the task information and sends the follow-up task to the corresponding execution account.

2. The indicator early warning processing method according to claim 1, characterized in that, The process of determining business metrics based on business data from each business module includes: Collect business data from various business modules, including at least two of the following: contract transaction module, customer management module, target management module, and task execution module; The business data is transformed based on a preset standard indicator structure to obtain corresponding business indicators. The standard indicator structure includes indicator name, indicator value, collection timestamp, and belonging object. Accordingly, after determining the business metrics based on the business data of each business module, the process also includes: The business categories corresponding to the business indicators are determined, including performance-based, process-based, and asset-based categories. Among them, the management account specified by the early warning rule for performance-based business indicators is the headquarters management account, the management account specified by the early warning rule for process-based business indicators is the regional management account, and the management account specified by the early warning rule for asset-based business indicators is the store management account.

3. The indicator early warning processing method according to claim 1, characterized in that, The early warning rule includes an indicator name and a detection range. The condition expression for the early warning triggering condition includes an indicator name, a comparison operator, and an indicator threshold. The comparison operator is used to compare the indicator value corresponding to the indicator name with the indicator threshold, or to calculate the total indicator value corresponding to multiple indicator names and compare it with the indicator threshold. Accordingly, the detection of the business indicators according to the preset early warning rules includes: Based on the detection range and indicator name in the preset early warning rules, determine the matching business indicators corresponding to the early warning rules; Based on the indicator values ​​of the matching business indicators and the indicator thresholds in the conditional expression, determine whether the comparison operators in the conditional expression are true; If the comparison operator is true, then the matching business indicator is determined to meet the early warning triggering condition; otherwise, the matching business indicator is determined not to meet the early warning triggering condition.

4. The indicator early warning processing method according to claim 1, characterized in that, The early warning rules include a suppression period; Accordingly, after detecting the business indicators according to the preset early warning rules, the method further includes: If the business indicator meets the early warning triggering conditions specified by the early warning rule, determine the duration of existence of the latest early warning instance corresponding to the early warning rule; If the duration of the warning does not exceed the suppression period of the warning rule, the generation of the warning instance is skipped. If the duration of an event exceeds the suppression period of the warning rule, an warning instance generation operation is performed. And / or, After detecting the business indicators according to the preset early warning rules, the method further includes: If the business indicator meets the warning triggering conditions specified by the warning rule, determine the status of the latest follow-up task corresponding to the warning rule; If the delivery time of the latest follow-up task has not reached the preset time, skip the generation of the warning instance. If the latest follow-up task has been issued for a preset period of time and remains unprocessed, then the operation of generating an early warning instance is performed.

5. The indicator early warning processing method according to claim 1, characterized in that, The early warning rules include early warning types; correspondingly, the early warning instances for generating the business metrics include: Based on the business metrics, obtain related information in each of the business modules. The related information includes related business data of the business metrics and / or similar business metrics of other objects. The business metrics are used as a summary of the evidence set, and the related information is used as a detail of the evidence set to generate an evidence set. An early warning instance is generated based on the early warning type and the evidence set according to the early warning rules; And / or, The warning rule includes a receiving role; correspondingly, sending the warning instance to the management account specified in the warning rule includes: According to the receiving role of the aforementioned warning rule, the warning instance is sent to the corresponding management account; The warning instance is configured with a jump entry to a task configuration interface on the warning instance display page of the management account. The task configuration interface is used to input the task information corresponding to the warning instance.

6. The indicator early warning processing method according to claim 1, characterized in that, The early warning rules also include an upgrade cycle; Accordingly, after detecting the business indicators according to the preset early warning rules, the method further includes: If the business indicator meets the warning triggering conditions specified by the warning rule, and the duration of the warning instance corresponding to the warning rule exceeds the upgrade cycle of the warning rule, then the warning level of the warning rule is increased. The management account specified by the warning rule is determined based on the warning level of the warning rule.

7. The indicator early warning processing method according to claim 1, characterized in that, The method further includes: In response to the early warning rule configuration operation, the configuration information of the corresponding early warning rule is obtained, including the indicator name, comparison operator, detection range and early warning type; The threshold reference range is determined based on the historical index values ​​corresponding to the index name and the comparison operator. In response to the selection operation of the threshold reference range, the corresponding indicator threshold is obtained, and a corresponding early warning rule is created based on the indicator threshold and the configuration information. And / or, After generating the alert instance for the business metric, the following is also included: When multiple warning instances of warning rules are generated and the multiple warning rules point to the same management account, the relationship between the multiple warning instances is determined. Accordingly, sending the warning instance to the management account specified in the warning rule includes: The multiple warning instances and their corresponding relationships are sent to the management account so that the management account can display the multiple warning instances and their corresponding relationships.

8. The indicator early warning processing method according to claim 1, characterized in that, After the task execution module creates the follow-up task for the early warning instance based on the task information, the method further includes: Receive the task identifier of the follow-up task and the instance identifier of the corresponding early warning instance from the task execution module, and establish a mapping relationship between the instance identifier and the task identifier; Accordingly, after the follow-up task is sent to the execution account, the following steps are also included: Receive the task identifier and task status sent by the task execution module, and query the local follow-up task and local early warning instance based on the sent task identifier; Update the status of the local follow-up task and the local early warning instance according to the sent task status.

9. The indicator early warning processing method according to claim 1, characterized in that, The warning rule also includes warning cancellation conditions; correspondingly, the method also includes: If there are warning instances in the warning rule that are not yet lifted, and if the business indicator meets the warning lifting conditions specified by the warning rule, then the warning instance corresponding to the warning rule will be marked as lifted. The status of the alert instance being deactivated is synchronized to the management account specified in the alert rule, so as to update the status of the local alert instance through the management account; The relevant data of the warning instance is archived and saved. The relevant data includes at least one of the following: the time of generation of the warning instance, the generation index value, the time of issuance of the corresponding follow-up task, the time of cancellation, and the cancellation index value.

10. An indicator early warning processing device, characterized in that, include: One or more processors; A memory that stores one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the indicator warning processing method as described in any one of claims 1-9.

Images