Business support device, business support method, and business support program

Abstract

Multiple general-purpose algorithms for detecting outlier data can be freely rearranged and executed in the required order. [Solution] The execution unit executes multiple alert definitions, each using a different algorithm to analyze data and detect anomalies. The execution control unit controls the execution unit to execute each alert definition in the order assigned to it. The execution control unit also uses the calculation results obtained from executing the previously scheduled alert definitions to control the execution unit so that the next scheduled alert definition detects anomalies. This allows multiple general-purpose algorithms for detecting anomaly data to be freely rearranged and executed in the required order.

Description

Technical Field

[0001] The present invention relates to a business support device, a business support method, and a business support program. Background Art

[0002] Patent Document 1 (Japanese Unexamined Patent Application Publication No. 2024-125737) discloses a remote monitoring system that remotely controls various types of equipment in a factory from an advanced perspective, and can flexibly execute appropriate responses such as monitoring and control for each equipment according to various states of the equipment.

[0003] Paragraph 0035 of Patent Document 1 describes that the optimization algorithm processor creates request control data by selecting and combining control patterns suitable for the equipment according to the state levels (diagnostic results) of one or a plurality of pieces of equipment. In addition, paragraph 0110 of Patent Document 1 describes that the analysis and determination block issues an alert notification when an abnormality occurs in the factory equipment, devices, or manufactured products, and performs an emergency stop of the production line.

[0004] In recent years, corporate internal control standards have been revised, and along with this, demand for enhanced control and monitoring has increased. In order to prevent fraud in corporate management, it is necessary to detect data showing abnormal values and take corrective actions. To improve the detection accuracy of data showing such abnormal values, it is necessary to use a detection method defined in accordance with the fraud being committed. In some cases, detection accuracy can be improved by combining a plurality of statistical calculations. Prior Art Documents Patent Documents

[0005] Patent Document 1 Japanese Unexamined Patent Application Publication No. 2024-125737 Summary of Invention Problems to be Solved by the Invention

[0006] However, algorithms for detecting outliers, which are generated by combining multiple statistical calculations, have the problem of being difficult to apply in a general way. On the other hand, general-purpose algorithms for detecting outliers may have low detection accuracy.

[0007] This invention has been made in view of the above-mentioned problems, and aims to provide a business support device, a business support method, and a business support program that enable the detection of abnormal values ​​in data with high detection accuracy while using a general-purpose algorithm. [Means for solving the problem]

[0008] To solve the above-mentioned problems and achieve the objective, the business support device according to the present invention includes an execution unit that executes multiple alert definitions, each of which analyzes data using a different algorithm to detect anomalies, and an execution control unit that controls the execution unit to execute each alert definition in the execution order assigned to each alert definition.

[0009] Furthermore, in order to solve the above-mentioned problems and achieve the objectives, the business support method according to the present invention comprises an execution step in which an execution unit executes a plurality of alert definitions that analyze data using different algorithms to detect abnormal values, and an execution control step in which an execution control unit controls the execution unit to execute each alert definition in the execution order assigned to each alert definition.

[0010] Furthermore, in order to solve the above-mentioned problems and achieve the objectives, the business support program according to the present invention causes a computer to function as an execution unit that executes multiple alert definitions, each of which analyzes data using a different algorithm to detect anomalies, and as an execution control unit that controls the execution unit to execute each alert definition in the execution order assigned to each alert definition. [Effects of the Invention]

[0011] This invention allows for the free rearrangement of multiple general-purpose algorithms and their execution in the required order. [Brief explanation of the drawing]

[0012] [Figure 1] Figure 1 is a block diagram showing the hardware configuration of the business support device according to the embodiment. [Figure 2] Figure 2 shows various tables and storage units provided in the storage unit of the business support device according to the embodiment. [Figure 3] Figure 3 shows an example of a definition master table for anomaly detection. [Figure 4] Figure 4 shows the configuration of a business support device according to an embodiment, which enables anomaly detection operations equivalent to complex algorithms by sequentially executing multiple general-purpose algorithms in a predetermined order. [Figure 5] Figure 5 shows an example of a master table for defining data acquisition for anomaly detection. [Figure 6] Figure 6 shows an example of a stored parameter definition master table. [Figure 7] Figure 7 shows the reference table, extraction criteria, and details for each stored procedure. [Figure 8] Figure 8 shows an example of a schedule definition master table. [Figure 9] Figure 9 shows an example of an anomaly detection definition schedule mapping master table. [Figure 10] Figure 10 shows an example of an execution history table. [Figure 11] Figure 11 shows an example of a clustering results table. [Figure 12] Figure 12 shows an example of a scarcity cost calculation result table. [Figure 13] Figure 13 shows an example of an abnormality detection result table. [Figure 14] Figure 14 shows an example of a construction data table. [Figure 15] Figure 15 shows an example of a construction cost data table. [Figure 16] Figure 16 is a diagram for explaining the determination operation of rare cost items in each cluster. [Figure 17] Figure 17 is a diagram for explaining the operation of calculating the cost amount of a rare cost item for each project in each cluster. [Figure 18] Figure 18 is another diagram for explaining the operation of calculating the cost amount of a rare cost item for each project in each cluster. [Figure 19] Figure 19 is still another diagram for explaining the operation of calculating the cost amount of a rare cost item for each project in each cluster. [Figure 20] Figure 20 is a diagram for explaining the operation of detecting the execution order of the algorithm for each alert definition at the time of anomaly detection. [Figure 21] Figure 21 is a diagram showing how the algorithm of the alert definition to be executed first is detected. [Figure 22] Figure 22 is a diagram showing how the reference table and extraction conditions of the algorithm of the alert definition to be executed first are detected. [Figure 23] Figure 23 is a diagram showing project data with a project status of "completed" extracted from the project data table which is the reference table of the algorithm of the alert definition to be executed first. [Figure 24] Figure 24 is a diagram showing an example of the calculation result of the clustering algorithm. [Figure 25] Figure 25 is a diagram showing how the previous calculation result in the clustering result table is updated with the new calculation result of the clustering algorithm. [Figure 26] Figure 26 is a diagram showing how the algorithm of the alert definition to be executed second is detected. [Figure 27] Figure 27 is a diagram showing how the cost composition ratio corresponding to each cost account item is calculated by the second algorithm using the calculation result of the algorithm executed first. [Figure 28] Figure 28 is a diagram showing the reference table, extraction conditions, and details set in the algorithm to be executed second. [Figure 29] Figure 29 shows how scarce cost information is assigned to scarce costs whose cost composition ratio is below a predetermined level, out of the cost amounts recorded for each cost account. [Figure 30] Figure 30 shows how the previous calculation results in the scarcity cost calculation results table are updated with the new calculation results from the "scarcity cost calculation process," which is the second algorithm to be executed. [Figure 31] Figure 31 shows how the algorithm for the third alert definition to be executed is detected. [Figure 32] Figure 32 shows an example of a project-specific rare cost account cost amount storage unit, which stores the cost amounts of rare accounts acquired for each project in each cluster. [Figure 33] Figure 33 shows the reference table, extraction criteria, and details for the stored procedure for obtaining the amount of rare cost items by construction project. [Figure 34] Figure 34 illustrates the outlier detection process based on an interquartile range algorithm for the cost amounts of rare cost items recorded for each construction project in each cluster. [Figure 35] Figure 35 shows how the calculation results of the previous anomaly detection process are updated with the calculation results of the newly generated anomaly detection process. [Figure 36] Figure 36 is a diagram illustrating the effects of the business support device according to the embodiment. [Modes for carrying out the invention]

