Digital management method for small and medium-sized enterprises

Abstract

The invention provides a digital management method for small and medium-sized enterprises, which belongs to the technical field of digital management, and is characterized in that an extensible framework is constructed through integration of an open source ERP system and a low-code development platform, and modular configuration is realized in combination with enterprise scale parameters and business type parameters. The method comprises a main data management system based on a hybrid coding rule, a three-level data exchange system, a double-track digital governance mechanism and external system standardized interaction, and a technical debt management and control model and a disaster recovery test mechanism are introduced. According to the method, the problems of high digitalization cost, difficulty in customization, data islanding and the like of small and medium-sized enterprises are solved, low-cost rapid deployment, cross-platform data intercommunication, data quality controllability and service continuity guarantee are realized, and the digitalization management efficiency and the return on investment rate of the small and medium-sized enterprises are remarkably improved.

Description

Technical Field

[0001] The present invention relates to the field of digital management technology, and in particular to a digital management method for small and medium-sized enterprises. Background Art

[0002] With the rapid development of the digital economy, small and medium-sized enterprises are facing an urgent need for digital transformation. However, traditional ERP systems have the following pain points:

[0003] 1. High costs and long implementation cycles: The procurement costs and custom development fees of commercial ERP systems place a heavy burden on small and medium-sized enterprises, and the implementation cycle is long;

[0004] 2. Insufficient flexibility and scalability: Small and medium-sized enterprises (SMEs) face rapid business model iteration, and traditional closed systems struggle to adapt to rapidly changing needs.

[0005] 3. Data silos and quality defects: The lack of unified master data management standards leads to inconsistent data across departments, affecting decision-making efficiency;

[0006] 4. Risk of technical debt accumulation: Rapid iterative development is prone to code quality defects, and long-term operation leads to a surge in system maintenance costs;

[0007] 5. Weak disaster recovery capabilities: Small and medium-sized enterprises generally lack professional disaster recovery systems, and system failures can easily lead to business interruptions.

[0008] Existing technology solutions (such as single commercial ERP deployments) fail to strike a balance between cost, flexibility, and data governance. This invention, through the innovative integration of open source architecture and low-code technology, combined with a standardized governance model, provides a low-cost, highly scalable, and implementable digital solution for small and medium-sized enterprises. Summary of the Invention

[0009] In view of this, the object of the present invention is to provide a digital management method for small and medium-sized enterprises to at least solve the above problems.

[0010] The technical solution adopted in the present invention is as follows:

[0011] A digital management method for small and medium-sized enterprises, comprising the following steps:

[0012] Step 1: Based on enterprise scale parameters and business type parameter data, select an open source ERP system as the core management platform and integrate it with a low-code development platform to form a scalable digital infrastructure. The enterprise scale parameter data includes annual turnover range, number of employees, and IT personnel ratio. The business type parameter data includes classification identification of production, service, or trade.

[0013] Step 2: Within a preset time window after the digital infrastructure deployment is completed, configure a master data management tool to establish a master data management system that includes product data standards, customer data standards, and supplier data standards, and implement cross-platform data field-level mapping;

[0014] Step 3: Relying on business leaders and technical leaders to build a digital governance module, and use the digital governance module to implement and monitor the digital route of short-term implementation goals and long-term development plans.

[0015] Furthermore, in step one, the following steps are also included:

[0016] Step 1.1. Deploy the pre-determined version of the Odoo open source ERP system to activate at least the Procurement Management, Inventory Management, and Financial Accounting modules.

[0017] Step 1.2: Develop and build a customer analysis module on the low-code platform, and use the customer analysis module to analyze enterprise scale parameter data and business type parameter data;

[0018] Step 1.3: In the open source ERP system, a three-level data exchange system is established through a database direct connection channel, a business data interface, and an analytical data pipeline.

[0019] Furthermore, in step 2, the following steps are also included:

[0020] Step 2.1: Use a hybrid coding rule combining national standard coding and enterprise-defined coding for product data;

