This article provides a dry tutorial from 0 basic to expert level for B-end product managers and system builders, focusing on how to identify and manage complex business rules. The article introduces in detail the definition, classification and importance of accurately identifying business rules, and shares a three-step method to structure and sort out business rules through practical cases to help readers overcome the problem of complex business rule identification.
In the previous lecture, we explained business modeling, and today we will continue to talk about the second major module of the complex system: business rule management and design.
01 What are business rules?
First of all, if we summarize it in one sentence: Business rules are the decision-making logic and constraints that must be followed by the operation of an enterprise, which defines how a system or person should act in a specific scenario.
Further, business rules are usually divided into the following three categories in the consulting industry:
– Explicit rule: contractual clause (“automatic shutdown for 30 consecutive days of arrears by the user”)
– Implicit rule: industry practice (“Customer service response time can be extended from 5 minutes to 15 minutes during the promotion period)
After 10 years of interaction design, why did I transfer to product manager?
After the real job transfer, I found that many jobs were still beyond my imagination. The work of a product manager is indeed more complicated. Theoretically, the work of a product manager includes all aspects of the product, from market research, user research, data analysis…
View details >
– Compound rule: Multi-condition superposition (“VIP users with an order amount of ≥ 1,000 yuan can get free shipping”)
The core of a business rule should include the following elements:
Trigger Condition (When/Who) + Behavior Definition (What) + Expected Outcome (Why/How)
02 Why must business rules be accurately identified?
Or to sum it up in one sentence is to avoid the fault line between business execution and business management!
Here I will give an extreme example to help you understand that a single product is swiped in batches by black production because it does not recognize the risk control rule of “purchasing the same device number ≤ 5 times a day”.
The essential problem here is that the system only implements basic functions (transfers) but does not cover business constraints (frequency monitoring).
03 Practice: Identify core business rules in three steps
After understanding the previous content, let’s talk about practical combat, to identify the business rules that the system should cover from complex business, here based on my past experience, you can follow the following three-step method.
Step 1: Business panorama dismantling and information integration
Goal: Extract key processes, constraints, and decision nodes from the entire business link. There are 3 actions in total
Action 01 Mapping business roles and scenarios
Sort out the core demands of stakeholders (users, operations, risk control, etc.), and clarify the operational boundaries of each role in the business (e.g., real-name authentication is required before users submit orders).
Use case diagrams or user journey diagrams to mark the triggered actions and desired outcomes of different roles in the process.
Action 02 Refined process disassembly
Use BPMN (Business Process Modeling) tools to break down the business into atomic-level steps (e.g., e-commerce order process: add-on→ inventory verification→ payment→ fulfillment).
Label the business constraints (for example, “Automatically cancel orders when inventory is low”) and exception branches (such as “Automatically release inventory when payment timeout”) at key nodes.
Action 03 Identification of rule trigger conditions
Here we recommend that you use a 5W1H analysis method positioning rule to take effect:
- When will it take effect? Example: Membership discount reset on the 1st of each month)
- Who (Affect?) Example: VIP users can enjoy priority refunds)
- What (operation limits?) Example: Single transfer amount ≤500,000)
- Why (Business Objective?) Example: risk control requires the prevention of money laundering).
Step 2: Rule classification and priority hierarchy
Goal: Distinguish between core rules and auxiliary rules, and establish rule implementation priorities.
Prioritization Method:
Business impact assessment: Priority coverage of rules for high-frequency use (such as price calculation) or high risk of loss (such as risk control interception).
Change Cost Evaluation: Design variable rules, such as campaign strategies, as configurable modules to reduce iteration costs.
Step 3: Rule verification and dynamic maintenance
Objective: Ensure rule coverage integrity and establish a continuous optimization mechanism.
Business rules are boarded
Establish a visual rule base, register the collected business rules uniformly, mark the rule status (effective/in testing/deprecated), and associate it with the system module mapping to dynamically track the changes of business rules.
Through the above steps, I believe that no matter how complex a business system is, it can be quickly split by us like a chef, so try it!
