Enterprise resource management platform based on cloud computing

Abstract

The invention relates to the technical field of enterprise resource management, in particular to an enterprise resource management platform based on cloud computing, which comprises a data acquisition and storage module for acquiring and storing internal and external resource data; the classification module dynamically divides the data into high / low mobility data according to the data change frequency and the number of interaction events in a resource preset period in combination with a mobility threshold value; the strategy execution module implements differential monitoring accordingly; the evaluation module aggregates the monitoring data, calculates a resource flow efficiency value and an asset safety stability value through an algorithm, and generates a health degree index through weighted fusion; according to the invention, through linkage of resource mobility dynamic classification and differential monitoring strategies, a closed-loop system with self-sensing, intelligent analysis and automatic optimization is constructed, the management refinement and intelligence level is improved, business efficiency and asset security unification is realized, and the management efficiency is improved. And core support is provided for digital transformation of enterprises.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of enterprise resource management, in particular to an enterprise resource management platform based on cloud computing. BACKGROUND

[0002] With the deepening of the digitalization process of enterprises, cloud computing has become the core infrastructure of enterprise resource planning (ERP). Modern enterprise resources are complex, including not only high-frequency dynamic assets such as computing resources and transaction streams, but also relatively static but crucial financial assets and configuration information. Under this background, the traditional enterprise resource management platform has the following limitations: On the one hand, the monitoring strategy is rigid and the resource utilization efficiency is low: most existing platforms use a "one-size-fits-all" monitoring and management strategy, which cannot distinguish between high-liquidity resources (such as cloud computing instances and business transactions) and low-liquidity resources (such as historical financial data and archived files). The monitoring granularity of the former is insufficient, which makes it impossible to real-time insight into performance bottlenecks and business opportunities; for the latter, high-frequency monitoring results in unnecessary computing overhead and cost waste.

[0003] On the other hand, the management goal is single and it is difficult to balance efficiency and security: traditional solutions often focus on resource utilization efficiency or cost control, but lack systematic monitoring of the security and compliance status of low-liquidity resources. This makes it difficult for the platform to comprehensively measure the overall "health" of the enterprise resource ecosystem, and managers cannot effectively protect the stability and security of core assets while improving business agility.

[0004] In addition, the management closed loop is missing and the regulation relies on manual decision-making: most systems only stay at the data monitoring and display level, lacking an automated feedback adjustment mechanism based on comprehensive evaluation results. Resource allocation, process approval and other decisions still require manual intervention, which is slow and cannot meet the real-time and intelligent management needs of modern enterprises.

[0005] In view of the above, an enterprise resource management platform based on cloud computing is proposed. SUMMARY

[0006] The purpose of the present application is to provide an enterprise resource management platform based on cloud computing to solve the problems of rigid monitoring strategy, low resource utilization efficiency, difficulty in balancing efficiency and security, and reliance on manual decision-making for regulation.

[0007] To solve the above technical problems, the present application provides an enterprise resource management platform based on cloud computing, comprising: a data acquisition and storage module for acquiring enterprise resource data from various internal and external data sources in real time and storing the data; The classification module is connected with the data collection and storage module, and is configured to classify enterprise resource data into high liquidity resource data and low liquidity resource data based on a preset liquidity threshold according to a data change frequency and a number of interaction events of each resource within a preset period, and output a classification marking result. The policy execution module is connected with the classification module, and is configured to receive the classification marking result and execute a corresponding monitoring policy according to the classification marking result: implementing high-frequency data collection and state monitoring on the high-liquidity resource data marked as high-liquidity resource data, and implementing low-frequency security and compliance monitoring on the low-liquidity resource data marked as low-liquidity resource data. The evaluation module is connected with the policy execution module, and is configured to receive and aggregate monitoring data from the policy execution module, calculate a resource flow efficiency value based on the monitoring data of the high-liquidity resource data by a first algorithm, calculate an asset security stability value based on the monitoring data of the low-liquidity resource data by a second algorithm, and generate a health degree index by weighted fusion of the flow efficiency value and the security stability value. The adjustment module is connected with the evaluation module, and is configured to receive the health degree index and match the health degree index with a pre-defined health degree interval in a policy rule library, and issue a corresponding regulation instruction to a resource management execution unit according to a matching result.

[0008] As a further improvement of the technical solution, the enterprise resource data includes usage data of cloud computing infrastructure resources, transaction data of business application systems, and financial asset data.

[0009] As a further improvement of the technical solution, the classification module includes: The resource activity index calculation unit is configured to calculate a data change frequency and a number of interaction events of each resource within a preset period; the number of interaction events refers to the number of operation event records of resource creation, modification, deletion, access or invocation; The liquidity threshold comparison unit is connected with the resource activity index calculation unit, and is configured to compare the calculated data change frequency and the number of interaction events with a preset liquidity threshold; The resource classification marking unit is connected with the liquidity threshold comparison unit, and is configured to mark the resource as high-liquidity resource data or low-liquidity resource data according to a comparison result.

[0010] As a further improvement of the technical solution, the policy execution module includes: The high-frequency fine monitoring unit, in response to the high-flowability resource data marked, is used for initiating a data request to a monitoring interface of the data collection storage module at a first preset frequency, and comparing the collected real-time data with a baseline value dynamically calculated based on historical data, and generating a warning log when the deviation exceeds a dynamic threshold; the first preset frequency is a high frequency, configured to perform data collection once every 10 seconds to 5 minutes; The low-frequency safety monitoring unit, in response to the low-flowability resource data marked, is used for at least one operation of calling an API interface of an identity management and access control system to check permissions, comparing resource configurations with a safety baseline template, and querying a qualification database for validity, at a second preset frequency; the second preset frequency is a low frequency, configured to perform a safety compliance check once every 24 hours or every week.

[0011] As a further improvement of the technical solution, in the evaluation module, The first algorithm is: the flow efficiency value = turnover rate x utilization rate; wherein the turnover rate is the number of times of successful calls of the high-flowability resource data per unit time, and the utilization rate is the ratio of the actual usage amount of the high-flowability resource data to the total allocation amount; The second algorithm is: the safety stability value = (1-safety event occurrence rate) x compliance state score; wherein the safety event occurrence rate is the ratio of the number of safety alarms triggered by the low-flowability resource data to the total number of resources in a preset period, and the compliance state score is a percentage score obtained by comparing the resource configuration with the safety policy template; The weighted fusion is: the health degree index = α x flow efficiency value + β x safety stability value, wherein α and β are preset weight coefficients, and α + β = 1.