[0013] The following describes in detail, with reference to the drawings, an embodiment of the present invention applied to a business support device that detects abnormal values ​​in business data such as cost data acquired from terminal devices at construction sites. However, the present invention is not limited to the following embodiments.

[0014] (overview) The applicant for the present invention previously disclosed in Japanese Patent Publication No. 2023-64481 an anomaly detection device that detects abnormal values ​​in data using alert definitions of multiple algorithms and issues alert notifications. The business support device of the embodiment has the configuration of the anomaly detection device disclosed in Japanese Patent Publication No. 2023-64481.

[0015] While detection methods that combine multiple algorithms to detect data anomalies offer high detection accuracy, they suffer from the problem of being difficult to apply generally. In contrast, detection methods using general-purpose algorithms may have low detection accuracy.

[0016] Therefore, in the business support device of this embodiment, a desired execution order is assigned to multiple general-purpose algorithms, and they are executed in the assigned execution order. This makes it possible to detect anomalies in data with high detection accuracy while using general-purpose algorithms.

[0017] Specifically, the business support device of this embodiment sets individual alert definitions for various types of fraud. In this process, one general-purpose algorithm (a simplified algorithm) is set for each alert definition. Furthermore, a schedule definition is created that manages multiple alert definitions and their execution order, and each alert definition is executed in the order it is executed. In this process, the detection results of each alert definition are stored in the memory unit, and the output of the previous algorithm is used as the input for the next algorithm.

[0018] This allows for the generation of complex algorithmic alert definitions using general-purpose algorithms, and because multiple algorithms are combined and executed in the desired order, it enables the detection of data anomalies with highly accurate alert definitions. In other words, it achieves both versatility and ease of use, as well as the realization of complex, highly accurate algorithmic alert definitions.

[0019] (Hardware configuration) As shown in Figure 1, the business support device 1 of this embodiment includes a storage unit 2, a control unit 3, a communication interface unit 4, and an input / output interface unit 5. An input device 6 and an output device 7 are connected to the input / output interface unit 5.

[0020] The output device 7 can be a display unit of a monitor device (including a household television), a printing device, or a speaker device.

[0021] The input device 6 can include a keyboard, mouse, and microphone, as well as a monitor that works in conjunction with the mouse to provide a pointing device function.

[0022] The communication interface unit 4 is connected to a network 50, such as a wide-area network like the Internet or a private network like a LAN (Local Area Network). Site terminal devices 51 at each construction site are connected to this network 50. The business support device 1 acquires construction data, which is business data such as cost data transmitted from the site terminal devices 51 at each construction site, via the network 50 and the communication interface unit 4, and stores it in the construction data table (reference numeral 20 in Figure 2).

[0023] For the memory unit 2, a storage device such as ROM (Read Only Memory), RAM (Random Access Memory), HDD (Hard Disk Drive), or SSD (Solid State Drive) can be used.

[0024] Memory unit 2 stores a business support program that allows multiple general-purpose algorithms to be freely rearranged and executed in the required order.

[0025] Furthermore, as shown in Figure 2, the memory unit 2 is provided with the following memory areas: anomaly determination definition master table 11, anomaly determination data acquisition definition master table 12, stored parameter definition master table 13, and schedule definition master table 14.

[0026] Furthermore, the memory unit 2 is equipped with the following memory areas: anomaly determination definition schedule mapping master table 15, execution history table 16, clustering result table 17, scarcity cost calculation result table 18, anomaly determination result table 19, and construction data table 20.

[0027] Furthermore, the memory unit 2 is equipped with the following memory areas: a construction cost data table 21, a cluster-specific cost composition ratio memory unit 22, a construction-specific rare cost item cost amount memory unit 24, an execution definition information memory unit 25, and a clustering processing data memory unit 26.

[0028] The business support device 1 of this embodiment uses the following three algorithms when determining anomalies in order to "automatically detect anomalies in the occurrence of rare construction costs between similar construction projects."

[0029] 1. Clustering (grouping similar construction projects together) 2. Rule-based approach (Focusing on the cost composition ratio of each cost account within each group, cost accounts below a certain composition ratio are considered scarce cost accounts.) 3. Anomaly detection algorithm (Focuses on rare cost items in each group and detects construction projects where the cost amount of rare cost items is abnormally high)

[0030] The settings required for each algorithm are as follows:

[0031] 1. In the case of clustering, Clustering explanatory variables (qualitative variables) → Items that form the basis for clustering construction projects. Clustering explanatory variables (quantitative variables) → Items that form the basis for clustering the construction projects, and, Cluster count → Sets the number of groups when dividing construction projects into groups.

[0032] 2. In the case of rule-based systems, Ratio threshold for determining scarcity costs → When focusing on the cost composition ratio of each cost account within each group, a threshold is set for which cost account is considered a scarcity cost account. If it is difficult to determine the threshold, the "interquartile range" algorithm may be used to statistically determine scarcity cost accounts. In this case, items equivalent to "3" below will be used.

[0033] 3. In the case of an anomaly detection algorithm, Anomaly detection algorithm → An algorithm used to detect construction projects where rare cost items are recorded at an abnormally high level (e.g., interquartile range). The interquartile multiplier is a parameter required for the interquartile range algorithm; the larger the value set, the wider the range of values ​​considered normal. Judgment criteria → Criteria to which the interquartile range algorithm is applied. Group Unit → Sets the unit of data used for anomaly detection.

