In the field of B-end products, taking over unfamiliar business is an extremely challenging task. In the face of complex business processes and massive requirements, how to start from scratch, deeply analyze and output practical product solutions, is a skill that every B-end product manager must master. This article takes a chain retail enterprise as an example to show in detail how to start with the enterprise architecture, gradually disassemble the business process, identify key pain points, and finally transform it into specific product solutions.
In the previous article, we introduced the basic concepts of enterprise architecture, and in this article, we will take a look at specific practical case studies.
Let’s first use the example of a supermarket chain to introduce the analysis of enterprise architecture in detail.
Let’s first look at the business characteristics of retail supermarket chains from a macro perspective:
Chain retail is a typical feature of multi-channel and multi-system collaboration scenarios (offline stores + online malls + supply chains), with high complexity of business architecture and many data flow links, among which inventory turnover, order fulfillment, and supplier reconciliation are common pain points of all retail enterprises.
Focusing on this company, as a product manager who has just joined this company, how can we analyze this company from 0 and output the entire digital demand points?
Let’s take it step by step.
01 Dismantling the enterprise architecture: looking at the business with a magnifying glass
First of all, we need to analyze the business structure of this enterprise – draw a blueprint for the “business engine”.
The core process is disassembled, here we expand it step by step from top to bottom, and it is divided into L1-L4.
The company’s L1 process is as follows
Key pain points:
- Offline stores and online malls are independently managed, resulting in offline stocks and online out-of-stock during promotions
- Vendor reconciliation relies on manual Excel reconciliation with a monthly billing cycle of up to 15 days
Key points How to analyze these two key pain points from the L1 process?
- Inventory independent management problem: The “inventory allocation” node in the swimlane diagram is divided into two branches: stores and e-commerce warehouses, and there is no data return in the subsequent sales link, indicating that the offline and online inventory has not been opened. Combined with industry common sense (online and offline inventory synchronization during promotion is the core requirement), it is judged that this is the root cause of the performance chaos.
- Reconciliation relies on manual reconciliation: The end point of all business processes in the enterprise must be financial reconciliation, and the upstream after-sales link is not connected to the digital system (such as electronic invoices, automatic settlement), which will inevitably lead to manual intervention. Observe that there is no arrow in the flowchart for the system to automatically flow to further validate the issue.
02 L2 process disassembly: longitudinal analysis of core modules
On the basis of the L1 main process, according to these two pain points, the L2 process is dismantled for the three core modules of “inventory management”, “supply chain collaboration” and “financial reconciliation”:
Inventory management L2 level process
Supply chain collaborative L2 processes
03 Level L3/L4 process disassembly: granularity to system functional units
Inventory synchronization exceptions handle L3-L4 level processes
L3 level: Exception handling of cross-channel inventory synchronization
L4 level: The real-time synchronization function unit of store inventory
- Data collection layer: For every transaction completed by the POS machine, the deduction data is pushed to the middle office in real time through the message queue
- Data verification layer: Set the inventory alert threshold (safety stock = 3 days of sales), below which the replenishment reminder is automatically triggered
- Interface layer: Develop a unified inventory API interface (including inventory query/lock/release functions), define field specifications (e.g., available inventory = total inventory – locked inventory – inventory in transit)
- Visualization layer: Provides operators with an inventory variance dashboard to display indicators such as inventory variance rate and synchronization delay duration in real time
Supplier reconciliation level L3-L4 process
L3 level: the entire process of monthly reconciliation
L4 level: Triple single matching automation function unit
- OCR recognition module: Support PDF / image format statement parsing
- Rule Engine: Preset matching rules (e.g. order number + vendor code must be exactly the same, amount allowed ±0.1% error)
- Variance Processing Workbench: Automatically classifies by variance type (quantity mismatch, unit price difference, tax point error), and supports batch tagging
- Electronic signature system: Connect with CA certification bodies to realize the online confirmation function of statements, shortening the signing process by 3-5 days
04 Process breakpoint diagnosis checklist
Through the four-level process disassembly, the following process breakpoints are identified, which are managed according to the degree of impact:
This process is from business pain points to product solutions, and it can be seen that this table is around the core pain points, in response to the system fragmentation, inefficient collaboration, and manual dependence problems exposed in process disassembly, and design iterative solutions for the three core modules from a product perspective, establishing a clear mapping relationship of “pain points-modules-functions”.
Through this case, we can see that the transformation from enterprise architecture to product architecture is essentially translating the business language of the enterprise into the functional language of the product.
Through this closed-loop thinking of “problem→ analysis→ decision-making”, we can ensure that each design output is closely related to the actual pain points of the enterprise, while taking into account business feasibility and technology scalability.
Remember that product architecture is not about drawing a beautiful flowchart, but about using logical reasoning to make each module of the product answer “why it exists” and “what problem it solves”.