[0012] As a further improvement of the technical solution, the adjustment module comprises: A policy rule library is used for storing a set of resource regulation instructions corresponding to different health degree index intervals; An instruction triggering unit is connected with the policy rule library and the evaluation module, and is used for matching the received health degree index with the intervals in the policy rule library, and outputting the matched set of resource regulation instructions; A resource scheduling execution module is connected with the instruction triggering unit, and is used for receiving the set of regulation instructions, and sending the instructions in the set of regulation instructions to the resource management execution unit.

[0013] As a further improvement of the technical solution, the pre-defined rules in the policy rule library include: triggering a first regulation instruction set when the health degree index is lower than a preset low health threshold value; and triggering a second regulation instruction set when the health degree index is higher than a preset high health threshold value; wherein the low health threshold value is lower than the high health threshold value. The first set of control instructions includes sending instructions to the enterprise's workflow engine to increase the approval nodes and / or approval personnel levels in the high-mobility resource data application process; The second set of control instructions includes modifying the resource scheduling policy configuration file of the cloud computing infrastructure layer to increase the virtual resource quota or priority weight of the marked high-efficiency business units. The high-efficiency business units are units identified from the business modules managed by the platform based on one or more preset business performance indicators. The business performance indicators include the business module's operating revenue, profit contribution, transaction throughput, service response time, resource utilization efficiency, or any combination thereof.

[0014] As a further improvement to this technical solution, the platform also includes a visual collaborative decision-making module, which is connected to the classification module, strategy execution module, and evaluation module respectively. It is used to graphically display the real-time dynamic data of high-liquidity resource data, the security status overview of low-liquidity resource data, and the changing trends of resource ecological health indicators.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This cloud-based enterprise resource management platform, by introducing a dynamic classification mechanism based on resource liquidity and a corresponding differentiated monitoring strategy, constructs a closed-loop enterprise resource management system capable of self-awareness, intelligent analysis, and automatic optimization. This fundamentally improves the refinement, intelligence, and overall efficiency of enterprise resource management, achieving a unified goal of business efficiency and asset security, and providing core support for the high-quality digital transformation of enterprises.

[0016] 2. In this cloud-based enterprise resource management platform, resources are dynamically classified into "high / low liquidity" through a classification module, enabling the policy execution module to "prescribe the right medicine." High-liquidity resources are monitored frequently and with fine granularity, ensuring the real-time visibility of critical business data. Low-liquidity resources are switched to a low-frequency, security-focused monitoring mode, which significantly reduces the system's ineffective computing load, saves cloud computing costs, and achieves optimal configuration of monitoring resources.

[0017] 3. In this cloud-based enterprise resource management platform, the evaluation module calculates the "resource flow efficiency value" through the first algorithm and the "asset security and stability value" through the second algorithm, and finally integrates them into a unified "health index". This breaks the traditional evaluation system where efficiency and security are separated, and provides enterprise decision-makers with a comprehensive, intuitive and quantifiable management dashboard to support their scientific decision-making.

[0018] 4. In this cloud-based enterprise resource management platform, the adjustment module can automatically match health indicators with the preset rule base and directly issue control instructions to the resource management execution unit (such as automatically adjusting the approval process and optimizing resource quotas), freeing managers from tedious daily monitoring and manual operation, greatly improving management response speed, and realizing the transformation from "passive response" to "proactive early warning and automatic optimization". Attached Figure Description

[0019] Figure 1 This is an overall system block diagram of the present invention; Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. Example 1