[0034] For example, if "cluster and cost account" is set, the system compares values ​​within records of the same cluster and cost account to determine if an anomaly has occurred.

[0035] The Anomaly Detection Definition Master Table 11 is a table that manages the predefined information necessary when performing anomaly detection. As shown in Figure 3, this Anomaly Detection Definition Master Table 11 stores the definition ID, which is a unique identification number for each alert definition, as well as the description, algorithm, algorithm parameters, data acquisition definition ID, and result table.

[0036] The algorithm and algorithm parameters are the algorithm executed in the alert definition and the parameters used during execution. The results table is a table that stores the detection results calculated as a result of executing the algorithm.

[0037] Specifically, for the alert definition with definition ID "AB01", the "clustering" algorithm, which is designated as the similar construction clustering definition, is applied, and the calculation results are stored in the clustering results table 17. Similarly, for the alert definition with definition ID "AB02", the "rule-based" algorithm, which is designated as the scarcity cost calculation definition, is applied, and the calculation results are stored in the scarcity cost calculation results table 18. Similarly, for the alert definition with definition ID "AB03", the "interquartile range (upper tailed test)" algorithm, which is designated as the scarcity cost calculation definition, is applied, and the calculation results are stored in the anomaly judgment results table 19.

[0038] In other words, in the case of the business support device 1 of this embodiment, as shown in Figure 4, a series of algorithms are formed by combining a general-purpose algorithm for "clustering" of the definition ID "AB01", a general-purpose algorithm for "rule-based" analysis of the definition ID "AB02", and a general-purpose algorithm for "interquartile range" analysis of the definition ID "AB03".

[0039] Furthermore, the business support device 1 of this embodiment divides construction projects into similar groups by executing an alert definition using a general-purpose "clustering" algorithm, and extracts rare cost items by executing an alert definition using a general-purpose "rule-based" algorithm. In addition, the business support device 1 identifies construction projects with a large amount of rare cost items by executing an alert definition using a general-purpose "interquartile range" algorithm, and detects anomalies in the occurrence of rare construction costs among similar construction projects.

[0040] In other words, the business support device 1 of this embodiment forms an anomaly detection definition by combining simple (general) algorithms and executes each algorithm in a chain reaction to perform "automatic detection of anomalies in the occurrence of rare construction costs between similar construction projects."

[0041] Next, the Anomaly Detection Data Acquisition Definition Master Table 12 is a table that manages the pre-defined data used when performing anomaly detection. As shown in Figure 5, the Anomaly Detection Data Acquisition Definition Master Table 12 stores associated data acquisition definition IDs, data acquisition definition names, and stored procedure names (stored name), etc.

[0042] In the example shown in Figure 5, the data acquisition definition name for the data acquisition definition ID "D01" is "Construction Information Acquisition Definition," and the stored procedure name is "Construction Information Acquisition Stored Procedure." Similarly, the data acquisition definition name for the data acquisition definition ID "D02" is "Cluster-Specific Cost Composition Ratio Acquisition Definition," and the stored procedure name is "Cluster-Specific Cost Composition Ratio Acquisition Stored Procedure." Similarly, the data acquisition definition name for the data acquisition definition ID "D03" is "Construction-Specific Rare Cost Item Amount Acquisition Definition," and the stored procedure name is "Construction-Specific Rare Cost Item Amount Acquisition Stored Procedure."

[0043] Next, the stored parameter definition master table 13 is a table that manages the parameters of the stored procedures for the data used when performing abnormality detection. As shown in Figure 6, the stored parameter definition master table 13 stores associated information such as the data acquisition definition ID, a sequential number which is used as a row number to distinguish stored parameter definitions with the same data acquisition definition ID, the parameter name, the parameter type, and the value.

[0044] In the example shown in Figure 6, the stored parameter definition with data acquisition definition ID "D01" is a stored parameter definition for construction progress, with parameter type "fixed value" and value "completed". The stored parameter definition with data acquisition definition ID "D02" and sequence number "0" is also a stored parameter definition for construction progress, with parameter type "fixed value" and value "completed". Additionally, the stored parameter definition with data acquisition definition ID "D02" and sequence number "1" is a stored parameter definition for definition ID, with parameter type "fixed value" and value "AB01".

[0045] Additionally, the stored parameter definition with data acquisition definition ID "D03" and serial number "0" is the stored parameter definition for construction progress status, with parameter type "fixed value" and value "completed". Furthermore, the stored parameter definition with data acquisition definition ID "D03" and serial number "1" is the stored parameter definition for scarcity cost flag information, with parameter type "fixed value" and value "TRUE".

[0046] Furthermore, the stored parameter definition with data acquisition definition ID "D03" and serial number "2" is the stored parameter definition for the clustering definition ID, the parameter type is "fixed value", and the value is "AB01". Also, the stored parameter definition with data acquisition definition ID "D03" and serial number "3" is the stored parameter definition for the cost calculation definition ID, the parameter type is "fixed value", and the value is "AB02".

[0047] Next, Figure 7 shows the reference table, extraction conditions, and details for each stored procedure. As shown in Figure 7, the construction information acquisition stored procedure references the construction data table to acquire information on construction projects whose progress status is "completed".

[0048] Furthermore, the cluster-specific cost composition ratio acquisition stored procedure retrieves the latest execution history ID related to the specified definition ID from the execution history table, integrates (combines) the construction cost data from the construction cost data table 20 and the clustering result data from the clustering result table 17, and calculates and retrieves the cost composition ratio for each cluster for completed construction projects.

[0049] This means that the stored procedure for obtaining cost composition ratios by cluster, which is the next in the execution order of alert definitions, will perform calculations using the calculation result of the stored procedure for obtaining construction information that executed the previous alert definition as input.

[0050] Furthermore, the stored procedure for obtaining rare cost account amounts by project retrieves the latest execution history ID associated with the specified clustering definition ID and cost calculation definition ID from the execution history table 16, and integrates (combines) the construction cost data in the construction cost data table 21, the clustering result data in the clustering result table 17, and the rare cost calculation result data in the rare cost calculation result table 18. Then, the stored procedure for obtaining rare cost account amounts by project retrieves the amounts of completed projects that belong to the rare cost account within the cluster.

[0051] This means that the stored procedure for obtaining rare cost item amounts by construction project, which is the third in the execution order of the alert definition, will perform calculations using the calculation results of the stored procedure for obtaining construction information (which is the first in the execution order of the alert definition) and the calculation results of the stored procedure for obtaining cluster-specific cost composition ratios (which is the second in the execution order of the alert definition) as inputs.

