Business coordination management system based on multi-dimensional data fusion

Abstract

This invention relates to the field of enterprise business data processing technology, specifically a business collaborative management system based on multi-dimensional data fusion. The system includes modules for data extraction, data cleaning, correlation fusion, analysis cube, and collaborative decision-making. The data extraction module extracts business master data from enterprise resource planning systems, customer relationship management tools, and supply chain management platforms to form corresponding datasets. The data cleaning module removes duplicate records and outliers to purify the data. The correlation fusion module establishes logical mapping relationships between production work orders, sales orders, and purchase contracts in the business data lake, generating a business object correlation graph. The analysis cube module constructs a multi-dimensional data cube with specified dimensions, and the collaborative decision-making module extracts key indicators through multi-dimensional operations to form an indicator set. This system breaks down the isolation of cross-source data, achieving full-domain correlation of business data and targeted extraction of collaborative decision-making indicators.

Description

Technical Field

[0001] This invention relates to the field of enterprise business data processing technology, and in particular to a business collaborative management system based on multi-dimensional data fusion. Background Technology

[0002] In enterprise business management scenarios, business data in production, marketing, and logistics are stored and processed independently by enterprise resource planning systems, customer relationship management tools, and supply chain management platforms, respectively. Existing technologies mostly extract and clean data for single-source systems, and only complete the data standardization within a single system. Business data from different systems are only superficially integrated through simple table summaries, without conducting deep association operations on cross-system business entities.

[0003] Data from separate business systems contains duplicate records and outliers. Data cleanup is limited to single-system datasets. Production work orders, sales orders, and purchase contracts originate from different systems, lacking a unified logical correspondence. Dispersed data storage prevents the formation of a global relational structure, and cross-source relationships between business entities are missing. Existing multidimensional analysis models do not build their analytical framework based on business entity relationships, and their analytical dimensions do not align with the actual needs of business collaboration. They cannot extract suitable business indicators for collaborative decision-making through drill-down, rotation, and slicing operations, making it difficult to form a dedicated indicator system to support business collaboration.

[0004] It is necessary to complete the cross-source association of business entities from different source systems in a unified business data lake, establish the logical mapping relationship between production work orders, sales orders and purchase contracts, construct a multi-dimensional data cube of a specified dimension based on the generated business object association graph, and extract key business indicators for collaborative decision-making and form corresponding indicator sets through drill-down, rotation and slicing operations on the cube. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by proposing a business collaborative management system based on multi-dimensional data fusion.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: a business collaborative management system based on multi-dimensional data fusion, comprising:

[0007] The data extraction module extracts business master data from the enterprise resource planning system, customer relationship management tools, and supply chain management platform to form production data sets, market data sets, and logistics data sets.

[0008] The data cleaning module cleans the production data set, the market data set, and the logistics data set, removing duplicate records and outliers to obtain the cleaned production data set, the cleaned market data set, and the cleaned logistics data set.

[0009] The association and fusion module imports the purified production data set, the purified market data set, and the purified logistics data set into a unified business data lake. In the business data lake, cross-source associations are performed on business entities from different source systems, establishing logical mapping relationships between production work orders, sales orders, and purchase contracts, and generating a business object association graph.

[0010] The analysis cube module constructs a multidimensional data cube based on the business object association graph. The dimensions of the multidimensional data cube include time period, organizational department, product category and business stage.

[0011] The collaborative decision-making module performs drill-down, rotation, and slicing operations on the multidimensional data cube to extract key business indicators that support collaborative decision-making, forming a collaborative decision-making indicator set.

[0012] As a further aspect of the present invention, data cleaning is performed on the production data set, the market data set, and the logistics data set, including:

[0013] The uniqueness of the work order numbers in the production data set is verified, records with duplicate work order numbers are marked as to be deleted, and the remaining records are sorted based on production time.

[0014] The customer contact information in the market data set is standardized in format, non-standard contact information is converted into a unified international area code format, and records that cannot be parsed are removed;

[0015] Logical checks are performed on the status of waybills in the logistics data set. Waybills with a status of "signed" but no signature time are marked as abnormal, and their historical status is queried in the business data lake based on the waybill number for repair.

[0016] The three processed datasets are merged to generate a temporary full business dataset, and null values ​​are filled into the temporary full business dataset.

[0017] As a further aspect of the present invention, the purified production data set, the purified market data set, and the purified logistics data set are imported into a unified business data lake, including:

[0018] The business data lake is constructed using a star schema, with business entity identifiers as the common dimension.

[0019] In the business data lake, fact tables and dimension tables are defined, wherein the fact tables are used to store metrics, and the dimension tables are used to store attributes such as the time period, the organizational department, the product category, and the business stage.

[0020] The output and working hours metrics from the purified production data set are loaded into the fact table, and the corresponding production workshop and shift information are associated with the organizational department dimension table.

[0021] The sales and cash collection metrics from the purified market data set are loaded into the fact table, and the corresponding sales regions and customer level information are associated with the organizational department dimension table and the product category dimension table.

[0022] The shipment volume and transit time values ​​from the purified logistics data set are loaded into the fact table, and the corresponding carrier and warehouse information are associated with the organizational department dimension table.

[0023] As a further aspect of the present invention, in the business data lake, cross-source association of business entities from different source systems includes:

[0024] Using the product code in the business data lake as the primary key, the product specification information in the production data set is matched with the product description information in the market data set to establish a product master data view;