[0021] Step 2.2: Verify the quality of product data, customer data, and supplier data according to the integrity check rules, consistency check rules, and timeliness check rules in the master data management system;

[0022] Step 2.3: Record the operation log of the master data management system and set a predetermined retention period.

[0023] Furthermore, in step three, the following steps are also included:

[0024] Step 3.1: Implement a dual-track management mechanism for business leaders and technical leaders in the digital governance module;

[0025] Step 3.2: Regulate the digitalization route of short-term implementation goals and long-term development plans based on the ROI model.

[0026] Furthermore, it also includes:

[0027] Step 4: The open source ERP system interacts with external systems through standardized adapters, including:

[0028] Step 4.1: Deploy an API gateway that supports multi-protocol conversion at the enterprise network edge.

[0029] Step 4.2: Configure field-level data filtering rules and encrypted transmission mechanism;

[0030] Step 4.3: Establish an interface maintenance cost early warning model.

[0031] Furthermore, in step 4.1, the multi-protocol conversion includes:

[0032] Convert received EDI format supply chain data into JSON format;

[0033] Convert the SOAP interface of the external system to a RESTful interface.

[0034] Furthermore, it also includes:

[0035] Step 5: The open source ERP system uses the technical debt management module to manage technical debt, including

[0036] S51. Debt Assessment: Use the TRIZ contradiction matrix to assess technical debt every six months and identify three high-risk debt categories:

[0037] Outdated open source components;

[0038] Custom modules with missing documentation;

[0039] Interfaces with performance degradation exceeding 30%;

[0040] S52. Repayment Plan: Develop a four-quadrant disposal strategy:

[0041] Immediate repayment: debts that affect safety compliance;

[0042] Deadline for repayment: Debt that leads to severe inefficiencies;

[0043] Forbearance: Debts affecting only non-core functions;

[0044] Permanent acceptance: Debt where the cost of renovation exceeds the benefits.

[0045] Furthermore, it also includes:

[0046] Step 6: Establish a disaster recovery test emergency response mechanism through the open source ERP system, including:

[0047] Step 6.1: Construct test scenarios including server downtime, network outage, and database corruption.

[0048] Step 6.2: Develop a hierarchical business recovery strategy;

[0049] Step 6.3: Optimize business continuity documentation based on test results.

[0050] Compared with the prior art, the present invention has the following beneficial effects:

[0051] 1. Low-cost and rapid deployment:

[0052] By combining Odoo open source ERP with a low-code platform, system procurement costs were reduced by more than 80%, and the implementation cycle was shortened to within 3 months;

[0053] Modular activation mechanisms (such as procurement, inventory, and financial module presets) reduce the need for custom development and support gradual expansion according to business stages.

[0054] 2. Controllability of digital goals:

[0055] The dual-track management mechanism (business leader + technical leader) ensures the coordination of strategic goals and technical implementation, and reduces project deviation rates;

[0056] The return on investment model drives roadmap adjustments to improve the return on investment (ROI) of digitalization.

[0057] 3. Technical debt risk is controllable:

[0058] The TRIZ contradiction matrix identifies high-risk technical debt (such as expired components and interfaces with degraded performance) every six months, reducing the rate of debt accumulation;

[0059] The four-quadrant disposal strategy enables classified management of technical debt, shortening the repair cycle for emergency issues to within 72 hours. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only preferred embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0061] Figure 1 This is a schematic diagram of the overall process of a digital management method for small and medium-sized enterprises proposed in an embodiment of the present invention. DETAILED DESCRIPTION

[0062] The principles and features of the present invention are described below with reference to the accompanying drawings. The enumerated embodiments are only used to explain the present invention and are not used to limit the scope of the present invention.

[0063] Reference Figure 1 The present invention provides a digital management method for small and medium-sized enterprises, the method comprising the following steps:

[0064] Step 1: Based on enterprise scale parameters and business type parameter data, select an open source ERP system as the core management platform and integrate it with a low-code development platform to form a scalable digital infrastructure. The enterprise scale parameter data includes annual turnover range, number of employees, and IT personnel ratio. The business type parameter data includes classification identification of production, service, or trade.