[0021] Traditional enterprise resource management platforms employ a "one-size-fits-all" monitoring strategy, which fails to distinguish between high-liquidity and low-liquidity resources. This results in insufficient granularity in monitoring high-liquidity resources (e.g., the inability to capture peak fluctuations in business transactions in real time) and excessive monitoring of low-liquidity resources (e.g., high-frequency collection of historical financial data leading to a waste of computing resources). At the same time, they lack an automated adjustment mechanism based on comprehensive evaluation, and management decisions rely on manual processes, resulting in slow response times and difficulty in balancing business efficiency and asset security. In view of this, please refer to Figure 1 As shown, the purpose of this invention is to provide a cloud-based enterprise resource management platform, which includes: The data acquisition and storage module is used to collect and store enterprise resource data in real time from various internal and external data sources; its specific structure is as follows: The data acquisition and storage module employs a distributed acquisition framework combining Flink and Kafka to collect and store enterprise resource data in real time from various internal and external data sources. Internal data sources include the financial module of the enterprise ERP system (such as SAPS / 4HANA), approval flow data of the OA system, and the transaction system of the business middle platform. External data sources include transaction callback data from third-party payment platforms (such as Alipay and WeChat Pay) and API data on ECS instance usage from cloud computing service providers (Alibaba Cloud). By configuring data source connection parameters (such as database IP, port, account password, API key, and request frequency), the data acquisition and storage module achieves a data acquisition capability of more than 1,000 records per second. The storage stage adopts a hybrid storage architecture, storing high-frequency data (such as transaction logs) in a Redis cluster (supporting 100,000 reads and writes per second) and low-frequency historical data (such as monthly financial statements) in Alibaba Cloud OSS. At the same time, data synchronization tools (such as DataX) are used to periodically archive data between Redis and OSS, ensuring the efficiency and security of data storage. The classification module dynamically classifies enterprise resource data into high-liquidity and low-liquidity resource data based on the data change frequency and number of interaction events for each resource within a preset period, and according to a preset liquidity threshold, and outputs the classification label results; specifically, it is constructed as follows: The classification module, developed in Java, establishes a JDBC connection with the Redis cluster of the data acquisition and storage module to read resource data to be classified in real time. First, a preset period of "1 hour" is set (this can be adjusted according to the enterprise's business scenario; for example, it can be set to 15 minutes during peak periods for retail enterprises and 4 hours for manufacturing). Second, the data change frequency of each resource within 1 hour is calculated (e.g., the CPU utilization of an ECS instance updates once every 5 minutes, changing 12 times within 1 hour, resulting in a change frequency of 12 times / hour) and the number of interaction events (e.g., a financial report is "accessed" 3 times within 1 hour). The system modifies the data once, with a total of 4 interaction events. Finally, based on preset liquidity thresholds (high liquidity threshold: change frequency ≥ 8 times / hour and number of interaction events ≥ 5 times / hour; low liquidity threshold: change frequency < 3 times / hour and number of interaction events < 2 times / hour), resource data is dynamically classified into high liquidity (such as business transaction flow and ECS instance usage) and low liquidity (such as annual financial asset data and historical archive files), and the classification results are marked with "HL" (high liquidity) or "LL" (low liquidity) and stored in the classification result table of the MySQL database. The determination of liquidity thresholds is based on a combination of historical business data statistics and industry benchmarks: First, resource data from the past 6 months is collected to analyze the distribution of change frequency and number of interaction events for different resources. For example, the change frequency of transaction flow is concentrated at 8-15 times / hour, and the number of interaction events is concentrated at 5-12 times / hour. The change frequency of historical financial data is concentrated at 1-3 times / hour, and the number of interaction events is concentrated at 0-2 times / hour. Second, referring to the resource management threshold standards of the same industry (such as the retail industry), the lower limit of the high liquidity threshold is determined to be "change frequency ≥ 8 times / hour and number of interaction events ≥ 5 times / hour", and the upper limit of the low liquidity threshold is "change frequency < 3 times / hour and number of interaction events < 2 times / hour". Resources in the middle range (change frequency 3-8 times / hour or number of interaction events 2-5 times / hour) are temporarily classified as "medium liquidity". The thresholds or classification levels can be adjusted later according to the company's business. The determination of health thresholds is based on the enterprise's target management needs. The low health threshold is set as the minimum value that meets the basic operational needs of the enterprise (such as the historical lowest health index of 300), and the high health threshold is set as the excellent operational level that the enterprise expects to achieve (such as the historical highest health index of 700), ensuring that the thresholds are operable and reasonable. The strategy execution module, connected to the classification module, receives the classification labeling results and executes the corresponding monitoring strategies based on these results: high-frequency data collection and status monitoring are implemented for data labeled as high-liquidity resources, while low-frequency security and compliance monitoring is implemented for data labeled as low-liquidity resources; specifically, it is constructed as follows: The strategy execution module, developed in Python, periodically (every minute) reads the classification and labeling results from the MySQL database. For resources labeled "HL" (such as real-time transaction logs), high-frequency, fine-grained monitoring is implemented: every 30 seconds, a data request is sent to the Redis interface of the data acquisition and storage module to collect data such as transaction amount, transaction success rate, and response time, and compared with a baseline value calculated based on the historical data of the past 7 days (such as a transaction success rate baseline of 99.5%). When the deviation exceeds a dynamic threshold (such as a transaction success rate lower than the baseline value by 1%), an early warning log is generated and pushed to the enterprise DingTalk alert group. For resources labeled "LL" (such as historical financial data), low-frequency security and compliance monitoring is implemented: every 24 hours, the API interface of Alibaba Cloud Access Control (RAM) is called to verify the access permissions of this type of data (such as only the finance department manager can view it), compare the data storage path with the enterprise security baseline template (such as prohibiting storage in publicly accessible OSS buckets), and query the validity of the corresponding qualification documents (such as financial audit reports) in the database (such as whether they are within the validity period). The evaluation module, connected to the strategy execution module, receives and aggregates monitoring data from the strategy execution module. It calculates a resource liquidity efficiency value based on monitoring data of high-liquidity resources using a first algorithm, and calculates an asset safety and stability value based on monitoring data of low-liquidity resources using a second algorithm. Finally, it generates a health index by weighted fusion of the liquidity efficiency value and the safety and stability value. Specifically, it is constructed as follows: The evaluation module is developed in Scala and executes monitoring data stored in the Hive data warehouse through the Spark SQL aggregation strategy execution module. For high-liquidity resource data, the resource flow efficiency value is calculated using the first algorithm: the turnover rate is the number of times the transaction flow is successfully invoked within an hour (e.g., a business system successfully invokes transaction data 1000 times per hour), and the utilization rate is the ratio (0.8) of the actual amount of transaction data used (e.g., 800 transactions actually processed per hour) to the total allocated amount (e.g., the system supports processing 1000 transactions per hour). Therefore, the flow efficiency value = 1000 × 0.8 = 800. For low-liquidity resource data, the asset security and stability value is calculated using the second algorithm: the preset period is 7. For each day, the security incident occurrence rate is the ratio of the number of security alerts triggered by financial data within 7 days (e.g., 2 times) to the total number of resources (e.g., 100 financial documents) (0.02). The compliance status score is the score obtained by comparing resource configuration with the security policy template (e.g., 95 points). Then, the security stability value = (1-0.02)×95 = 93.1. When weighted and integrated, α = 0.6 (flow efficiency weight) and β = 0.4 (security stability weight) are set according to the enterprise's business priority. Then, the health index = 0.6×800 + 0.4×93.1 = 517.24. The adjustment module, connected to the evaluation module, receives health indicators and matches them against predefined health ranges in the policy rule base. Based on the matching results, it issues corresponding adjustment instructions to the resource management execution unit. Specifically, it is constructed as follows: The adjustment module is developed using the Java Spring Boot framework, and the strategy rule base is stored in a MySQL database. Three health ranges are predefined: low health threshold (<300), normal range (300-700), and high health threshold (>700). When the assessment module outputs a health index of 517.24 (normal range), the instruction trigger unit matches the policy rule base without sending control instructions. If the health index drops to 280 (below the low health threshold), the first control instruction set is triggered, sending instructions to the enterprise workflow engine (such as JBPM) to increase the approval nodes for high-liquidity resources (such as expansion applications) (from 1 to 2) and upgrade the level of the approvers (from department head to company director). If the health index rises to 750 (above the high health threshold), the second control instruction set is triggered, modifying the resource scheduling policy configuration file of Alibaba Cloud ECS to increase the virtual resource quota (CPU from 4 cores to 8 cores) and priority weight (from 0.5 to 0.8) for high-efficiency business units (such as enterprise e-commerce business, identified by 60% of operating revenue and 500 transactions per second). Through the above technical solutions, dynamic classification and differentiated monitoring of resources are achieved, reducing the monitoring latency of high-liquidity resources and capturing peak business fluctuations in real time (such as transaction anomalies during e-commerce promotions); the monitoring frequency of low-liquidity resources is reduced, and the utilization rate of cloud computing resources is also reduced, saving cloud computing costs; the health index provides enterprises with a comprehensive management view, allowing managers to intuitively understand the resource operation status, and the automated adjustment mechanism reduces the resource allocation response time, realizing the transformation from "passive response" to "proactive early warning and automatic optimization", significantly improving the refinement and intelligence level of enterprise resource management. Example 2

[0022] Considering that traditional platforms have a vague definition of enterprise resource data and a narrow scope of collection, only covering some internal data (such as financial data) and lacking the collection of key data such as cloud computing infrastructure resource usage and business application system transaction data, it is impossible to fully grasp the status of enterprise resources and affect the accuracy of management decisions. Therefore, enterprise resource data includes cloud computing infrastructure resource usage data, business application system transaction data, and financial asset data. This embodiment takes a manufacturing enterprise as an example to explain in detail the specific content and collection methods of enterprise resource data. The specific content is as follows: Cloud computing infrastructure resource usage data: including CPU utilization (in %), memory usage (in GB), disk IOPS (in times / second), network bandwidth utilization (in Mbps) of Alibaba Cloud ECS instances, and the number of connections to Alibaba Cloud RDS databases (in units) and SQL execution response time (in ms). Data collection method: The above data is obtained every 5 minutes by calling the Alibaba Cloud Monitoring API (Access Key authorization). The API request parameters include instance ID, metric name, and time range. The returned data is stored in JSON format in the Kafka message queue and then synchronized to the Redis cluster for use by subsequent modules.

[0023] Transaction data from business application systems: including order transaction data from the enterprise production management system (order number, product model, quantity, amount, order time, production workshop number), procurement transaction data from the supply chain management system (purchase order number, supplier name, purchase amount, delivery time), and sales transaction data from the sales management system (sales order number, customer name, sales amount, delivery time). Data collection method: Database log parsing tools (such as Debezium) are used to monitor the binlog logs of the business database (MySQL) in real time, capture data insertion, update and deletion operations, convert transaction flow data into a standardized format (such as JSON), and transmit it to the data collection and storage module through Kafka to ensure the real-time performance (latency < 1 second) and integrity of data collection.

[0024] Financial asset data includes the company's balance sheet data (total assets, total liabilities, owner's equity), income statement data (operating revenue, operating costs, net profit), cash flow statement data (cash flow from operating activities, cash flow from investing activities, cash flow from financing activities), and fixed asset data (equipment number, name, purchase date, original value, accumulated depreciation, net value). Data collection method: By connecting to the enterprise's financial system (such as Yonyou U9) via API interface, the previous day's financial data is collected in batches at 2:00 AM every day (outside of peak business hours). The data format is Excel. The Excel data is converted into structured data using a data parsing tool (such as Apache POI) and stored in the archive storage layer of Alibaba Cloud OSS (low cost and high reliability). At the same time, data indexes (such as indexes based on device numbers) are created to facilitate subsequent queries and classification.