[0025] Using the customer code in the business data lake as a foreign key, sales orders in the market data set and delivery orders in the logistics data set are linked to establish a customer fulfillment view;

[0026] Using the project number in the business data lake as the association key, the production work orders in the production data set are associated with the project budget in the financial system to establish a project cost view;

[0027] The product master data view, customer fulfillment view, and project cost view are merged to form the business object association graph, which stores the many-to-many relationships between business entities in the form of a graph structure.

[0028] As a further aspect of the present invention, a multidimensional data cube is constructed based on the business object association graph, including:

[0029] The nodes in the business object association graph are used as the basic analysis units of the multidimensional data cube;

[0030] The time period, the organizational department, the product category, and the business stage are used as the four dimensions of the multidimensional data cube, and a hierarchical structure is established for each dimension, wherein the time period dimension includes the levels of year, quarter, month, and day.

[0031] The metrics of the fact table in the business data lake are used as the metrics of the multidimensional data cube, including production completion rate, sales achievement rate and inventory turnover rate;

[0032] Online analytical processing (OLAP) technology is used to pre-compute the multidimensional data cube to generate aggregated data blocks.

[0033] As a further aspect of the present invention, drilling, rotating, and slicing operations are performed on the multidimensional data cube, including:

[0034] Receive analysis requests initiated by users, the analysis requests containing specified analysis dimensions and filtering conditions;

[0035] According to the analysis request, the corresponding aggregated data block is located in the multidimensional data cube. If the analysis request involves more granular data, a drill-down operation is performed to obtain detailed data of the higher-level aggregated data block from the lower-level aggregated data block.

[0036] If the analysis request requires a change in the analysis perspective, a rotation operation is performed to swap the row and column dimensions in the multidimensional data cube;

[0037] If the analysis request includes restrictions on the values ​​of a specific dimension, a slicing operation is performed to cut a sub-cube from the multidimensional data cube;

[0038] The dataset obtained after the operation is further processed according to the predefined index calculation rules to generate the collaborative decision-making index set.

[0039] As a further aspect of the present invention, the system further includes:

[0040] The task engine module inputs the collaborative decision indicator set into a workflow engine, which converts the indicators into tasks according to predefined business rules and generates a queue of tasks to be done.

[0041] The resource scheduling module parses the resource requirements for task execution from the task queue and locks the corresponding computing and storage resources in the resource pool based on the resource requirements to form a resource scheduling list. The resource scheduling list drives the enterprise resource planning system, the customer relationship management tool and the supply chain management platform to write back data, thereby realizing a closed-loop update of business status.

[0042] The data traceability module archives the historical data in the business data lake after the business status closed-loop update is completed, and generates a data lineage traceability record, which includes the data source, processing process and target system.

[0043] As a further aspect of the present invention, the collaborative decision-making index set is input into a workflow engine, including:

[0044] A pre-built business rule base is loaded into the workflow engine. The business rule base defines the mapping relationship between different indicator thresholds and business actions.

[0045] Iterate through each indicator in the collaborative decision-making indicator set, compare the actual value of the indicator with the threshold in the rule base, and trigger the corresponding rule when the actual value of the indicator exceeds the threshold range.

[0046] Based on the triggered rules, generate a pending task containing a task description, the person in charge of the task, the task deadline, and the task input data, and push the pending task into the pending task queue.

[0047] Dependency analysis is performed on the tasks in the pending task queue. If there are pending tasks with incomplete prerequisite tasks, their status is set to suspended.

[0048] As a further aspect of the present invention, the resource requirements for task execution are parsed from the task queue, and corresponding computing and storage resources are locked in the resource pool based on the resource requirements, including:

[0049] The task description of the pending task is parsed to identify the task type, which includes data report generation, batch data processing, and interface calls.

[0050] Based on the task type, available compute nodes and storage volumes are queried in the resource pool. Among them, data report generation tasks are given priority to compute nodes with high concurrency processing capabilities, and batch data processing tasks are given priority to nodes with large-capacity storage volumes.

[0051] Set resource locks for the selected compute nodes and storage volumes. The validity period of the resource locks is consistent with the deadline of the pending tasks to prevent resources from being preempted by other tasks.

[0052] The selected compute nodes, storage volumes, and resource lock information are combined into the resource scheduling list, and the resource scheduling list is bound to the corresponding pending tasks.

[0053] As a further aspect of the present invention, data write-back is driven by a resource scheduling list to the enterprise resource planning system, the customer relationship management tool, and the supply chain management platform, including:

[0054] Read the pending tasks bound in the resource scheduling list, and locate the latest business data snapshot in the business data lake based on the business entity identifier in the task input data;

[0055] The data in the business data snapshot is converted into an interface protocol format that the target system can recognize. For the enterprise resource planning system, an intermediate table exchange method is used, and for the customer relationship management tool, an application programming interface (API) call method is used.

[0056] Send a data write request to the target system, along with the converted data, and wait for the target system to return a write confirmation;

[0057] After receiving write confirmations from all target systems, the status field of the corresponding business entity in the business data lake is updated, changing the status from "processing" to "synchronized," thus completing the closed-loop update of the business status.

[0058] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0059] The purified production data set, market data set, and logistics data set are imported into a unified business data lake. In the business data lake, cross-source associations are performed on business entities from different source systems, establishing logical mapping relationships between production work orders, sales orders, and purchase contracts, generating a business object association graph. The separate production, market, and logistics business data form a global association structure, the correspondence between different business entities is fully sorted out, the association status of cross-source business data is intuitively presented, the isolated state of data within a single system is broken, and the correspondence logic between business entities is fully solidified.