[0052] In other words, in the case of the business support device of this embodiment, stored procedures formed with a general-purpose algorithm are executed sequentially and controlled, and the subsequent stored procedures use the calculation results of the preceding stored procedures as input to perform calculations.

[0053] Next, the schedule definition master table 14 is a table that manages the settings for the schedule that executes the anomaly detection. As shown in Figure 8, the schedule definition master table 14 stores the schedule definition ID, description, and conditions in association with each other. The example in Figure 8 shows that the schedule with schedule definition ID "SD01" is a schedule for detecting anomalies in rare cost items and is executed on the 5th business day of each month.

[0054] Next, the Anomaly Judgment Definition Schedule Mapping Master Table 15 is a table that manages the execution order of scheduled alert definitions (anomaly judgment definitions). As shown in Figure 9, this Anomaly Judgment Definition Schedule Mapping Master Table 15 indicates that the execution order of the alert definitions (anomaly judgment definitions) for each definition ID, "AB01", "AB02", "AB03", etc., whose execution schedules are managed under the schedule ID "SD01", is "1 (executed first)", "2 (executed second)", and "3 (executed third)", respectively.

[0055] Next, the execution history table 16 is a table that stores the execution history of alert definitions. As shown in Figure 10, this execution history table 16 stores associated information such as the execution history ID, execution history detail ID, definition ID of the executed alert definition, and the execution date and time of the executed alert definition.

[0056] Next, the clustering result table 17 is a table that stores clustering result data, which is the result of the clustering process that groups construction projects into desired groups. As shown in Figure 11, the clustering result table 17 stores associated information such as each execution history detail ID and row number of each execution history detail ID from the execution history table, the construction name, and the cluster to which the construction project belongs.

[0057] Next, the scarcity cost calculation results table 18 is a table that manages the cost composition ratio for each cluster of construction work and the result of whether or not it is a scarcity cost. As shown in Figure 12, this scarcity cost calculation results table 18 stores the execution history item ID and row number of each execution history item ID from the execution history table, the cluster to which it belongs, the cost account such as material costs or subcontracting costs, the cost amount, the cost composition ratio (%), and the scarcity cost flag, etc., in association with each other.

[0058] Next, the anomaly judgment result table 19 is a table that manages the anomaly judgment results for each construction project. As shown in Figure 13, this anomaly judgment result table 19 stores information such as each execution history detail ID, the row number of each execution history detail ID, the cluster to which it belongs, the name of the construction project for which an anomaly was judged, the cost account, the cost amount, the upper limit, and whether or not an anomaly was detected, all associated with each other.

[0059] Next, the construction data table 20 is a table that stores information about each construction project. As shown in Figure 14, this construction data table 20 stores associated information such as the project name, company name, department name, person in charge, payee name, supplier name, type of construction, construction period (months), contract amount, and construction progress status.

[0060] Next, the construction cost data table 21 is a table that stores the costs recorded for each construction project. As shown in Figure 15, this construction cost data table 21 stores the construction name, the cost accounting voucher number for which the cost was recorded, the cost accounting detail number (=line number), the recording date, the cost account, the cost amount, the product name, the detail remarks, and the transaction details, all associated with each other.

[0061] (Functional configuration of business support equipment) Next, the control unit 3 executes the business support program stored in the storage unit 2, and functions as a display control unit 31, execution unit 32, execution control unit 33, storage control unit 34, and data generation unit 35, as shown in Figure 1.

[0062] In this example, the display control unit 31 to the data generation unit 35 are described as being implemented in software based on a business support program, but all or part of the display control unit 31 to the data generation unit 35 may be implemented in hardware. In either case, the same effects as described later can be obtained.

[0063] The display control unit 31 displays an input screen for entering the schedule definition ID of the schedule definition set in the alert definition to be executed, via the output device 7, which is the display unit.

[0064] The data generation unit 35 generates various data to be stored in the various tables 11 to 21 and the various storage units 22, 24 to 26 described above.

[0065] The execution unit 32 executes multiple alert definitions, each using a different algorithm to analyze the data and detect anomalies (see Figure 21(a)).

[0066] The execution control unit 33 controls the execution unit 32 to execute each alert definition in the execution order assigned to each alert definition (see Figure 21(a)).

[0067] Furthermore, the execution control unit 33 uses the calculation results obtained by executing the alert definition in the previous execution order to control the execution unit so that the alert definition in the next order detects abnormal values ​​(see Figures 28 and 33).

[0068] The memory control unit 34 integrates (combines) the calculation results obtained by executing each alert definition and stores them in the memory unit (see Figures 30(d) and 35(d)).

[0069] Furthermore, the execution control unit 33 refers to the abnormality determination definition schedule mapping master table 15, which stores the definition identification number uniquely assigned to each alert definition and the execution order of each alert definition (see Figure 9), and controls the execution unit 32 to execute the corresponding alert definitions in the execution order.

[0070] (Decision-making process for scarce cost items in each cluster) Here, we will explain the process for determining rare cost items in each cluster. The applicant of the present invention has previously disclosed an invention in Japanese Patent Application No. 2024-039271, which is a business support device that determines rare cost items based on the cluster of each construction project that has undergone clustering processing. The business support device 1 of this embodiment also uses the same technology as the business support device of Japanese Patent Application No. 2024-039271 to determine rare cost items.

[0071] Specifically, as shown in Figure 11, similar construction projects are grouped together through clustering and classified into clusters such as Cluster A, Cluster B, etc. The control unit 3 of the business support device 1 in this embodiment calculates the cost composition ratio of each cost account for each cluster based on the construction cost data shown in Figure 15, and stores it in the cluster-specific cost composition ratio storage unit 22 shown in Figure 16(a).

[0072] As shown in Figure 16(b), the definition master table 11 for anomaly detection stores the ratio threshold for determining scarcity costs. In this example, the ratio threshold for determining scarcity costs is "1%". In contrast, the cost account for "miscellaneous expenses" shown in Figure 16(a) has a cost composition ratio of "0.4%", which is less than or equal to the ratio threshold for determining scarcity costs of "1%". The control unit 3 determines that a cost composition ratio that is less than or equal to the ratio threshold for determining scarcity costs is a scarcity cost account.