[0025] By clearly defining the specific scope and collection methods of enterprise resource data, comprehensive coverage of enterprise resources is achieved. The collection of cloud computing infrastructure resource usage data enables the IT department to monitor server load status in real time (e.g., timely expansion when CPU utilization exceeds 80%). The collection of business transaction data enables the business department to accurately analyze order trends (e.g., adjusting production plans when sales of a certain product increase by 50%). The collection of financial asset data enables the finance department to manage assets efficiently (e.g., improving the accuracy of fixed asset depreciation calculations). This solves the problem of incomplete data collection in traditional platforms and provides a complete and accurate data foundation for subsequent classification, monitoring, and evaluation modules.

[0026] Example 3: Considering that traditional platforms lack a scientific resource classification mechanism and only perform static classification based on resource type (such as data, devices), they cannot adjust the classification results according to dynamic changes in resources (such as data change frequency, number of interaction events), resulting in a mismatch between monitoring strategies and actual resource needs and low monitoring efficiency. Therefore, the classification module includes: The resource activity index calculation unit is used to calculate the data change frequency and number of interaction events for each resource within a preset period; the number of interaction events refers to the number of operation event records of resource creation, modification, deletion, access, or invocation. The liquidity threshold comparison unit, connected to the resource activity index calculation unit, is used to compare the calculated data change frequency and number of interaction events with the preset liquidity threshold. The resource classification and labeling unit, connected to the liquidity threshold comparison unit, is used to label resources as high-liquidity or low-liquidity resource data based on the comparison results. This embodiment uses an internet company as an example to illustrate the specific implementation of the three units of the classification module in detail: Resource Activity Metric Calculation Unit: Developed using Java multithreading technology, it starts an independent calculation thread for each type of resource to ensure calculation efficiency; the preset cycle is set to 30 minutes (internet companies experience rapid business changes, shortening the cycle to improve classification timeliness); Data Change Frequency Calculation: Taking user behavior data of a certain APP as an example, the number of times the data is updated within 30 minutes (e.g., user clicks, browsing, order placement leading to data updates, totaling 30 times) is counted, then the change frequency = 30 times / 30 minutes = 1 time / minute; Interaction Event Count Calculation: The number of operation event records within 30 minutes for "creation" (new user behavior record generation, 10 times), "modification" (user modifying order information, 5 times), "deletion" (user canceling order, 2 times), "access" (operations personnel viewing data, 8 times), and "call" (data analysis system calling data, 5 times) is counted, totaling 10 + 5 + 2 + 8 + 5 = 30 times, that is, the number of interaction events is 30. The calculation results are stored in a Redis Hash structure, where the Key is the resource ID, the Fields are "change frequency" and "number of interaction events", and the Value is the corresponding calculated value.