[0060] Based on the business object association graph, a multi-dimensional data cube is constructed, including dimensions such as time period, organizational department, product category, and business stage. Drill-down, rotation, and slicing operations are performed on the multi-dimensional data cube to extract key business indicators that support collaborative decision-making, forming a collaborative decision indicator set. The setting of analysis dimensions is aligned with the management needs of business collaboration, and multi-dimensional operations can directly reach the core analysis needs of business collaboration. The extraction path of key business indicators is more compatible with business collaborative decision-making, and the collaborative decision indicator set directly matches the indicator application scenarios of business collaborative management. The targeting of analysis operations and indicator extraction is enhanced. Attached Figure Description

[0061] Figure 1 This is a sequence diagram of the business collaborative management system based on multi-dimensional data fusion as described in this invention;

[0062] Figure 2 A flowchart illustrating the process of building a business data lake;

[0063] Figure 3 A flowchart of the process of constructing a multidimensional data cube;

[0064] Figure 4 A comparison chart of core decision-making indicators and thresholds for each region;

[0065] Figure 5 This is a line graph for 24-hour system performance monitoring. Detailed Implementation

[0066] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0067] In the description of this invention, it should be understood that the terms "length," "width," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships, are based on the orientation or positional relationships shown in the accompanying drawings and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, in the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0068] See Figure 1 The data extraction module connects to the Enterprise Resource Planning (ERP) system, Customer Relationship Management (CRM) tools, and Supply Chain Management (SLM) platform to extract business master data, forming production, market, and logistics data sets. The data cleaning module cleans these sets, removing duplicate records and outliers to obtain purified production, market, and logistics data sets. The association and fusion module imports these purified sets into a unified business data lake. Within this lake, cross-source associations are established between business entities from different source systems, creating logical mappings between production work orders, sales orders, and purchase contracts, generating a business object association graph. The analysis cube module constructs a multidimensional data cube based on this association graph, with dimensions including time period, organizational department, product category, and business stage. The collaborative decision-making module performs drill-down, rotation, and slicing operations on the multidimensional data cube to extract key business indicators supporting collaborative decision-making, forming a collaborative decision-making indicator set. Through the coordinated operation of the above modules, the system integrates, correlates, and performs in-depth analysis of multi-source business data to support cross-departmental business decision-making.

[0069] In one embodiment of the present invention, the data cleaning module performs cleaning operations on production data sets extracted from an enterprise resource planning system, market data sets extracted from a customer relationship management tool, and logistics data sets extracted from a supply chain management platform. The data cleaning module's processing combines specific business rules with data quality verification logic. In some embodiments, for the production data set, the system performs a uniqueness check on the work order number. The system scans all records in the production data set and extracts the production work order number field for each record. The system maintains a hash set of known work order numbers for quick duplicate lookup. When the system encounters a new production work order number, it adds it to the hash set; when the system encounters a production work order number already existing in the hash set, the corresponding record is marked as "pending deletion." In practice, the production dataset contains three production work order numbers: "P-20250320001", "P-20250320002", and "P-20250320001". The system marks the "P-20250320001" record as a duplicate in the second and third records (assuming sequential scanning). After marking duplicates, the system sorts all records not in the "to be deleted" state in ascending order based on their production timestamp field. The sorted records provide temporal continuity for subsequent processing. It can be understood that the calculation of uniqueness verification can be formalized, for example, by calculating the uniqueness score of the production work order numbers in the record set, using the formula:

[0070] ;

[0071] Where: symbol The uniqueness score is represented by the symbol. This indicates the number of records marked as "pending deletion". This indicates the total number of records in the production dataset.

[0072] In its implementation, the system standardizes the format of customer contact information for the market dataset. The system reads each record in the market dataset, locating the customer contact number field. The system has a pre-built library of regular expression patterns for global international dialing codes. For each customer contact number, the system attempts to match it against the pattern library. If a match is found, it is converted to a standard format; for example, "13800138000" or "086-13800138000" is uniformly converted to "+86-13800138000". If a customer contact number cannot be successfully parsed by any predefined pattern, for example, if it contains a large number of non-numeric characters or its length severely violates telephone number specifications, the system marks the entire record as "invalid" and removes it from the purified market dataset. In essence, the format standardization process unifies heterogeneous contact data into a standardized, structured representation.

[0073] In practical implementation, the system performs a logical check on the waybill status for the logistics dataset. The system iterates through the logistics dataset, searching for records where the waybill status field is "signed for." For each record with a "signed for" status, the system checks if its waybill signing time field is null or an invalid date value. If the waybill signing time field is null, the system marks the record as "abnormal." Next, based on the waybill number of the abnormal record, the system queries the historical waybill status table in the business data lake to obtain the most recent record for that waybill number that is not in a "signed for" status, along with its timestamp. Using the retrieved historical status and time information, the system attempts to infer and correct the waybill signing time of the current abnormal record, for example, by using a reasonable delivery cycle after the historical status change time as the estimated signing time.