[0073] (Calculation process for the cost amount of rare cost items for each construction project in each cluster) Next, the calculation process for the cost amount of rare cost items for each construction project in each cluster will be explained. The business support device 1 of the embodiment uses the same technology as the business support device in Japanese Patent Application No. 2024-039271, which was previously filed by the applicant of the present invention, to calculate the cost amount of the rare cost items determined as described above.

[0074] Note that rare cost items may differ from cluster to cluster. Also, for clusters where rare cost items do not exist, the calculation of the cost amount for rare cost items described below will not be performed (the cost amount calculation process will be skipped).

[0075] First, as shown in Figures 17(a) and 17(b), the control unit 3 detects from the cluster-specific cost composition ratio storage unit 22 the cost composition ratio of cost accounts in the same cluster that is less than or equal to the "1%" threshold for determining scarce costs (in this example, the cost composition ratio of miscellaneous expenses (=0.4%)).

[0076] Next, as shown in Figure 18, the control unit 3 detects records in the construction cost data table 21 in which rare cost items of "miscellaneous expenses" have a cost composition ratio below the threshold for determining rare costs. Then, as shown in Figure 19, the control unit 3 aggregates the cost amounts of the rare cost items of "miscellaneous expenses" detected from the construction cost data table 21.

[0077] (Anomaly detection operation) In this way, once the cost amount for the rare cost items for each construction project in each cluster is calculated, several algorithms are executed sequentially based on this cost amount, as shown below, to detect business data showing anomalies.

[0078] (Execution of the algorithm that is first in the execution order) In other words, the business operator inputs the desired schedule definition ID via the data acquisition parameter input screen shown in Figure 20(a), which is displayed by the display control unit 31. The example in Figure 20(a) shows an example where the schedule definition ID "SD01" is entered.

[0079] Next, as shown in Figure 20(b), the execution control unit 33 refers to the schedule definition master table 14 and detects the conditions associated with the specified schedule definition ID "SD01". In this example, the condition is "5 business days per month". Therefore, the execution control unit 33 checks whether the timing for anomaly detection is "5 business days or not".

[0080] If the timing for anomaly detection corresponds to "5 business days" (i.e., the condition is met), the execution control unit 33 refers to the anomaly judgment definition schedule mapping master table 15 based on the schedule definition ID, as shown in Figure 20(c), and detects the definition ID of the alert definition to be executed (the definition ID of the algorithm to be executed) and the execution order, as shown in Figure 20(d).

[0081] If the timing for detecting an anomaly does not correspond to "5 business days" (i.e., the condition is not met), the execution control unit 33 will terminate processing without detecting an anomaly.

[0082] Next, as shown in Figure 21(a), once the execution order of each alert definition is recognized, the execution control unit 33, in order to execute the algorithm of the first alert definition, as shown in Figure 21(b), refers to the anomaly determination definition master table 11 based on the definition ID "AB01", as shown in Figure 21(c), and recognizes the algorithm of the alert definition to be executed, the algorithm parameters, the data acquisition definition ID, and the result table that stores the calculation results.

[0083] In this example, the first algorithm to be executed is the "clustering" algorithm, and the result table used to store the calculation results is named "Clustering Result Table 17".

[0084] Next, the execution control unit 33, based on the data acquisition definition ID "D01" in the abnormality determination definition master table 11 shown in Figure 22(a), refers to the abnormality determination data acquisition definition master table 12 and the stored parameter definition master table 13, as shown in Figures 22(b) and 22(c). The execution control unit 33 then recognizes the stored name of the "construction information acquisition stored procedure," the parameter name of "construction progress status," the parameter type of "fixed value," and the value of "completed."

[0085] Furthermore, the reference table, extraction conditions, and details of the construction information retrieval stored procedure are pre-configured as shown in Figure 22(d). The settings for this construction information retrieval stored procedure refer to the construction data table 20 and, as shown in Figure 23, extract construction data where the construction progress status is "completed," which is the extraction condition.

[0086] Next, as shown in Figure 24(a), the execution control unit 33 controls the execution unit 32 to execute the "clustering" algorithm, which has the "1st" execution order, based on the algorithm parameters recognized from the abnormality determination definition master table 11.

[0087] In this example, "construction type," "contract amount," and "construction period" are set as algorithm parameters. Therefore, as shown in Figure 24(b), the execution unit 32 refers to the "construction type," "contract amount," and "construction period" of the construction data whose construction progress status is "completed," and as shown in Figure 24(c), it generates clustering processed data with standardized "contract amount" and "construction period" for each of the same construction types, such as construction type A and construction type B, and stores it in the clustering processed data storage unit 26.

[0088] Next, the execution unit 32, based on the algorithm parameters shown in Figure 24(a), generates calculation results that assign each construction project to a total of four clusters: type A, type B, type C, and type D, as shown in Figure 24(d), since the algorithm parameter for the number of clusters is "4".

[0089] Next, the execution unit 32 stores the execution history data, including the definition ID and execution date and time of "AB01" stored in the anomaly determination definition master table 11 shown in Figure 25(a), which corresponds to the first algorithm (clustering process) executed this time, in the execution history table 16 as shown in Figure 25(b). Note that the execution history ID (EH01) and execution history detail ID (EHM101) of the execution history data are automatically assigned and added by the control unit 3 when the execution history data is stored.

[0090] Next, the execution unit 32 stores the calculation result of the current clustering process shown in Figure 25(c), along with the execution history detail ID (EHM101) and row number of the current execution history data, in the clustering result table 17, which is stored as the "result table" in the abnormality determination definition master table 11 shown in Figure 25(a), as shown in Figure 25(d) (updating the previous clustering result with the new clustering result). This completes the execution of the "clustering" algorithm, which is the first algorithm to be executed.

[0091] (Execution of the second algorithm in the execution order) Next, the business operator enters the definition ID of the alert definition that will be executed in the "2nd" order via the data acquisition parameter input screen shown in Figure 26(a), which is displayed by the display control unit 31. The example in Figure 26(a) shows an example where the definition ID "AB02" has been entered.

[0092] Next, the execution control unit 33, based on the input definition ID "AB02", refers to the anomaly determination definition master table 11 shown in Figure 26(b) and recognizes the algorithm, algorithm parameters, data acquisition definition ID, and result table for storing the alert definition to be executed.

[0093] In this example, the second algorithm to be executed is a "rule-based" algorithm, and the result table used to store the calculation results is "Scarcity Cost Calculation Result Table 18".