[0065] Step 2: Within a preset time window after the digital infrastructure deployment is completed, configure a master data management tool to establish a master data management system that includes product data standards, customer data standards, and supplier data standards, and implement cross-platform data field-level mapping;

[0066] Step 3: Relying on business leaders and technical leaders to build a digital governance module, and use the digital governance module to implement and monitor the digital route of short-term implementation goals and long-term development plans.

[0067] Illustratively, the present invention provides a basis for the digital transformation path for small and medium-sized enterprises through parameterized decision-making, standardized tool chains and governance mechanisms. The present invention can select an open source ERP system based on enterprise scale parameter data and business type parameter data. The open source ERP system supports modular expansion and is low-cost. The integrated low-code platform can also provide a visual development interface. For the establishment of a master data management system, a master data management tool (such as Informatica MDM) can be deployed within 3 months after the ERP system goes online to establish three types of master data standards covering products, customers, and suppliers. The master data tool can be used to map the "product name" field of Odoo with the "SKU code" field of the e-commerce platform to ensure consistency of online and offline data. The business manager and the technical manager jointly build a digital governance module, and implement and monitor the digital route of short-term implementation goals and long-term development plans to control risks and avoid the accumulation of technical debt.

[0068] In step one, the following steps are also included:

[0069] Step 1.1. Deploy the pre-determined version of the Odoo open source ERP system to activate at least the Procurement Management, Inventory Management, and Financial Accounting modules.

[0070] Step 1.2: Develop and build a customer analysis module on the low-code platform, and use the customer analysis module to analyze enterprise scale parameter data and business type parameter data;

[0071] Step 1.3: In the open source ERP system, a three-level data exchange system is established through a database direct connection channel, a business data interface, and an analytical data pipeline.

[0072] For example, you can choose Odoo Community Edition as the benchmark deployment package. For example, for manufacturing companies with an annual turnover of 5 million to 200 million yuan and 50 to 200 employees, pre-activate the three core modules of procurement management, dynamic inventory counting, and financial accounting; build a customer analysis module based on the low-code platform, and use a decision tree algorithm to intelligently match the input enterprise size parameters (such as IT personnel ratio <5% triggers a simple interactive interface) and business type identification (service-oriented organizations automatically load project-based CRM templates). For example, after a trading company enters parameters such as annual turnover of 80 million yuan and 120 employees (including 3 IT personnel), the system automatically generates initial configuration suggestions, including "mobile approval priority" and "basic data analysis package." For direct database connections, a two-way connection between ERP and local Excel can be established via ODBC, supporting real-time import of production data. For business data interfaces, a RESTful API can be developed to synchronize orders with e-commerce platforms. For analytical data pipelines, Apache Kafka can be used to build a streaming data processing channel to support big data operations in the customer analysis module. This step forms a closed "deployment-analysis-interaction" loop: initial data generated by system deployment flows into the analysis module, and the analysis results are fed back to the business module through the data exchange system for optimization, forming a self-evolving digital management ecosystem.

[0073] In step 2, the following steps are also included:

[0074] Step 2.1: Use a hybrid coding rule combining national standard coding and enterprise-defined coding for product data;

[0075] Step 2.2: Verify the quality of product data, customer data, and supplier data according to the integrity check rules, consistency check rules, and timeliness check rules in the master data management system;

[0076] Step 2.3: Record the operation log of the master data management system and set a predetermined retention period.