[0074] In practice, the system merges the production, market, and logistics data sets after their independent processing. The merging operation is performed using a temporary full business data table structure containing all fields from the three data sets. The system performs a full outer join operation to generate a temporary full business dataset. Subsequently, the system handles null fields in the temporary full business dataset. Different filling strategies are used based on the field's data type and business meaning: for numeric metric fields, the average value within the same dimension is used; for categorical descriptive fields, the "unknown" identifier is used. This null filling process ensures the integrity of the dataset in subsequent analysis.

[0075] In one embodiment of the present invention, see [reference] Figure 2 The data import and modeling module performs data fusion operations. The business data lake is constructed using a star schema, with business entity identifiers serving as the common dimension connecting all data. In implementation, the business data lake comprises a core fact table and multiple dimension tables. The fact table stores measurable numerical data (measures), while the dimension tables store descriptive attributes, including time-period, organizational-department, product-category, and business-stage dimension tables. The time-period dimension table includes hierarchical fields such as year, quarter, month, and day; the organizational-department dimension table includes fields such as department code, department name, and parent department; the product-category dimension table includes fields such as category code, category name, and product line; and the business-stage dimension table includes fields such as stage code and stage name. The fact table and dimension tables are connected via foreign keys, forming a model structure centered on the fact table with the dimension tables radially distributed.

[0076] In some embodiments, the system loads the purified production data set into the business data lake. The system reads each record in the purified production data set, extracts the metric fields, such as the "daily output" value "850" and the "actual working hours" value "16.5", and writes them into the corresponding "output" and "working hours" fields in the fact table. Simultaneously, the system extracts dimensional attribute information from the same record, such as the "production workshop" string "Workshop A" and the "shift" string "night shift", obtains the corresponding "organizational department key" by searching and matching in the organizational department dimension table, and associates this key value with the metric record just written to the fact table. In practice, the loading of the purified market data set follows a similar logic. The system writes the "Order Amount" value "12500.00" and the "Payment Amount" value "10000.00" as measures into the fact table, and extracts the "Sales Region" string "East China Region" and the "Customer Level" string "VIP" from the records. The former is used to find a match in the organizational department dimension table to obtain a foreign key, and the latter is used to find a match in the product category dimension table to obtain another foreign key. The loading process for the purified logistics data set is similar. The system writes the "Shipping Weight" value "2.5" and the "Transit Days" value "3" as measures into the fact table, and obtains the associated foreign key value in the organizational department dimension table through the "Carrier" string "XX Logistics".

[0077] In practical implementation, after data is loaded into the business data lake, the association and fusion module performs cross-source associations on business entities from different source systems within the business data lake. The system performs the first type of association using the product code in the business data lake as the primary key. Product codes may have heterogeneous representations in different datasets, such as "Prod_Internal_A1001" in the production dataset and "P-A1001-STD" in the market dataset. The system uses a predefined coding mapping rule table to match product specification information records in the production dataset with product description information records in the market dataset. Successfully matched records together constitute a complete information view of a product entity, i.e., the product master data view. The system performs a second type of association using customer codes from the business data lake as foreign keys. Customer codes serve as the link between marketing and logistics activities. Through the customer code field, the system connects the sales order record with customer code "CUST2024001" in the marketing data set with all delivery order records in the logistics data set that share the same customer code "CUST2024001," creating a customer fulfillment view showing the entire process from order placement to delivery. The system performs a third type of association using project numbers from the business data lake as the association key. Project numbers can be used across production and financial management. Through the project number field, the system connects the production work order record with project number "Proj_2024_FY01" in the production data set with the project budget record synchronized from the financial system interface and sharing the same project number "Proj_2024_FY01," creating a project cost view that tracks project cost consumption.

[0078] In some embodiments, the system merges the separately established product master data view, customer fulfillment view, and project cost view to generate a business object association graph. The merging process connects common business entity nodes in the views; for example, a product node may appear in both the product master data view and the project cost view, and the system identifies it as the same node and merges them. It can be understood that the construction of the business object association graph can be achieved through a node-edge relationship merging algorithm in graph computing, and the completeness of the merging operation can be measured by the association fusion degree. The formula for calculating the association fusion degree R is:

[0079] ;

[0080] Where: symbol Indicates the degree of correlation and integration, symbol This represents the number of business entity nodes from different sources that were successfully merged in the final business object association graph, with the symbol [symbol missing]. This represents the total number of all business entity nodes to be merged. The final generated business object association graph is stored in the form of a graph structure, where nodes represent business entities and edges represent relationships between entities. This structure can explicitly store and express complex many-to-many relationships between business entities.

[0081] In one embodiment of the present invention, see [reference] Figure 3 The Analysis Cube module constructs a multidimensional data cube based on a business object association graph. Nodes in the business object association graph, such as a specific product entity "P-A1001-STD" or a customer entity "CUST2024001," are directly mapped to the basic analysis units of the multidimensional data cube. In implementation, the system defines time period, organizational department, product category, and business stage as four fixed analysis dimensions of the multidimensional data cube, and establishes a hierarchical structure for each dimension. The hierarchical structure of the time period dimension includes levels of "year," "quarter," "month," and "day." For example, the date "2024-03-20" aggregates upwards to "March 2024," then upwards to "First Quarter of 2024," and finally to "2024." The hierarchical structure of the organizational department dimension includes levels of "company," "business unit," "department," and "team." The hierarchical structure of the product category dimension includes levels of "product line," "series," and "model." The hierarchical structure of the business stage dimension includes levels such as "leads", "opportunities", "orders", "deliveries", and "payments". These hierarchical structures define the aggregation path of data from details to summaries.