[0094] Next, the execution control unit 33, based on the data acquisition definition ID "D02" in the anomaly determination definition master table 11 shown in Figure 27(a), refers to the anomaly determination data acquisition definition master table 12 and the stored parameter definition master table 13, as shown in Figures 27(b) and 27(c). The execution control unit 33 then recognizes the stored procedure name (stored name), parameter name, parameter type, and value. In this example, the stored name is "Cluster-specific cost composition ratio acquisition stored procedure".

[0095] Here, as shown in Figure 27(c), the parameter names, parameter types, and values ​​for the stored procedure for obtaining the cost composition ratio by cluster are as follows:

[0096] Data acquisition definition ID "D02" row number "0" → Construction progress status, fixed value, completed Data acquisition definition ID "D02" row number "1" → Definition ID, fixed value, AB01

[0097] Furthermore, as shown in Figure 28, the stored procedure for obtaining the cost composition ratio by cluster is configured to refer to the construction data table 20, the construction cost data table 21, the clustering results table 17, and the execution history table 16.

[0098] Furthermore, the stored procedure for obtaining cost composition ratios by cluster is configured to extract completed construction data from the construction data table 20, as shown in Figure 28, and to obtain the clustering result data from the clustering result table 17 for the latest execution history detail ID with definition ID "AB01" (in the example of Figure 25(d), the execution history detail ID is "EHM101").

[0099] Furthermore, as shown in Figure 28, the stored procedure for obtaining the cost composition ratio by cluster is configured to retrieve the latest execution history detail ID from the execution history table 16, integrate (join) the construction cost data table 21 and the clustering result table 17, and calculate and retrieve the cost composition ratio for each cluster for construction projects whose progress status is "completed".

[0100] This setting means that the result of the first calculation is used as input for the second stored procedure, which retrieves the cost breakdown ratio by cluster.

[0101] In other words, the stored procedure for obtaining cost composition ratios by cluster retrieves the cost amounts for each cost account, such as material costs, labor costs, subcontracting costs, and miscellaneous expenses, for each project clustered by the first algorithm (cluster A, cluster B, cluster C, etc.) from the project cost data table 21 shown in Figure 15.

[0102] The cluster-specific cost composition ratio acquisition stored procedure calculates the ratio of the cost amount of each cost account to the total cost amount obtained by adding up the acquired cost amounts of material costs, labor costs, subcontracting costs, and miscellaneous expenses, as the "cost composition ratio (%)", and stores it in the class-specific cost composition ratio storage unit 22, as shown in Figure 27(d).

[0103] Cost composition ratio (%) = ((Cost amount of each cost account) ÷ (Cost amount of materials + Cost amount of labor + Cost amount of subcontracting + Cost amount of miscellaneous expenses)) × 100

[0104] Next, as shown in Figure 29(a), the execution unit 32 refers to the anomaly detection definition master table 11 and recognizes the algorithm parameters set for such a "rule-based" algorithm. In this example, the execution unit 32 recognizes that the algorithm parameter "cost composition ratio is 1% or less" is set as a "condition".

[0105] Next, as shown in Figure 29(b), the execution unit 32 refers to the class-specific cost composition ratio storage unit 22 and detects cost accounts whose cost composition ratio is "1% or less" to determine whether the cost amount recorded for that cost account is a scarce cost.

[0106] In this example, the cost amounts for materials, labor, and outsourcing are greater than "1%" of the total cost. In this case, the execution unit 32 determines that the cost amounts for materials, labor, and outsourcing are not scarce costs (FALSE). In contrast, the cost amount for miscellaneous expenses is less than or equal to "1%" of the total cost. In this case, the execution unit 32 determines that the cost amount for miscellaneous expenses is a scarce cost (TRUE).

[0107] The execution unit 32 stores the results of the determination of scarcity costs for each cost amount of each cost account as scarcity cost flag information in the cluster-specific cost composition ratio storage unit 22, as shown in Figure 29(c). In this example, scarcity cost flag information of "FALSE" indicating that it is not a scarcity cost is attached to the cost amounts of material costs, labor costs, and outsourcing costs, while scarcity cost flag information of "TRUE" indicating that it is a scarcity cost is attached to the cost amount of miscellaneous expenses. This makes it possible to detect the cost amount of miscellaneous expenses as an outlier.

[0108] Next, the execution unit 32 stores the execution history data, including the definition ID and execution date and time of "AB02" stored in the anomaly detection definition master table 11 shown in Figure 30(a), which corresponds to the second algorithm (scarcity cost calculation process) executed this time, in the execution history table 16, as shown in Figure 30(b).

[0109] Furthermore, the execution history ID (EH01) in the execution history data is the same as that of the first algorithm (EH01) as the first algorithm, because the first algorithm and the second algorithm in question are executed consecutively (a series of algorithms), and are stored in the execution history table 16. In contrast, the execution history detail ID is "EHM102" to indicate that it is the execution history of the second algorithm, and the definition ID is "AB02" to indicate that it is the definition ID of the alert definition for the second algorithm.

[0110] Next, the execution unit 32 stores the calculation result of the current scarcity cost calculation process shown in Figure 30(c), along with the execution history detail ID (EHM102) and row number of the current execution history data, in the scarcity cost calculation result table 18, which is stored as the "result table" in the abnormality determination definition master table 11 shown in Figure 30(a), as shown in Figure 30(d) (the result of the previous scarcity cost calculation process is updated with the result of the new scarcity cost calculation process). With this, the algorithm of the "scarcity cost calculation process," which is the second algorithm to be executed, is completed.

[0111] (Execution of the third algorithm in the execution order) Next, the business operator enters the definition ID of the alert definition that will be executed in the "3rd" order via the data acquisition parameter input screen shown in Figure 31(a), which is displayed by the display control unit 31. The example in Figure 31(a) shows an example where the definition ID "AB03" has been entered.

[0112] Next, the execution control unit 33 refers to the anomaly determination definition master table 11 shown in Figure 31(b) based on the input definition ID "AB03", and recognizes the algorithm, algorithm parameters, data acquisition definition ID, and result table for storing the alert definition to be executed.

[0113] In this example, the third algorithm to be executed is the "interquartile range (upper tailed test)" algorithm, and the result table where the calculation results are stored is "anomaly detection result table 19".

[0114] Next, the execution control unit 33, based on the data acquisition definition ID "D03" in the anomaly determination definition master table 11 shown in Figure 32(a), refers to the anomaly determination data acquisition definition master table 12 and the stored parameter definition master table 13, as shown in Figures 32(b) and 32(c). The execution control unit 33 then recognizes the stored procedure name (stored name), parameter name, parameter type, and value. In this example, the stored name is "Stored Procedure for Acquiring Scarce Cost Amount by Construction Project".