[0027] Liquidity Threshold Comparison Unit: Developed using Python, this unit connects to the Redis cluster of the resource activity indicator calculation unit. It reads the calculation results every 30 minutes (synchronized with a preset period) and compares them with preset liquidity thresholds. In this embodiment, based on the characteristics of internet enterprise user behavior data (frequent changes, high interaction volume), a high liquidity threshold is set as "change frequency ≥ 0.8 times / minute and number of interaction events ≥ 25 times / 30 minutes," and a low liquidity threshold is set as "change frequency < 0.3 times / minute and number of interaction events < 10 times / 30 minutes." Taking a certain APP user behavior data as an example, a change frequency of 1 time / minute ≥ 0.8 times / minute and a number of interaction events of 30 times ≥ 25 times are considered to meet the high liquidity threshold. Taking historical user registration data of an enterprise (2 changes within 30 minutes, change frequency 0.067 times / minute, number of interaction events 5 times) as an example, a change frequency of 0.067 times / minute < 0.3 times / minute and a number of interaction events of 5 times < 10 times are considered to meet the low liquidity threshold. The comparison results are stored in the comparison result table in MySQL, which includes resource ID, change frequency, number of interaction events, and threshold comparison results (meeting high liquidity / low liquidity / medium liquidity). Resource Classification and Tagging Unit: Developed in Java, this unit monitors new data entries in the MySQL comparison result table. Upon receiving the comparison results, it adds classification tags to the resources based on the results. For resources meeting the high liquidity threshold, a "HL-High Liquidity" tag is added, along with the tagging time (e.g., 2024-05-20 10:30:00). For resources meeting the low liquidity threshold, a "LL-Low Liquidity" tag is added. For medium liquidity resources (e.g., change frequency 0.5 times / minute, number of interaction events 15 times), a "ML-Medium Liquidity" tag is temporarily added; the monitoring strategy can be expanded later according to enterprise needs. The classification and tagging results are synchronously updated to the resource metadata table in the data acquisition and storage module (adding a "Classification Tag" field) and pushed to the strategy execution module to trigger the corresponding monitoring strategy. In this embodiment, the liquidity threshold is determined using a "business scenario adaptation method": First, the core business scenarios of internet companies (such as APP operation and user services) are analyzed to determine the dynamic characteristics of key resources (such as user behavior data and transaction data). User behavior data changes at a frequency of up to 1.2 times per minute during peak hours (e.g., 8-10 PM), with up to 40 interaction events per 30 minutes. During off-peak hours, the change frequency is approximately 0.5 times per minute, with approximately 20 interaction events per 30 minutes. Second, the carrying capacity of monitoring resources is considered (e.g., each high-liquidity resource requires 0.5 CPU cores to monitor, and the platform has a total of 100 CPU cores). Supports monitoring of 200 high-liquidity resources. The lower limit of the high-liquidity threshold is set as "change frequency ≥ 0.8 times / minute and number of interaction events ≥ 25 times / 30 minutes" to ensure that the number of high-liquidity resources does not exceed 150 during peak periods (occupying 75 CPU cores), reserving 25 CPU cores to cope with emergencies. The low-liquidity threshold is set with reference to the dynamic characteristics of historical data (such as the highest change frequency of historical user registration data being 0.3 times / minute and the highest number of interaction events being 10 times / 30 minutes), and is set as "change frequency < 0.3 times / minute and number of interaction events < 10 times / 30 minutes" to ensure that monitoring of low-liquidity resources does not consume too many computing resources. By refining the classification module, the accuracy of resource classification is improved, enabling precise identification of high- and low-liquidity resources. The dynamic updating of classification results (updated every 30 minutes) allows monitoring strategies to adapt to resource changes in real time, upgrading resource classification from "passively adapting to resource types" to "actively sensing business dynamics," providing core technical support for the refinement and intelligence of enterprise resource management.

[0028] Example 4: Considering that traditional enterprise resource management platforms have significant shortcomings in the execution of monitoring strategies: on the one hand, using a uniform monitoring frequency for all resources leads to a lag in the monitoring response of high-liquidity resources (such as real-time transaction data), making it impossible to detect business anomalies in a timely manner; on the other hand, implementing high-frequency monitoring for low-liquidity resources (such as historical contract documents) results in a waste of computing resources, while lacking targeted security and compliance checks, increasing the risk of asset leakage, therefore, the strategy execution module includes: The high-frequency fine monitoring unit, in response to data marked as high-mobility resource data, initiates a data request to the monitoring interface of the data acquisition and storage module at a first preset frequency, and compares the acquired real-time data with a baseline value dynamically calculated based on historical data. When the deviation exceeds a dynamic threshold, an early warning log is generated. The first preset frequency is a high frequency, configured to perform data acquisition once every 10 seconds to 5 minutes. The low-frequency security monitoring unit, in response to data marked as low-mobility resources, performs at least one of the following operations at a second preset frequency: verifying permissions via the API interface of the identity management and access control system, comparing resource configuration with the security baseline template, and querying the validity of the qualification database; the second preset frequency is low frequency, configured to perform a security compliance check once every 24 hours or week; this embodiment uses an internet company as an example to illustrate the technical details of the differentiated monitoring strategy in detail: The strategy execution module adopts a microservice architecture design, consisting of a high-frequency fine-grained monitoring unit and a low-frequency security monitoring unit. It is deployed in containers through Kubernetes to ensure the module's elastic scalability. High-frequency fine-grained monitoring unit: For high-liquidity resources marked "HL" (such as real-time order data from a stock trading system), the following technical solutions are adopted: Dynamically adaptable data collection frequency: The default preset frequency is 30 seconds / time, which can be adjusted according to resource importance (10 seconds / time for core transaction data, 5 minutes / time for general business data). Data collection requests are precisely triggered by developing a scheduled task component (based on the Quartz framework). Real-time data request mechanism: A high-performance API client is developed using the Netty framework to initiate asynchronous data requests to the Redis monitoring interface of the data acquisition and storage module, supporting 1000 concurrent requests per second and ensuring data acquisition latency <50ms. The collected fields include 20+ dimensions such as order amount, number of transactions, order time, and transaction status. Baseline value dynamic calculation model: Employing a sliding window algorithm (window size of 24 hours), it calculates the baseline value of historical data for the same time period over the past 7 days in real time. For example, the baseline value of order processing success rate for a certain stock trading session (9:30-11:30) is calculated using a weighted average (0.5 weight for the most recent 3 days and 0.5 weight for the 4th to 7th days). Dynamic threshold early warning mechanism: Based on the 3σ principle, a deviation threshold is set (e.g., the dynamic threshold for order processing success rate is ±3% of the baseline value). When the deviation between real-time data and the baseline value exceeds the threshold, an early warning is triggered immediately. The early warning log contains information such as the abnormal time, resource ID, current value, baseline value, and deviation rate. It is pushed to an enterprise-level monitoring platform (such as Prometheus + Grafana) via Kafka and simultaneously sent to the mobile phones of operations and maintenance personnel via SMS. Low-frequency security monitoring unit: For low-liquidity resources marked "LL" (such as customer credit files), the following technical solutions are adopted: Security check frequency configuration: The second preset frequency is 24 hours / time by default. For highly sensitive resources (such as core customer information), it can be adjusted to 12 hours / time. Archived resources can be set to once a week. Frequency parameters are centrally managed through a configuration center (such as Apollo), and dynamic modification is supported without restarting the service. Access control implementation: Integrate with enterprise identity management and access control systems (such as Keycloak), obtain access tokens by calling their REST API interface, and then call the access query interface to verify whether the current access subject (such as user or system) has the preset permissions (such as credit files can only be viewed by the risk control department manager). Security baseline comparison process: Build an enterprise-level security baseline template library (stored in MongoDB), including 200+ checkpoints such as data storage location (e.g., prohibiting storage on servers with public IP addresses), encryption algorithms (e.g., AES-256), and backup strategies (e.g., daily off-site backup); by developing a comparison engine, extract the actual configuration information of resources (e.g., file storage path, encryption method), compare it item by item with the template library, and generate a compliance rate (e.g., 98%). Qualification Validity Inquiry: A qualification document database (MySQL) is established to store information such as approval documents, validity period, and approver corresponding to the credit file. SQL queries are used to verify whether the qualification is within its validity period; expired qualifications are automatically marked as "abnormal." High-frequency, high-precision monitoring shortens the real-time response time to transaction anomalies for financial institutions and improves order processing success rates. Low-frequency security monitoring reduces the computational overhead of monitoring low-liquidity resources while increasing the coverage of security and compliance checks and reducing the risk of customer information leakage.