[0082] In some embodiments, the system selects metrics from the fact table of the business data lake as metrics for the multidimensional data cube. These selected metrics include production completion rate, sales achievement rate, and inventory turnover rate. The system calculates these metrics based on business rules. For example, the production completion rate for a specific product on a specific date is calculated as the actual quantity completed that day divided by the planned production quantity; the sales achievement rate is calculated as the actual sales revenue divided by the target sales revenue; and the inventory turnover rate is calculated as the cost of sales divided by the average inventory level. These calculated metrics are then populated into cells of the multidimensional data cube defined by the coordinates of each dimension. In a specific implementation, the system pre-calculates the multidimensional data cube using online analytical processing (OLAP). The pre-calculation aggregates metrics upwards along the hierarchical structure of each dimension, generating aggregated data blocks at different granularities. For example, the system pre-calculates the sum of sales achievement rates for "Q1 2024," "East China Business Unit," and "Product Line A" across all business stages and stores this result as an aggregated data block for quick querying.

[0083] In practice, the collaborative decision-making module performs drill-down, rotation, and slicing operations on the multidimensional data cube in response to user requests. The module receives analysis requests from users, which are passed in using Structured Query Language (SCL) or graphical conditions, containing specified analysis dimensions and filtering conditions. For example, an analysis request might have dimensions of "time period" and "product category," with filtering conditions such as "organizational department = 'East China Sales Department'" and "business stage = 'order'". Based on the analysis request, the collaborative decision-making module locates the corresponding aggregated data block within the multidimensional data cube. If a user initially requests to view sales data for "Q1 2024" and then initiates a drill-down operation to view details for "March 2024," the collaborative decision-making module performs the drill-down operation, retrieving the detailed data constituting the high-level aggregated data block for "Q1 2024" from the lower-level aggregated data block storing the "March 2024" data. In essence, the drill-down operation expands the details downwards along the hierarchical structure of dimensions.

[0084] In some embodiments, if a user's analysis request requires a change in the analytical perspective, the collaborative decision-making module performs a rotation operation. For example, an initial crosstab might display sales achievement rates with "time period" as the row dimension and "product category" as the column dimension. The rotation operation swaps the row and column dimensions, adjusting "product category" to a row and "time period" to a column, thus presenting the same metric data from different perspectives. If the user's analysis request includes restrictions on the values ​​of a specific dimension, the collaborative decision-making module performs a slicing operation. For example, if a user requests to analyze all data where "product category = 'high-end series'", the collaborative decision-making module will slice out a sub-cube from the complete cube, where the "product category" dimension is fixed to "high-end series". This sub-cube only contains data related to the other three dimensions. In specific implementations, the dataset obtained after the operation is a set of metrics under a specific combination of dimensions. The system then performs secondary processing according to predefined indicator calculation rules. This secondary processing may involve compound operations on multiple metrics; for example, calculating the "sales expense ratio" metric requires dividing the "sales expense" metric by the "sales revenue" metric. The collaborative decision-making module organizes the processing results into a collaborative decision-making indicator set, which contains information such as indicator name, value, and related dimension context in list form.

[0085] In one embodiment of the present invention, the task engine module inputs the collaborative decision-making indicator set generated by the collaborative decision-making module into a workflow engine. In a specific implementation, the workflow engine loads a pre-built business rule base, which is stored in the form of an extensible markup language or database table. This business rule base defines the mapping relationship between different indicator thresholds and specific business actions. For example, one rule defines that when "inventory turnover rate is lower than threshold X", the triggered business action is "generate a procurement early warning task," and another rule defines that when "sales achievement rate is higher than threshold Y", the triggered business action is "generate a customer follow-up task." Table 1 below shows a simplified example of a business rule base mapping representation:

[0086] Table 1: Partial Mapping Table of Business Rule Base

[0087]

[0088] In practice, the workflow engine iterates through each indicator in the collaborative decision-making indicator set. For example, it reads the indicator "East China Inventory Turnover Rate" and its actual value "1.8," comparing the actual value "1.8" with the threshold condition "<2.0" corresponding to the "Inventory Turnover Rate" indicator in the business rule base. Since the actual value "1.8" meets the condition of "less than 2.0," the workflow engine triggers the "Generate Procurement Warning Task" business action mapped in the rule base. Based on the triggered business action, the workflow engine instantiates a specific pending task. The pending task contains structured fields such as task description, task responsible person, task deadline, and task input data. The task description might be "Generate a procurement warning for product P-A1001." The task responsible person is automatically assigned to the procurement department's interface person from the organizational structure. The task deadline is preset to the next 24 hours based on the rules. The task input data includes the indicator context data that triggered this task. The workflow engine pushes this instantiated pending task into a first-in, first-out pending task queue. In some embodiments, the workflow engine performs dependency analysis on all tasks in the task queue. Dependencies are predefined by business rules; for example, the "Generate Sales Report" task must be executed after the "Daily Settlement Completed" task. The system scans the task queue, and if it finds that a task's predecessor has not been completed or its status is not "Completed," it sets the task's status to "Suspended" until its predecessor is completed. It is understood that the processing efficiency of the task queue can be evaluated using average response time. The calculation formula is:

[0089] ;

[0090] Where: symbol The symbol represents the average response time of the pending task queue. Indicates the number of tasks completed within the statistical period, symbol Indicates the first The timestamp of when each task started execution, symbol Indicates the first The timestamp of each task entering the task queue.