[0115] Here, as shown in Figure 32(c), the parameter names, parameter types, and values ​​for the stored procedure for obtaining the amount of rare cost items by construction project are as follows:

[0116] Data acquisition definition ID "D03", row number (sequential number) "0" → Construction progress status, fixed value, completed Data acquisition definition ID "D03" row number "1" → Scarcity cost flag, fixed value, TRUE Data acquisition definition ID "D03" row number "2" → Clustering definition ID, fixed value, AB01 Data acquisition definition ID "D03" row number "3" → Cost calculation definition ID, fixed value, AB02

[0117] This indicates that when the stored procedure for obtaining rare cost item amounts by project is executed, the project data table 20, project cost data table 21, clustering results table 17, rare cost calculation results table 18, and execution history table 16 are referenced, as shown in Figure 33.

[0118] Furthermore, by referring to the construction data table 20, construction data with a "completed" status is obtained, and by referring to the scarcity cost calculation result table 18, cost accounts with the scarcity cost flag information set to "TRUE" are obtained.

[0119] Furthermore, by referring to clustering result table 17, it is shown that the clustering result data for the latest execution history detail ID (in the example of Figure 25(d), the execution history detail ID "EHM101") obtained by executing the construction information acquisition stored procedure, which is an algorithm with definition ID "AB01".

[0120] Furthermore, by referring to the scarcity cost calculation results table 18, the clustering result data of the latest execution history detail ID (in the example of Figure 30(d), the execution history detail ID "EHM102") obtained by executing the cluster-specific cost composition ratio acquisition stored procedure, which is an algorithm with definition ID "AB02".

[0121] In other words, as shown in Figure 33, the stored procedure for obtaining rare cost amounts by construction project retrieves the latest execution history ID related to the specified clustering definition ID and cost calculation definition ID from the execution history table 16, integrates the construction cost data table 21, the clustering result table 17, and the rare cost calculation result table 18, and retrieves the cost amounts of cost accounts identified as rare costs from each cluster, as shown in Figure 32(d). Then, among the retrieved cost amounts for each cluster, cost amounts that are above the upper threshold amount and cost amounts that are below the lower threshold amount are identified as outliers.

[0122] The operation of this stored procedure for obtaining rare cost amounts by construction project means that the results of the first and second calculations are used as inputs to the third stored procedure for obtaining rare cost amounts by construction project, respectively.

[0123] Next, as shown in Figure 34(a), the execution unit 32 refers to the anomaly detection definition master table 11 and recognizes the algorithm parameters set for this "interquartile range (upper tailed test)" algorithm. In this example, the execution unit 32 recognizes that the "judgment item" is "cost amount", the group unit is "the unit of cost account for each cluster", and the "interquartile range multiplier" is "1.5 times".

[0124] Next, as shown in Figure 34(b), the execution unit 32 refers to the construction-specific rare cost account cost amount storage unit 24 and retrieves the cost amount of the cost account "miscellaneous expenses," which is a rare cost account detected by executing the cluster-specific cost composition ratio acquisition stored procedure described above, for each construction project in the same cluster.

[0125] Next, the execution unit 32 determines whether the cost amount of miscellaneous expenses for each construction project is equal to or greater than the upper threshold of "12,000 yen", and whether the cost amount of miscellaneous expenses for each construction project is equal to or less than the lower threshold of "4,000 yen".

[0126] In the example shown in Figure 34(b), the cost amount of "100,000 yen" recorded for construction work A exceeds the upper threshold of "12,000 yen". In this case, the execution unit 32 detects the cost amount of "100,000 yen" recorded for construction work A as an abnormal value. The other cost amounts are normal values.

[0127] When the execution unit 32 detects an abnormal value in the cost amount for each construction project in each cluster, as shown in Figure 34(c), the rare cost item cost amount storage unit 24 for each construction project adds an "abnormal" judgment result to construction project A in cluster A, and a "normal" judgment result to the other construction projects. This makes it possible to identify the construction project that recorded an abnormal cost amount among the miscellaneous expenses recorded for each construction project.

[0128] Next, the execution unit 32 stores the execution history data, including the definition ID and execution date and time of "AB03" stored in the anomaly determination definition master table 11 shown in Figure 35(a), which corresponds to the third algorithm (anomaly determination process) executed this time, in the execution history table 16, as shown in Figure 35(b).

[0129] Furthermore, the execution history ID (EH01) of the execution history data is the same as that of the first algorithm, as the execution history ID (EH01) is added to the execution history table 16, because the first algorithm to the third algorithm described above are executed consecutively (a series of algorithms). In contrast, the execution history detail ID is "EHM103" to indicate that it is the execution history of the third algorithm, and the definition ID is "AB03" to indicate that it is the definition ID of the alert definition for the third algorithm.

[0130] Next, the execution unit 32 stores the calculation result of the current abnormality judgment process shown in Figure 35(c), along with the execution history detail ID (EHM103) and row number of the current execution history data, in the abnormality judgment result table 19, which is stored as the "result table" in the abnormality judgment definition master table 11 shown in Figure 35(a), as shown in Figure 35(d) (the calculation result of the previous abnormality judgment process is updated with the calculation result of the new abnormality judgment process). As a result, the algorithm of the "abnormality judgment process," which is the third algorithm in the execution order, is completed.

[0131] (Effects of the embodiment) As is clear from the above description, the business support device 1 of the embodiment assigns a desired execution order to a plurality of general-purpose algorithms and executes them in the assigned execution order. This makes it possible to detect abnormal values ​​in data with high detection accuracy while using general-purpose algorithms.

[0132] In other words, as shown in Figure 36, one general-purpose algorithm (simplified algorithm) is set for each alert definition, a schedule definition is created that manages multiple alert definitions and their execution order, and each alert definition is executed in the order it is executed. At this time, the detection result of each alert definition is stored in the memory unit, and the output of the previous algorithm is used as the input to the next algorithm.

[0133] This allows for the generation of complex algorithmic alert definitions using general-purpose algorithms, and because multiple algorithms are combined and executed in the desired order, it enables the detection of data anomalies with highly accurate alert definitions. In other words, it achieves both versatility and ease of use, as well as the realization of complex algorithms with high detection accuracy.