[0029] Example 5 considers two major problems with traditional platforms' assessment of enterprise resources: first, the assessment dimensions are singular, focusing only on efficiency indicators such as resource utilization while neglecting security and compliance; second, the assessment algorithms are vague, lacking quantitative calculation models, resulting in highly subjective assessment results that cannot provide accurate basis for decision-making. Therefore, in the assessment module, The first algorithm is as follows: the flow efficiency value = turnover rate × utilization rate; wherein, the turnover rate is the number of times high-flow resource data is successfully accessed per unit time, and the utilization rate is the ratio of the actual usage of high-flow resource data to the total allocation. The second algorithm is as follows: the security stability value = (1 - security incident occurrence rate) × compliance status score; where the security incident occurrence rate is the ratio of the number of security alarms triggered by low-liquidity resource data to the total number of resources within a preset period, and the compliance status score is a percentage score obtained by comparing resource configuration with security policy template; The weighted fusion is as follows: the health index = α × flow efficiency value + β × safety stability value, where α and β are preset weighting coefficients, and α + β = 1; this embodiment takes an e-commerce enterprise as an example to disclose in detail the algorithm implementation and parameter determination method of the evaluation module: The evaluation module is deployed on a Spark cluster (3 master nodes, 10 worker nodes) and processes monitoring data in real time using Spark Streaming. The calculation process is as follows: Flow efficiency calculation (first algorithm): For high-liquidity resources (such as product inventory data on e-commerce platforms): Turnover rate = the number of times inventory data is successfully accessed per unit of time. By parsing the call logs in Kafka, the total number of successful operations such as inventory queries and deductions per hour is counted (e.g., a certain product is accessed 1200 times per hour); Utilization rate = actual usage / total allocation. Actual usage is the number of products actually shipped out per hour (e.g., 800 items), and total allocation is the maximum inventory capacity of the product (e.g., 1000 items). Therefore, utilization rate = 800 / 1000 = 0.8; Flow efficiency value = Turnover rate × Utilization rate = 1200 × 0.8 = 960; Safety stability value calculation (second algorithm): For low-liquidity resources (such as supplier contract documents on e-commerce platforms): Security incident occurrence rate = number of security alerts within a preset period / total number of resources. The preset period is 7 days. The statistics include security alerts triggered by unauthorized access and file tampering of contract documents within this period (e.g., 3 times). The total number of resources is the total number of such contract documents (e.g., 150 documents). Therefore, the security incident occurrence rate = 3 / 150 = 0.02. The compliance status score is obtained by comparing the storage configuration of contract documents (e.g., whether they are encrypted or backed up) with e-commerce industry security standards (e.g., the "E-commerce Data Security Management Specification"), and a score of 100 is used (e.g., 92 points). Security stability value = (1 - security incident occurrence rate) × compliance status score = (1 - 0.02) × 92 = 90.16.

[0030] Weighted fusion calculation of health indicators: The weighting coefficients α and β were determined using the Analytic Hierarchy Process (AHP): Five experts (IT Director, Security Manager, Operations Manager, etc.) were invited to score the importance of "flow efficiency" and "security stability"; a judgment matrix was constructed, the weight vector was calculated, and a consistency test was performed (CR < 0.1); finally, the weights for e-commerce companies were determined as α = 0.7 (flow efficiency is more important) and β = 0.3 (security stability is secondary but necessary); the health index = 0.7 × 960 + 0.3 × 90.16 = 699.05; Through quantitative algorithms, e-commerce companies' resource assessment has shifted from qualitative descriptions to precise numerical values, reducing the assessment error rate. The health index integrates efficiency and security dimensions, enabling management to intuitively judge the state of the resource ecosystem and improving decision-making accuracy.

[0031] Example 6: Considering the problem of "disconnect between monitoring and control" in traditional platform resource management—monitoring data is only used for display and lacks automatic association with management actions; resource allocation, process adjustment, and other operations rely on manual judgment, resulting in delayed response (e.g., expansion approval requires 2 hours when resources are insufficient) and inability to adapt to rapid business changes—the adjustment module includes: The strategy rule base is used to store resource control instruction sets corresponding to different health index ranges; The instruction triggering unit, connected to the policy rule base and evaluation module, is used to match the received health indicators with the intervals in the policy rule base and output the matched resource control instruction set. The resource scheduling execution module, connected to the instruction triggering unit, is used to receive the control instruction set and send instructions from the control instruction set to the resource management execution unit. This embodiment uses a logistics company as an example to disclose the specific implementation of the control module: The regulation module adopts a "rule engine + executor" architecture, and the technology stack includes Drools (rule engine), Spring Cloud Stream (message driven), and Docker (containerized execution).

[0032] The policy rule base is built using a MySQL database to store rules, and a three-dimensional rule model is designed: Health range: Low health threshold (<400), Normal range (400-800), High health threshold (>800); Resource types: transportation vehicle resources, storage space resources, human resources, etc.; Control instruction set: Define specific instructions for different ranges and resource types.

[0033] For example, rules regarding transport vehicle resources: When health is less than 400, the instruction set includes "Add 2 temporary rental vehicles" and "Increase the priority of long-distance transportation"; When the health level is greater than 800, the instruction set includes "reducing one idle owned vehicle" and "reducing the budget for short-distance transportation costs".

[0034] The rule base supports version management (version control via Git) and hot updates (changes take effect within 10 minutes).