[0091] In practice, the resource scheduling module parses the resource requirements for task execution from the pending task queue. It reads the structured information of the task at the head of the queue and extracts the resource requirements from the task description and task type fields. The task type field clearly identifies whether the task belongs to "data report generation," "batch data processing," or "interface call." Based on the parsed resource requirements, the resource scheduling module locks the corresponding computing and storage resources in a global resource pool, forming a resource scheduling list. The resource pool records the real-time status and performance attributes of all available computing nodes and storage volumes. For "data report generation" tasks, the resource scheduling module prioritizes allocating computing nodes with high-concurrency query processing capabilities; for "batch data processing" tasks, it prioritizes allocating computing nodes equipped with large-capacity persistent storage volumes. The resource scheduling module sets resource locks for the selected computing nodes and storage volumes. These locks exist as records, including the lock holder, the locked resource identifier, and the expected release time. The validity period of the resource lock is consistent with the deadline field value of the currently processed pending task to prevent allocated resources from being preempted by other tasks during task execution. The resource scheduling module combines the selected compute node identifier, storage volume identifier, and resource lock information into a resource scheduling list, and uniquely binds this resource scheduling list to the corresponding pending task in the pending task queue.

[0092] In some embodiments, the data tracing module performs operations after the business status closed-loop update is completed. This update is achieved by the resource scheduling module driving the enterprise resource planning system, customer relationship management tools, and supply chain management platform to perform data write-back. After successful write-back confirmation, the data tracing module archives relevant historical business data snapshots in the business data lake, migrating the snapshot data from the online analytical processing storage area to a lower-cost offline archiving storage area. Simultaneously, the data tracing module generates a structured data lineage tracing record, stored as log entries, containing three core parts: data source, processing procedure, and target system. The data source field records the original collaborative decision-making indicator and its value that triggered this closed-loop update; the processing procedure field records the complete workflow instance identifier from task generation, resource scheduling to data write-back; and the target system field records a list of downstream system names where the data was successfully written back. In essence, each data lineage tracing record uniquely identifies a complete data flow closed loop from analytical decision-making to execution feedback.

[0093] See Figure 4 This is a comparison chart of core decision-making indicators and thresholds for each region, showing the performance of inventory turnover rate, sales achievement rate, and production completion rate in East China, North China, South China, Southwest China, and Northwest China. East China (1.80), South China (1.95), and Northwest China (1.70) are below the threshold of 2.0, requiring a procurement warning task to be triggered. East China (1.25) and South China (1.32) are above the threshold of 1.2, requiring a high-value customer follow-up task to be triggered. East China (0.82) and Southwest China (0.79) are below the threshold of 0.85, requiring a production line equipment status inspection task to be triggered. In North China, all three indicators are within the safe range of the thresholds, and the production completion rate (0.88) is the highest in the entire region. In East China, warnings for inventory turnover rate, sales achievement rate, and production completion rate are triggered simultaneously. The Southwest region had the highest inventory turnover rate (2.30) but the lowest production completion rate (0.79); the South China region had the highest sales achievement rate (1.32) and its inventory turnover rate was close to the threshold.

[0094] In one embodiment of the present invention, the resource scheduling module parses the resource requirements for task execution from the pending task queue, and reads task entries in the ready state from the pending task queue. Each pending task entry contains a structured task description field and a task type field. The resource scheduling module parses the task description text of the pending task and identifies the task type through natural language processing or predefined keyword matching rules. In a specific implementation, one task in the pending task queue is described as "Generate sales analysis charts for the first quarter of 2024 in East China," and the system identifies its task type as "data report generation" after parsing; another pending task is described as "Batch update customer levels according to the new discount strategy," and the system identifies its task type as "Batch data processing" after parsing; a third pending task is described as "Call the ERP interface to update the work order status," and the system identifies its task type as "interface call." It can be understood that the task type is the core basis for determining the resource allocation strategy.

[0095] In some embodiments, based on the identified task type, the resource scheduling module queries the resource pool for available compute nodes and storage volumes. The resource pool maintains a list of available resources, recording the processing capacity attributes of each compute node and the capacity attributes of each storage volume. For a pending task with the task type "data report generation," the resource scheduling module's query logic prioritizes compute nodes with high-concurrency online transaction processing capabilities, such as the compute node with the node configuration identifier "OLAP_Node_01," whose attributes show support for more than 100 concurrent query connections. For a pending task with the task type "batch data processing," the resource scheduling module's query logic prioritizes compute nodes mounted with large-capacity storage volumes, such as the compute node with the node identifier "Batch_Node_05," whose associated storage volume attributes show a remaining capacity of more than 10TB. The resource scheduling module selects the compute node and one or more storage volumes from the query results that best meet the requirements of the task type. In implementation, the resource scheduling module sets resource locks for selected compute nodes and storage volumes. A resource lock is a record containing a locked resource identifier, a locked task identifier, a locked timestamp, and an expected release timestamp. The validity period of the resource lock is consistent with the deadline field value of the currently processed pending task. For example, if the deadline field value of a pending task is "2024-03-21 18:00:00", then the expected release timestamp of the resource lock set for allocating resources to it is also set to "2024-03-21 18:00:00". The resource lock mechanism prevents allocated resources from being preempted by other tasks during task execution. The resource scheduling module combines the selected compute node identifier, storage volume identifier, and generated resource lock record information into a resource scheduling list. The resource scheduling list uses JavaScript object notation format, and a unique identifier for this resource scheduling list is written into the "Resource Binding" field of the corresponding pending task entry, completing the binding between the resource scheduling list and the pending task. The robustness of the resource lock can be evaluated using a timeout tolerance coefficient. The calculation formula is:

[0096] ;

[0097] Where: symbol Represents the timeout tolerance coefficient, symbol Indicates the actual release timestamp of the resource lock, symbol Indicates the expected release timestamp of the resource lock, symbol This indicates the estimated duration for the execution of the pending task plan.

[0098] In implementation, the resource scheduling module drives data write-back through the enterprise resource planning system, customer relationship management tools, and supply chain management platform via a resource scheduling list. The module reads the pending tasks bound to the resource scheduling list and extracts the business entity identifier from the "task input data" field of each task. This identifier might be a sales order number "SO-20240320001" or a production work order number "WO-20240315078". Using this business entity identifier as a key, the module queries the current fact table in the business data lake to locate a snapshot of the latest state of that business entity. This snapshot contains the fields and their values ​​that need to be synchronized to downstream systems. In practice, the resource scheduling module converts the data in the business data snapshot into an interface protocol format recognizable by the target system. For the enterprise resource planning system, the conversion uses an intermediate table exchange method. The system maps the fields in the data snapshot to a predefined database intermediate table structure and generates standard Structured Query Language (SCL) insert or update statements. For CRM tools, the transformation uses an application programming interface (API) call. The system encapsulates the fields in the data snapshot into a request body that conforms to the CRM tool's open API specification, such as a JavaScript object representation. The resource scheduling module sends a data write request, carrying the transformed data, to the target system via the enterprise intranet or a secure channel. After sending, the resource scheduling module waits for the target system to return a write confirmation response. The response typically includes a processing status code, such as "200 OK" for success and "500 Internal Server Error" for failure.

[0099] See Figure 5 This is a 24-hour system performance monitoring line chart, tracking three core metrics: CPU utilization, memory utilization, and response time, used to assess system load and service stability. CPU utilization peaked at hour 6 (approximately 79%) and hour 24 (approximately 75%), with troughs at hour 9 (approximately 40%) and hour 18 (approximately 44%), exhibiting high-frequency fluctuations without sustained high load or continuous idle periods. Memory utilization peaked at hour 9 (approximately 81%) and hour 24 (approximately 79%), with troughs at hour 6 (approximately 51%) and hour 18 (approximately 53%), showing an inverse trend to CPU utilization, reflecting resource scheduling characteristics. Response time remained consistently at an extremely low level of 0-2 seconds, without significant spikes or abnormal fluctuations, indicating that the system maintained stable responsiveness even under high load.

[0100] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A business coordination management system based on multi-dimensional data fusion, characterized in that, The system includes: The data extraction module extracts business master data from the enterprise resource planning system, customer relationship management tools, and supply chain management platform to form production data sets, market data sets, and logistics data sets. The data cleaning module cleans the production data set, the market data set, and the logistics data set, removing duplicate records and outliers to obtain the cleaned production data set, the cleaned market data set, and the cleaned logistics data set. The association and fusion module imports the purified production data set, the purified market data set, and the purified logistics data set into a unified business data lake. In the business data lake, cross-source associations are performed on business entities from different source systems, establishing logical mapping relationships between production work orders, sales orders, and purchase contracts, and generating a business object association graph. The analysis cube module constructs a multidimensional data cube based on the business object association graph. The dimensions of the multidimensional data cube include time period, organizational department, product category and business stage. The collaborative decision-making module performs drill-down, rotation, and slicing operations on the multidimensional data cube to extract key business indicators that support collaborative decision-making, forming a collaborative decision-making indicator set.

2. The multi-dimensional data fusion based business collaboration management system as claimed in claim 1, wherein, Data cleaning is performed on the production data set, the market data set, and the logistics data set, including: The uniqueness of the work order numbers in the production data set is verified, records with duplicate work order numbers are marked as to be deleted, and the remaining records are sorted based on production time. The customer contact information in the market data set is standardized in format, non-standard contact information is converted into a unified international area code format, and records that cannot be parsed are removed; Logical checks are performed on the status of waybills in the logistics data set. Waybills with a status of "signed" but no signature time are marked as abnormal, and their historical status is queried in the business data lake based on the waybill number for repair. The three processed datasets are merged to generate a temporary full business dataset, and null values ​​are filled into the temporary full business dataset.

3. The business collaborative management system based on multi-dimensional data fusion as described in claim 2, characterized in that, The purified production data set, purified market data set, and purified logistics data set will be imported into a unified business data lake, including: The business data lake is constructed using a star schema, with business entity identifiers as the common dimension. In the business data lake, fact tables and dimension tables are defined, wherein the fact tables are used to store metrics, and the dimension tables are used to store attributes such as the time period, the organizational department, the product category, and the business stage. The output and working hours metrics from the purified production data set are loaded into the fact table, and the corresponding production workshop and shift information are associated with the organizational department dimension table. The sales and cash collection metrics from the purified market data set are loaded into the fact table, and the corresponding sales regions and customer level information are associated with the organizational department dimension table and the product category dimension table. The shipment volume and transit time values ​​from the purified logistics data set are loaded into the fact table, and the corresponding carrier and warehouse information are associated with the organizational department dimension table.