[0134] [Contribution to the United Nations-led Sustainable Development Goals (SDGs)] This invention can contribute to improving operational efficiency and promoting appropriate management decisions by companies, and therefore can contribute to SDGs Goals 8 and 9.

[0135] Furthermore, this invention can contribute to reducing waste and promoting paperless and digital processes, thereby contributing to SDGs Goals 12, 13, and 15.

[0136] Furthermore, this invention can contribute to strengthening control and governance, and therefore can contribute to achieving the 16 goals of the SDGs.

[0137] [Other embodiments] The present invention can be implemented in various different forms within the scope of the technical idea described in the claims, even in embodiments other than those described above.

[0138] For example, among the processes described in the embodiments, all or part of the processes described as being performed automatically may be performed manually. Alternatively, all or part of the processes described as being performed manually may be performed automatically by known methods or the like.

[0139] Furthermore, unless otherwise specified, the processing procedures, control procedures, specific names, registration data for each process, information including parameters such as search conditions, screen examples, and database configuration shown in the specification or drawings can be arbitrarily changed.

[0140] Furthermore, with respect to the business support device 1, each component shown in the diagram is a functional concept and does not necessarily have to have the physical configuration shown. For example, the processing functions of the business support device 1, particularly the processing functions performed by the control unit 3, may be implemented in whole or in any part by a program interpreted and executed by the control unit 3 (CPU: Central Processing Unit), or by hardware using wired logic.

[0141] The program is recorded on a non-temporary, computer-readable recording medium containing programmed instructions for the information processing device to execute the processes described in the embodiment, and is mechanically read by the business support device 1 as needed. In other words, the storage unit 2, such as ROM or HDD, records a computer program that works in cooperation with the OS (Operating System) to give instructions to the control unit 3 (CPU) and perform various processes. This computer program is loaded into RAM, unpacked, and executed by the control unit 3 as appropriate.

[0142] Furthermore, the business support program for this business support device 1 may be stored on another server device connected to the business support device 1 via any network, and all or part of it may be downloaded and executed as needed.

[0143] Furthermore, the business support program for executing the processes described in the embodiment may be stored on a non-temporary computer-readable recording medium, or it may be configured as a program product.

[0144] Here, any "portable physical medium" can be used as the "recording medium," such as memory cards, USB (Universal Serial Bus) memory, SD (Secure Digital) cards, flexible disks, magneto-optical disks, ROMs, EPROMs (Erasable Programmable Read Only Memory), EEPROMs (Registered Trademark) (Electrically Erasable and Programmable Read Only Memory), CD-ROMs (Compact Disk Read Only Memory), MOs (Magneto-Optical Disks), DVDs (Digital Versatile Disks), and Blu-ray (Registered Trademark) Discs.

[0145] Furthermore, "program" refers to a data processing method written in any language or writing method, regardless of whether it is source code or binary code.

[0146] Furthermore, the term "program" is not necessarily limited to a single, monolithic entity, but also includes those that are distributed as multiple modules or libraries, and those that work in cooperation with other programs, such as an operating system, to achieve their functions.

[0147] Furthermore, for the specific configuration, reading procedure, and post-reading installation procedure for the business support device 1 of the embodiment, well-known configurations or procedures can be used.

[0148] The storage unit 2 is a storage means such as memory devices like RAM and ROM, fixed disk devices like hard disks, flexible disks, and optical disks, and stores various programs, tables, databases, and web page files used for various processing or website provision.

[0149] Furthermore, the business support device 1 may be composed of a known personal computer device or an information processing device such as a workstation, or it may be composed of an information processing device to which any peripheral devices are connected. In addition, the information processing device may be implemented by implementing software (including programs or data, etc.) that realizes the processing described in the embodiment.

[0150] Furthermore, the specific forms of distribution and integration of the devices are not limited to those shown in the figures, and all or part of them can be configured by functionally or physically distributing or integrating them in any unit according to various additions or functional loads. In other words, the embodiments described above can be selectively implemented by arbitrarily combining the embodiments described above. [Industrial applicability]

[0151] This invention is particularly suitable for application to an anomaly detection system that detects abnormal values ​​in various types of data. [Explanation of Symbols]

[0152] 1 Business support equipment 2 Storage section 3. Control Unit 4. Communication Interface Section 5 Input / Output Interface Section 6 Input devices 7 Output device 11. Master table for defining abnormalities 12. Master table for defining data acquisition for anomaly detection. 13. Stored Parameter Definition Master Table 14. Schedule Definition Master Table 15 Anomaly detection definition schedule mapping master table 16 Execution History Table 17. Clustering Result Table 18. Scarcity Cost Calculation Results Table 19 Anomaly detection result table 20 Construction Data Table 21 Construction Cost Data Table 22. Cluster-specific cost composition ratio storage unit 24. Cost Amount Storage for Rare Cost Items by Construction Project 25 Execution Definition Information Storage Unit 26. Processing data storage unit for clustering 31 Display Control Unit 32 Execution Department 33 Execution Control Unit 34 Memory Control Unit 35 Data Generation Unit 50 Networks 51 Field Terminal Device

Claims

1. An execution unit that executes multiple alert definitions, each using a different algorithm to analyze data and detect anomalies, An execution control unit controls the execution unit to execute each of the aforementioned alert definitions in the execution order assigned to each of the aforementioned alert definitions, A business support device having the following features.

2. The execution control unit uses the calculation results obtained by executing the alert definition in the previous execution order to control the execution unit so that the alert definition in the next order detects the abnormal value. The business support device according to claim 1, characterized by the following:

3. The system further includes a storage control unit that integrates the calculation results obtained by executing each of the aforementioned alert definitions and stores them in the storage unit. The business support device according to claim 2, characterized by the following:

4. The execution control unit refers to an anomaly determination definition schedule mapping master table which stores a definition identification number uniquely assigned to each alert definition and the execution order of each alert definition, and controls the execution unit to execute the corresponding alert definitions in the execution order. A business support device according to any one of claims 1 to 3, characterized by the above.

5. The execution unit performs an execution step in which it executes multiple alert definitions that analyze data using different algorithms to detect anomalies, An execution control step in which the execution control unit controls the execution unit to execute each of the alert definitions in the execution order assigned to each of the alert definitions, A business support method that has the following characteristics.

6. Computers, An execution unit that executes multiple alert definitions, each using a different algorithm to analyze data and detect anomalies, The execution control unit controls the execution unit to execute each of the alert definitions in the execution order assigned to each of the alert definitions. A business support program designed to function as such.

Images