[0077] For example, the mixed coding rules for product data can adopt a dual identification system of "national standard coding + enterprise customized coding". For example, an automotive parts company can mark its products as "GB / T3730.1-2001 (national standard classification code)" and "P-102-A (enterprise internal classification rules)" at the same time. This hybrid coding not only meets industry regulatory requirements but also retains the personalized management needs of enterprises, thus achieving a balance between supply chain collaboration and refined internal management of the enterprise; for the integrity check in the three-level data quality verification mechanism: the system automatically verifies whether mandatory fields (such as customer tax registration number and supplier bank account number) are missing, generates exception reports for missing items and triggers the re-entry process; consistency check: through algorithm comparison of key fields such as customer name and contact number from different data sources (such as ERP system and CRM system), it marks suspected duplicate data such as "Zhang Sanyue" and "Zhang San"; timeliness check: set data validity period rules, such as supplier qualification documents need to be updated every six months, and the system automatically warns of 32 supplier records that are about to expire; record master data management system can include: operation subject (account / IP address dual-dimensional records), operation type (addition, deletion, modification and query), and impact scope (accurate to field-level changes)

[0078] The log retention period can be set to three years, complying with the Electronic Signature Law's requirements for electronic evidence storage and providing a legal basis for data traceability and compliance audits. For example, if a supplier information leak is discovered through log tracing to be caused by unauthorized access by a former employee, legal action can be taken promptly.

[0079] In step three, the following steps are also included:

[0080] Step 3.1: Implement a dual-track management mechanism for business leaders and technical leaders in the digital governance module;

[0081] Step 3.2: Regulate the digitalization route of short-term implementation goals and long-term development plans based on the ROI model.

[0082] For example, the purpose of establishing a dual-track management mechanism is to establish a two-way collaborative channel for business goals and technology implementation, avoiding the communication gap between business departments and technical departments in the traditional management model. The business leader takes the lead in demand formulation and priority sorting, for example, adjusting the inventory warning threshold of a production enterprise based on market forecasts; the technical leader is responsible for evaluating the technical feasibility and implementation cost, for example, the manpower and time cost required to develop a customer analysis module on a low-code platform. Both parties jointly formulate short-term goals (such as launching a supplier collaboration module within 3 months) and long-term plans (such as building an AI demand forecasting system within 2 years), so as to ensure that technology investment always serves core business goals (such as improving customer retention rates of service-oriented enterprises) and avoid over-development of non-critical functions.

[0083] By regulating the return on investment (ROI) model, the economic benefits of digital projects can be quantified and resource allocation can be dynamically adjusted. The model is constructed with the following goals: short-term goals: calculating the direct benefits of module launch (e.g., 200 hours / month in labor costs saved by automated financial report generation); long-term planning: evaluating compound growth benefits (e.g., a 15% increase in customer lifetime value over three years from a customer data analytics module). Dynamic regulation: Positive feedback: If a module's ROI exceeds a threshold (e.g., ROI > 1.5 and payback period < 2 years), additional budget is allocated for expanded functionality (e.g., upgrading from basic CRM to AI customer profiling). Risk alerts are also provided. If the ROI falls short of expectations (e.g., customized development cost overruns), a technical debt assessment is triggered (see Claim 7), prioritizing the disposal of high-yield debt. For example, a trading company plans to deploy an intelligent pricing module with an initial ROI forecast of 1.8. However, due to data source quality issues, actual returns decline. The system automatically deprioritizes the module and prioritizes optimizing master data quality (Step 2.2).

[0084] This embodiment also includes:

[0085] Step 4: The open source ERP system interacts with external systems through standardized adapters, including:

[0086] Step 4.1: Deploy an API gateway that supports multi-protocol conversion at the enterprise network edge.

[0087] Step 4.2: Configure field-level data filtering rules and encrypted transmission mechanism;

[0088] Step 4.3: Establish an interface maintenance cost early warning model.