[0035] Instruction triggering unit implementation: Develop a real-time comparison service that retrieves health metrics from the assessment module every 5 minutes and matches them against the policy rule base using the Drools rule engine. Details are as follows: Input parameters include health value, resource type ID, and current time; then the engine parses the rule conditions (such as "health < 400 AND resource type = transport vehicle"), matches the corresponding instruction set; finally, the output results are generated into an instruction execution list (including instruction ID, execution priority, and timeout).

[0036] The resource scheduling and execution module calls different executors based on the instruction type, specifically: System-level commands (such as vehicle dispatching) are executed directly by calling the logistics management system API and the execution result (success / failure reason) is returned. Process-level instructions (such as approval process adjustments) are sent to a RabbitMQ queue, where they are consumed and executed by the workflow engine (Activiti). Manual intervention instructions (such as emergency meeting notifications) are pushed to designated personnel via the WeChat Work API, and the reading status is recorded. The execution of all instructions is recorded through a distributed tracing system (Zipkin) to ensure traceability.

[0037] Through the above-mentioned technical means, the response time for enterprise resource regulation is shortened, and the resource utilization rate is increased by 25%; the flexible configuration of the rule base enables enterprises to quickly adapt to business changes (such as seasonal transportation peaks), reducing management costs; automated execution reduces human operation errors and improves the accuracy of instruction execution.

[0038] Example 7: Considering the "one-size-fits-all" problem in the control strategies of traditional platforms—that is, the lack of refined correlation between health indicators and control measures, and the application of the same control strategy to different business units with the same health value, which fails to reflect differences in business priorities and leads to resource misallocation (such as allocating limited resources to low-efficiency businesses)—the predefined rules in the strategy rule base include: when the health indicator is lower than a preset low health threshold, a first control instruction set is triggered; when the health indicator is higher than a preset high health threshold, a second control instruction set is triggered; wherein, the low health threshold is less than the high health threshold. The first set of control instructions includes sending instructions to the enterprise's workflow engine to increase the approval nodes and / or approval personnel levels in the high-mobility resource data application process; The second set of control instructions includes modifying the resource scheduling policy configuration file of the cloud computing infrastructure layer to increase the virtual resource quota or priority weight of units marked as high-efficiency business units. These high-efficiency business units are identified from the business modules managed by the platform based on one or more preset business performance indicators. These indicators include the business module's operating revenue, profit contribution, transaction throughput, service response time, resource utilization efficiency, or any combination thereof. This embodiment takes an internet finance company as an example and discloses a refined rule design for the policy rule base and a method for identifying high-efficiency business units. The specific content is as follows: First, the health threshold is determined by combining historical data analysis with business objectives. For low health thresholds, the 30th percentile (350 points) of the health index over the past 12 months is used to ensure that emergency adjustments are triggered when the value falls below this value. For high health thresholds, the 70th percentile (750 points) of the health index over the past 12 months is used to ensure that redundant resources are released when the value rises above this value. The thresholds also support automatic calibration every quarter (by calculating the percentiles using a Python script).

[0039] The first set of control instructions (triggered when health < 350) targets high-liquidity resources (such as loan approval process data). Specifically, it includes: adding approval nodes by modifying the workflow engine's (Flowable) process definition XML file to add a "Department Director Review" node after the "Risk Control Audit" node; and upgrading the approver's level by calling the access control system API to change the approver's role from "Risk Control Specialist" to "Risk Control Manager." For example, the approval process for a consumer loan product originally had one node (Risk Control Specialist), but after triggering the instruction, it becomes two nodes (Risk Control Specialist → Risk Control Manager), extending the approval time from 30 minutes to 1 hour, but improving the approval accuracy. The second set of control instructions (triggered when health > 750) is used to identify high-efficiency business units, specifically including the following: A multi-dimensional evaluation model is established, with indicators including: financial indicators such as operating revenue (weight 0.4) and profit margin (weight 0.3); and operational indicators such as transaction throughput (weight 0.15) and user growth rate (weight 0.15). The calculation method involves standardizing each indicator (0-100 points) and then weighting and summing them. The top 20% of business units are marked as "high-efficiency". For example, a company's "supply chain finance business" scores 92 points (above the 80-point threshold) and is identified as a high-efficiency business unit. The specific details of the resource regulation measures are as follows: Edit the Kubernetes HPA (HorizontalPodAutoscaler) configuration file to increase the maximum number of Pod replicas for this business unit from 10 to 20, thereby modifying the cloud computing resource scheduling policy; increase the CPU quota from 4 cores to 8 cores and the memory from 8GB to 16GB by calling the Alibaba Cloud Container Service API, thereby increasing the virtual resource quota; adjust the routing weight of this business from 0.5 to 0.8 in the service registry (Nacos) to ensure priority traffic allocation, thereby adjusting the priority weight. Through the aforementioned technical means, high-risk businesses (such as consumer loans) can reduce bad debt rates when in a low-health state through a strict approval process; high-efficiency businesses can obtain more resource support when in a high-health state, thereby improving transaction processing capabilities and user satisfaction; and the resource mismatch problem can be solved, thereby improving the return on investment of cloud computing resources.

[0040] Example 8: Considering that traditional platforms lack intuitive resource management visualization tools, and monitoring data is scattered across multiple systems (such as monitoring platforms and reporting systems), managers need to switch between multiple interfaces to understand the overall resource status, resulting in low decision-making efficiency. Simultaneously, the lack of collaborative functions makes it difficult for departments (IT, business, finance) to share resource data, leading to delays in cross-departmental decision-making. Therefore, the platform also includes a visual collaborative decision-making module, which is connected to the classification module, strategy execution module, and evaluation module to graphically and synchronously display real-time dynamic data of high-liquidity resource data, a security status overview of low-liquidity resource data, and the changing trends of resource ecosystem health indicators. This example uses a group enterprise as an example to disclose the specific implementation of the visual collaborative decision-making module: The visual collaborative decision-making module adopts a front-end and back-end separation architecture. The front-end is developed based on ECharts + Vue3, and the back-end uses Spring Boot + Web Socket to provide real-time data interfaces and is deployed on an enterprise private cloud platform. The content and format of the data display will differ depending on the type of data. Specific details are as follows: For real-time dynamic data of highly liquid resources, the system displays transaction amount (line chart), resource utilization rate (dashboard), and response time (heatmap), and pushes data every second via WebSocket, with the charts automatically refreshed. For example, the group's e-commerce sector's real-time transaction data dashboard displays transaction volume from all regions across the country every 5 minutes, and supports drill-down to view specific product categories.