4. The business collaborative management system based on multi-dimensional data fusion as described in claim 3, characterized in that, In the business data lake, cross-source associations are performed on business entities from different source systems, including: Using the product code in the business data lake as the primary key, the product specification information in the production data set is matched with the product description information in the market data set to establish a product master data view; Using the customer code in the business data lake as a foreign key, sales orders in the market data set and delivery orders in the logistics data set are linked to establish a customer fulfillment view; Using the project number in the business data lake as the association key, the production work orders in the production data set are associated with the project budget in the financial system to establish a project cost view; The product master data view, customer fulfillment view, and project cost view are merged to form the business object association graph, which stores the many-to-many relationships between business entities in the form of a graph structure.

5. The business collaboration management system based on multi-dimensional data fusion as described in claim 4, characterized in that, Based on the aforementioned business object association graph, a multidimensional data cube is constructed, including: The nodes in the business object association graph are used as the basic analysis units of the multidimensional data cube; The time period, the organizational department, the product category, and the business stage are used as the four dimensions of the multidimensional data cube, and a hierarchical structure is established for each dimension, wherein the time period dimension includes the levels of year, quarter, month, and day. The metrics of the fact table in the business data lake are used as the metrics of the multidimensional data cube, including production completion rate, sales achievement rate and inventory turnover rate; Online analytical processing (OLAP) technology is used to pre-compute the multidimensional data cube to generate aggregated data blocks.

6. The business collaborative management system based on multi-dimensional data fusion as described in claim 5, characterized in that, Drilling, rotating, and slicing operations are performed on the multidimensional data cube, including: Receive analysis requests initiated by users, the analysis requests containing specified analysis dimensions and filtering conditions; According to the analysis request, the corresponding aggregated data block is located in the multidimensional data cube. If the analysis request involves more granular data, a drill-down operation is performed to obtain detailed data of the higher-level aggregated data block from the lower-level aggregated data block. If the analysis request requires a change in the analysis perspective, a rotation operation is performed to swap the row and column dimensions in the multidimensional data cube; If the analysis request includes restrictions on the values ​​of a specific dimension, a slicing operation is performed to cut a sub-cube from the multidimensional data cube; The dataset obtained after the operation is further processed according to the predefined index calculation rules to generate the collaborative decision-making index set.

7. The business collaborative management system based on multi-dimensional data fusion as described in claim 6, characterized in that, The system also includes: The task engine module inputs the collaborative decision indicator set into a workflow engine, which converts the indicators into tasks according to predefined business rules and generates a queue of tasks to be done. The resource scheduling module parses the resource requirements for task execution from the task queue and locks the corresponding computing and storage resources in the resource pool based on the resource requirements to form a resource scheduling list. The resource scheduling list drives the enterprise resource planning system, the customer relationship management tool and the supply chain management platform to write back data, thereby realizing a closed-loop update of business status. The data traceability module archives the historical data in the business data lake after the business status closed-loop update is completed, and generates a data lineage traceability record, which includes the data source, processing process and target system.

8. The business collaborative management system based on multi-dimensional data fusion as described in claim 7, characterized in that, Inputting the collaborative decision-making indicator set into a workflow engine includes: A pre-built business rule base is loaded into the workflow engine. The business rule base defines the mapping relationship between different indicator thresholds and business actions. Iterate through each indicator in the collaborative decision-making indicator set, compare the actual value of the indicator with the threshold in the rule base, and trigger the corresponding rule when the actual value of the indicator exceeds the threshold range. Based on the triggered rules, generate a pending task containing a task description, the person in charge of the task, the task deadline, and the task input data, and push the pending task into the pending task queue. Dependency analysis is performed on the tasks in the pending task queue. If there are pending tasks with incomplete prerequisite tasks, their status is set to suspended.

9. The business collaborative management system based on multi-dimensional data fusion as described in claim 8, characterized in that, The resource requirements for task execution are parsed from the task queue, and corresponding computing and storage resources are locked in the resource pool based on these requirements, including: The task description of the pending task is parsed to identify the task type, which includes data report generation, batch data processing, and interface calls. Based on the task type, available compute nodes and storage volumes are queried in the resource pool. Among them, data report generation tasks are given priority to compute nodes with high concurrency processing capabilities, and batch data processing tasks are given priority to nodes with large-capacity storage volumes. Set resource locks for the selected compute nodes and storage volumes. The validity period of the resource locks is consistent with the deadline of the pending tasks to prevent resources from being preempted by other tasks. The selected compute nodes, storage volumes, and resource lock information are combined into the resource scheduling list, and the resource scheduling list is bound to the corresponding pending tasks.

10. The business collaborative management system based on multi-dimensional data fusion as described in claim 9, characterized in that, Data write-back is driven by a resource scheduling list to the enterprise resource planning system, the customer relationship management tool, and the supply chain management platform, including: Read the pending tasks bound in the resource scheduling list, and locate the latest business data snapshot in the business data lake based on the business entity identifier in the task input data; The data in the business data snapshot is converted into an interface protocol format that the target system can recognize. For the enterprise resource planning system, an intermediate table exchange method is used, and for the customer relationship management tool, an application programming interface (API) call method is used. Send a data write request to the target system, along with the converted data, and wait for the target system to return a write confirmation; After receiving write confirmations from all target systems, the status field of the corresponding business entity in the business data lake is updated, changing the status from "processing" to "synchronized," thus completing the closed-loop update of the business status.

Images