[0089] For example, for the deployment of a multi-protocol conversion API gateway, two API gateway servers serving as hot standby for each other can be deployed in the enterprise network boundary area, and gigabit network interface cards can be configured to handle high-concurrency requests. When receiving purchase orders sent by suppliers through the traditional EDI protocol, the gateway automatically converts the EDI UN / EDIFACT format into a JSON format data packet, and can encapsulate the SOAP interface of the external logistics system as a RESTful API, thereby achieving seamless docking with the Odoo system; for the configuration of field-level data, customer sensitive information (such as ID number) can be automatically replaced with a hash value during transmission, and the product unit price field is restricted to only allow numerical types with a precision of no more than decimal places. Two, you can use the TLS1.3 protocol to establish a secure channel, use the national secret SM4 algorithm to encrypt the transmitted data, manage the encryption key through the hardware security module (HSM), and realize the automation of the key life cycle; for the interface maintenance cost early warning model, you can monitor the three core indicators of API call number, average response time, and error rate in real time, and record the amount of data exchanged each time (such as XML file size, number of JSON fields). The early warning algorithm is as follows: when the API call volume exceeds 100,000 times in a single month or more than 5% of error requests are generated, a yellow warning is triggered, and a linear regression model is established to predict the traffic growth in the next three months. When the predicted value exceeds 80% of the current package capacity, an expansion recommendation is generated.

[0090] In step 4.1, multi-protocol conversion includes:

[0091] Convert received EDI format supply chain data into JSON format;

[0092] Convert the SOAP interface of the external system to a RESTful interface.

[0093] For example, for the data parsing layer of the EDI to JSON conversion module, EDI messages can be parsed through open source frameworks such as Apache Camel to extract key data segments of transaction sets such as purchase orders (850PO) and invoices (810Invoice) (such as PO1 order line items and N1 supplier information). For the semantic mapping layer, EDI data segments can be converted into JSON key-value pairs based on the predefined EDI-JSON Schema mapping table (for example, EDI's "PO110100*" can be mapped to JSON's {"line_item":1,"quantity":10,"unit_price":100}); for the format adaptation layer, data type conversion (such as converting EDI's implicit numeric format to JSON's explicit numeric type) and nested structure reorganization (such as converting EDI hierarchical segments to JSON object nesting) can be processed. The WSDL parsing engine of the SOAP to RESTful conversion module automatically parses the WSDL file provided by the external system and extracts available operations (Operation) and parameters (Message Part). For the request converter, the content in the SOAP Envelope can be parsed into XML The DOM tree extracts the operation name (such as GetCustomer) and parameters (such as CustomerID) and maps them to RESTful HTTP methods (GET / POST) and paths ( / api / customers / {id}). The response converter can convert the XML data in the SOAP response into JSON format and handle complex types (such as converting XML xsd:complexType into JSON Schema objects). For example, take the integration between a manufacturing company and its supplier system as an example:

[0094] EDI interaction scenario: Supplier sends EDI 850 purchase order via AS2 protocol;

[0095] After receiving the data, the API gateway extracts the material code, quantity, price and other data through the EDI parsing module, converts it into JSON format and writes it into the procurement management module of ERP;

[0096] After ERP processing is completed, the response data (such as order confirmation status) is converted back to generate an EDI 855 confirmation message and returned to the supplier.

[0097] SOAP interaction scenario: The external logistics system provides a SOAP interface to query the transportation status;

[0098] The API gateway converts the RESTful GET request ( / api / shipments?tracking_number=123) into the SOAP GetShipmentStatus operation, and after the call, converts the XML response into JSON and returns it to the front-end application.

[0099] This embodiment also includes:

[0100] Step 5: The open source ERP system uses the technical debt management module to manage technical debt, including

[0101] S51. Debt Assessment: Use the TRIZ contradiction matrix to assess technical debt every six months and identify three high-risk debt categories:

[0102] Outdated open source components;

[0103] Custom modules with missing documentation;

[0104] Interfaces with performance degradation exceeding 30%;

[0105] S52. Repayment Plan: Develop a four-quadrant disposal strategy:

[0106] Immediate repayment: debts that affect safety compliance;

[0107] Deadline for repayment: Debt that leads to severe inefficiencies;

[0108] Forbearance: Debts affecting only non-core functions;

[0109] Permanent acceptance: Debt where the cost of renovation exceeds the benefits.