[0041] For the overview of the security status of low-liquidity resources, the system displays the security compliance rate (pie chart), security event trend (bar chart), and weight distribution (Sankey diagram); it is refreshed every hour. For example, the security status dashboard of the group's financial archives displays the compliance rate of each subsidiary's financial data (e.g., 98.5%) and the number of security incidents in the past 30 days (e.g., 5 incidents).

[0042] The system displays historical curves (line charts), the proportions of efficiency and safety dimensions (pie charts), and a comparison of the health of each business unit (radar charts) to show the changing trends of resource and ecological health indicators. It also supports selecting time intervals (such as the last 7 days or the last 30 days) and year-on-year / month-on-month analysis. For example: a trend chart of the group's overall health, highlighting key milestones (such as a sharp increase in health on June 18, due to increased resource investment during e-commerce promotions). The aforementioned technologies shorten management decision-making time and improve cross-departmental collaboration efficiency; data visualization increases the rate of resource problem detection, achieving early warning; and data sharing among departments makes resource allocation more precise, reducing the overall operating costs of the group.

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

Claims

1. A cloud-based enterprise resource management platform, characterized in that, include: The data acquisition and storage module is used to collect and store enterprise resource data in real time from various internal and external data sources. The classification module, connected to the data acquisition and storage module, is used to dynamically classify enterprise resource data into high-liquidity resource data and low-liquidity resource data based on the data change frequency and number of interaction events of each resource within a preset period and a preset liquidity threshold, and output the classification label results. The strategy execution module, connected to the classification module, is used to receive classification labeling results and execute corresponding monitoring strategies based on the classification labeling results: high-frequency data collection and status monitoring are implemented for data labeled as high-liquidity resources, and low-frequency security and compliance monitoring is implemented for data labeled as low-liquidity resources. The evaluation module, connected to the strategy execution module, is used to receive and aggregate monitoring data from the strategy execution module. It calculates the resource flow efficiency value based on the monitoring data of high-liquidity resource data using a first algorithm, calculates the asset security and stability value based on the monitoring data of low-liquidity resource data using a second algorithm, and generates a health index by weighted fusion of the flow efficiency value and the security and stability value. The adjustment module, connected to the evaluation module, receives health indicators and matches them with predefined health ranges in the policy rule base. Based on the matching results, it issues corresponding adjustment instructions to the resource management execution unit.

2. The cloud-based enterprise resource management platform according to claim 1, characterized in that: The enterprise resource data includes usage data of cloud computing infrastructure resources, transaction flow data of business application systems, and financial asset data.

3. The cloud-based enterprise resource management platform according to claim 1, characterized in that, The classification module includes: The resource activity index calculation unit is used to calculate the data change frequency and number of interaction events for each resource within a preset period; the number of interaction events refers to the number of operation event records of resource creation, modification, deletion, access, or invocation. A liquidity threshold comparison unit, connected to the resource activity index calculation unit, is used to compare the calculated data change frequency and number of interaction events with a preset liquidity threshold. The resource classification and labeling unit is connected to the liquidity threshold comparison unit and is used to label resources as high-liquidity resource data or low-liquidity resource data according to the comparison results.

4. The cloud-based enterprise resource management platform according to claim 1, characterized in that: The strategy execution module includes: The high-frequency fine monitoring unit, in response to data marked as high-mobility resource data, initiates a data request to the monitoring interface of the data acquisition and storage module at a first preset frequency, and compares the acquired real-time data with a baseline value dynamically calculated based on historical data. When the deviation exceeds a dynamic threshold, an early warning log is generated. The first preset frequency is a high frequency, configured to perform data acquisition once every 10 seconds to 5 minutes. The low-frequency security monitoring unit, in response to data marked as low-mobility resources, performs at least one of the following operations at a second preset frequency: verifying permissions by calling the API interface of the identity management and access control system, comparing resource configuration with security baseline templates, and querying the validity of the qualification database; the second preset frequency is a low frequency, configured to perform a security compliance check once every 24 hours or once a week.

5. The cloud-based enterprise resource management platform according to claim 1, characterized in that: In the evaluation module The first algorithm is as follows: the flow efficiency value = turnover rate × utilization rate; wherein, the turnover rate is the number of times high-flow resource data is successfully accessed per unit time, and the utilization rate is the ratio of the actual usage of high-flow resource data to the total allocation. The second algorithm is as follows: the security stability value = (1 - security incident occurrence rate) × compliance status score; where the security incident occurrence rate is the ratio of the number of security alarms triggered by low-liquidity resource data to the total number of resources within a preset period, and the compliance status score is a percentage score obtained by comparing resource configuration with security policy template; The weighted fusion is as follows: the health index = α × flow efficiency value + β × safety stability value, where α and β are preset weighting coefficients, and α + β = 1.

6. The cloud-based enterprise resource management platform according to claim 1, characterized in that: The adjustment module includes: The strategy rule base is used to store resource control instruction sets corresponding to different health index ranges; The instruction triggering unit, connected to the policy rule base and evaluation module, is used to match the received health indicators with the intervals in the policy rule base and output the matched resource control instruction set. The resource scheduling execution module, connected to the instruction triggering unit, is used to receive the control instruction set and send the instructions in the control instruction set to the resource management execution unit.

7. The cloud-based enterprise resource management platform according to claim 6, characterized in that: The predefined rules in the strategy rule base include: when the health index is lower than a preset low health threshold, a first set of control instructions is triggered; when the health index is higher than a preset high health threshold, a second set of control instructions is triggered; wherein, the low health threshold is less than the high health threshold. The first set of control instructions includes sending instructions to the enterprise's workflow engine to increase the approval nodes and / or approval personnel levels in the high-mobility resource data application process; The second set of control instructions includes modifying the resource scheduling policy configuration file of the cloud computing infrastructure layer to increase the virtual resource quota or priority weight of the marked high-efficiency business units. The high-efficiency business units are units identified from the business modules managed by the platform based on one or more preset business performance indicators. The business performance indicators include the business module's operating revenue, profit contribution, transaction throughput, service response time, resource utilization efficiency, or any combination thereof.

8. The cloud-based enterprise resource management platform according to claim 1, characterized in that: It also includes a visual collaborative decision-making module, which is connected to the classification module, strategy execution module, and evaluation module to display in a graphical manner the real-time dynamic data of high-mobility resource data, the security status overview of low-mobility resource data, and the changing trends of resource ecological health indicators.

Images