[0110] Step S51: Debt assessment can be performed every six months. For the application of the TRIZ contradiction matrix, the 39 engineering parameters in TRIZ theory can be used to define technical debt contradictions (such as the conflict between "reliability" and "development speed"). The matrix can be used to recommend invention principles to solve the root causes of technical debt. For example, when it is detected that the open source component version is out of date and causes a security vulnerability, the "segmentation principle" is applied to decouple the core business module from the dependent library to achieve independent component upgrades. For high-risk debt identification, standard outdated open source components can be scanned using the OWASP Dependency-Check tool to identify components that have not been updated for more than 12 months, focusing on vulnerabilities with a CVE score of ≥7.0. For missing documentation, the CodeMR static analysis tool can be used to detect cases where the code comment coverage of custom modules is less than 30% and there is no API documentation. For performance-degraded interfaces, the P99 value of the interface response time can be monitored using Prometheus. An alarm is triggered when the benchmark test shows a performance degradation of >30% for 7 consecutive days. The repayment plan can be divided into the following categories:

[0111] Immediate Repayment (P0 priority) is applicable when a cryptographic component that impacts PCI-DSS compliance expires and requires a hotfix within 72 hours. This can be achieved through the Kubernetes rolling update mechanism, enabling zero-downtime upgrades and simultaneous updates to the infrastructure-as-code template.

[0112] The applicable scenario for the limited repayment (P1 priority): Database query interfaces (such as unoptimized Odoo ORM queries) that cause order processing delays of more than 2 hours must be completed within 2 iterations. The query logic can be restructured using the Materialize streaming database and performance verified through JMeter stress testing.

[0113] Deferred processing (P2 priority) applies to scenarios where documentation for custom JavaScript chart libraries that only affect the report generation module is missing, but an alternative solution (such as the ECharts migration plan) exists. You can create a "Technical Debt Dashboard" in Jira, mark it as "Planned", and assign it to the next fiscal year budget cycle.

[0114] Permanent Acceptance (P3 priority) decision criteria: When the reconstruction cost (estimated man-days × average hourly wage) is greater than 150% of the potential loss during the debt's life (Monte Carlo simulation results), for example, an EDI interface uses the legacy AS2 protocol. Converting to the AS4 protocol requires 640 man-days, while the annual potential loss is only ￥120,000 (cost-benefit ratio 5.3:1), the status quo is maintained and recorded in the technical debt register.

[0115] This embodiment also includes:

[0116] Step 6: Establish a disaster recovery test emergency response mechanism through the open source ERP system, including:

[0117] Step 6.1: Construct test scenarios including server downtime, network outage, and database corruption.

[0118] Step 6.2: Develop a hierarchical business recovery strategy;

[0119] Step 6.3: Optimize business continuity documentation based on test results.

[0120] For example, to construct multi-dimensional test scenarios, three typical failure scenarios can be simulated in an open source ERP system (such as Odoo):

[0121] Server downtime test: Use the Kubernetes cluster to simulate a primary server node failure to verify whether the PostgreSQL database's streaming replication high-availability architecture can complete active-standby switchover within 30 seconds.

[0122] Network interruption testing: Use the Traffic Control tool to simulate a network partition to verify whether core business modules (such as order processing) can continue to operate through local cache when the cross-data center network is interrupted.

[0123] Database corruption test: Injecting a corrupted WAL log file to trigger a PostgreSQL crash and verify whether the PITR (Point-in-Time Recovery) mechanism can recover data from the most recent baseline backup + WAL archive.

[0124] For a hierarchical business recovery strategy, a four-level response mechanism based on business impact analysis (BIA) can be used, as shown in the following table:

[0125]

[0126]

[0127] For example, when a database connection timeout (a level 1 event) is detected for Odoo’s manufacturing module, the system automatically performs the following actions: triggering a Zabbix alarm and notifying the IT manager;

[0128] Start the load balancer (Nginx) to switch traffic to the disaster recovery node;

[0129] Use Prometheus to monitor the recovery progress and perform database consistency checks after the RTO is met.

[0130] For dynamic optimization of disaster recovery documents, a closed-loop document iteration mechanism can be established:

[0131] Test result injection: Chaos Engineering test reports are automatically parsed into Markdown format and updated to the Disaster Recovery Test Matrix in GitLabWiki.

[0132] Key data example: Record the data consistency deviation rate of the order processing module within 15 minutes of database downtime in the 2023Q3 test of 0.03%.

[0133] Policy version control: Use Ansible Playbook to encode recovery strategies into executable scripts, manage versions through Git, and retain records of the last five major changes.

[0134] Emergency contact escalation: When a Level 3 incident is detected and remains unresolved for more than two hours, the PagerDuty escalation process is automatically triggered, notifying the CIO and activating the War Room.

[0135] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A digital management method for small and medium-sized enterprises, characterized in that: The method comprises the following steps: Step 1: Based on enterprise scale parameters and business type parameter data, select an open source ERP system as the core management platform and integrate it with a low-code development platform to form a scalable digital infrastructure. The enterprise scale parameter data includes annual turnover range, number of employees, and IT personnel ratio. The business type parameter data includes classification identification of production, service, or trade. Step 2: Within a preset time window after the digital infrastructure deployment is completed, configure a master data management tool to establish a master data management system that includes product data standards, customer data standards, and supplier data standards, and implement cross-platform data field-level mapping; Step 3: Relying on business leaders and technical leaders to build a digital governance module, and use the digital governance module to implement and monitor the digital route of short-term implementation goals and long-term development plans.

2. The method according to claim 1, characterized in that In step one, the following steps are also included: Step 1.

1. Deploy the pre-determined version of the Odoo open source ERP system to activate at least the Procurement Management, Inventory Management, and Financial Accounting modules. Step 1.2: Develop and build a customer analysis module on the low-code platform, and use the customer analysis module to analyze enterprise scale parameter data and business type parameter data; Step 1.3: In the open source ERP system, a three-level data exchange system is established through a database direct connection channel, a business data interface, and an analytical data pipeline.

3. The method according to claim 1, characterized in that In step 2, the following steps are also included: Step 2.1: Use a hybrid coding rule combining national standard coding and enterprise-defined coding for product data; Step 2.2: Verify the quality of product data, customer data, and supplier data according to the integrity check rules, consistency check rules, and timeliness check rules in the master data management system; Step 2.3: Record the operation log of the master data management system and set a predetermined retention period.

4. The method according to claim 1, wherein In step three, the following steps are also included: Step 3.1: Implement a dual-track management mechanism for business leaders and technical leaders in the digital governance module; Step 3.2: Regulate the digitalization route of short-term implementation goals and long-term development plans based on the ROI model.

5. The method according to claim 1, wherein Also includes: Step 4: The open source ERP system interacts with external systems through standardized adapters, including: Step 4.1: Deploy an API gateway that supports multi-protocol conversion at the enterprise network edge. Step 4.2: Configure field-level data filtering rules and encrypted transmission mechanism; Step 4.3: Establish an interface maintenance cost early warning model.

6. The method according to claim 5, characterized in that In step 4.1, multi-protocol conversion includes: Convert received EDI format supply chain data into JSON format; Convert the SOAP interface of the external system to a RESTful interface.

7. The method according to claim 1, characterized in that Also includes: Step 5: The open source ERP system uses the technical debt management module to manage technical debt, including S51. Debt Assessment: Use the TRIZ contradiction matrix to assess technical debt every six months and identify three high-risk debt categories: Outdated open source components; Custom modules with missing documentation; Interfaces with performance degradation exceeding 30%; S52. Repayment Plan: Develop a four-quadrant disposal strategy: Immediate repayment: debts that affect safety compliance; Deadline for repayment: Debt that leads to severe inefficiencies; Forbearance: Debts affecting only non-core functions; Permanent acceptance: Debt where the cost of renovation exceeds the benefits.

8. The method according to claim 1, characterized in that Also includes: Step 6: Establish a disaster recovery test emergency response mechanism through the open source ERP system, including: Step 6.1: Construct test scenarios including server downtime, network outage, and database corruption. Step 6.2: Develop a hierarchical business recovery strategy; Step 6.3: Optimize business continuity documentation based on test results.

Images