Mở đầu — vì sao bài này quan trọng
Hãy nhớ lại những ngày bạn còn làm Sales. Mỗi khi định chốt một deal lớn, bạn phải tự trả lời hàng loạt câu hỏi trong đầu: "Khách này mua trên 500 triệu thì được chiết khấu bao nhiêu? Combo này có được cộng dồn khuyến mãi không? Sales rep mới vào dưới 3 tháng có được bán giá đặc biệt không? Hoa hồng tháng này tính theo doanh số gross hay net?". Những câu trả lời đó chính là business rules — quy tắc nghiệp vụ. Vấn đề là hồi đó chúng nằm rải rác: một phần trong email của sếp, một phần trong file Excel "chính sách giá v7_final_final", một phần trong cái đầu của chị kế toán trưởng, và một phần... chỉ tồn tại như "luật bất thành văn" mà ai vào lâu mới biết.
Khi chuyển sang làm BA, một trong những giá trị lớn nhất bạn mang lại cho team phát triển phần mềm chính là khả năng gom toàn bộ mớ hỗn độn đó lại thành một danh mục có cấu trúc — gọi là Business Rule Catalog. Đây là kỹ năng mà rất nhiều BA non kinh nghiệm bỏ qua, dẫn đến tình trạng dev code sai logic, tester không biết test case nào đúng, và stakeholder cãi nhau về "đáng lẽ hệ thống phải làm thế này chứ". Một BA giỏi biết rằng: requirement nói hệ thống phải làm gì, còn business rule nói hệ thống được phép và không được phép làm theo điều kiện nào. Bài này sẽ dạy bạn cách xây và quản trị danh mục đó một cách chuyên nghiệp.
Khái niệm cốt lõi
Business rule là gì?
Business rule là một mệnh đề ràng buộc hoặc định nghĩa khía cạnh nào đó của nghiệp vụ, độc lập với việc nó được hiện thực bằng phần mềm hay con người. Theo định nghĩa kinh điển trong Business Rules Group, một business rule là "một câu lệnh nhằm định nghĩa hoặc ràng buộc một khía cạnh của doanh nghiệp; nó nhằm khẳng định cấu trúc kinh doanh, hoặc kiểm soát/ảnh hưởng đến hành vi của doanh nghiệp".
Điểm quan trọng cho người chuyển từ Sales: business rule không phải là quy trình (process), cũng không phải là requirement (yêu cầu). Hãy phân biệt rõ:
- Requirement: "Hệ thống phải cho phép áp dụng chiết khấu khi tạo đơn hàng."
- Business rule: "Đơn hàng có giá trị từ 500 triệu trở lên được chiết khấu tối đa 8%; dưới mức đó tối đa 5%."
- Process: các bước tạo đơn → kiểm tra điều kiện → áp chiết khấu → duyệt.
Bốn nhóm business rule phổ biến
Để xây catalog có hệ thống, BA thường phân business rule thành các nhóm. Một cách phân loại dễ nhớ cho người mới:
- Definitional rules / Term (định nghĩa): làm rõ thuật ngữ. Ví dụ: "Khách hàng VIP là khách có tổng doanh số 12 tháng gần nhất ≥ 1 tỷ đồng."
- Fact / Quan hệ: mô tả mối liên hệ giữa các khái niệm. Ví dụ: "Mỗi đơn hàng thuộc về đúng một khách hàng; một khách hàng có thể có nhiều đơn hàng."
- Constraint / Ràng buộc: bắt buộc hoặc cấm điều gì đó. Ví dụ: "Không được tạo đơn hàng cho khách hàng đang bị khóa công nợ."
- Derivation / Tính toán suy ra: cách tính ra một giá trị. Ví dụ: "Hoa hồng = doanh số net × tỷ lệ bậc tương ứng; doanh số net = gross − hàng trả lại − thuế GTGT."
Mỗi rule cần những thuộc tính gì?
Một dòng trong catalog không chỉ là một câu mô tả. Để quản trị được, mỗi rule cần tối thiểu các trường (attributes) sau:
- Rule ID: mã định danh duy nhất, ví dụ
BR-PRICE-014. ID giúp dev, tester, stakeholder tham chiếu chính xác. Đặt ID có tiền tố theo domain (PRICE, CREDIT, AUTH...) rất dễ tra. - Tên/Mô tả rule: phát biểu rõ ràng, một mệnh đề, tránh "và/hoặc" lồng nhau.
- Loại rule (type): definition / constraint / derivation / fact.
- Owner: ai là người có thẩm quyền quyết định và thay đổi rule này. Thường là một vai trò nghiệp vụ (Trưởng phòng Kinh doanh, Giám đốc Tài chính), không phải một cá nhân.
- Source: rule đến từ đâu — chính sách công ty, văn bản pháp luật, hợp đồng, hay quyết định của ban lãnh đạo.
- Version & Effective date: phiên bản và ngày hiệu lực. Rule thay đổi theo thời gian, bạn cần biết "tại thời điểm tháng 3/2026, rule đang là phiên bản nào".
- Status: draft / active / deprecated / retired.
- Related requirements / use cases: rule này được dùng ở đâu trong hệ thống.
- Rationale: lý do tồn tại của rule (rất quan trọng để sau này ai đó không vô tình xóa nó).
Tình huống thực tế
Tình huống 1 — Sàn TMĐT nội thất "NhaViet": rule chiết khấu chồng chéo
NhaViet là một công ty thương mại điện tử nội thất giả định ở TP.HCM, doanh thu khoảng 200 tỷ/năm. Trước khi có BA, chính sách chiết khấu nằm trong 4 nguồn: file Excel của phòng Marketing, group Zalo nội bộ, mã giảm giá hard-code trong website cũ, và "thỏa thuận miệng" của Sales với khách lớn.
Hậu quả: một khách đặt sofa 60 triệu được cộng dồn 3 khuyến mãi (giảm 10% flash sale + voucher 2 triệu + chiết khấu khách thân thiết 8%), khiến đơn hàng lỗ vốn. Kế toán phát hiện sau một tháng, hai phòng đổ lỗi cho nhau.
Khi BA mới vào, việc đầu tiên là phỏng vấn (elicitation) và dựng catalog. Một vài rule được chuẩn hóa:
BR-PROMO-001(constraint): "Mỗi đơn hàng chỉ được áp dụng tối đa một chương trình khuyến mãi phần trăm; không cộng dồn với chiết khấu khách thân thiết." Owner: Trưởng phòng Marketing.BR-PROMO-002(constraint): "Voucher tiền mặt được phép cộng với khuyến mãi phần trăm, nhưng tổng mức giảm không vượt quá 20% giá trị đơn." Owner: Giám đốc Kinh doanh.
Tình huống 2 — Công ty SaaS B2B "FlowDesk": rule tier subscription
FlowDesk (giả định, mô phỏng kiểu Base.vn hay Misa) bán phần mềm quản lý công việc theo gói. Họ có ba bậc: Starter, Growth, Enterprise. Khi còn là Sales, bạn quen với "tier" theo nghĩa khách mua gói nào. Nhưng khi làm BA cho đội sản phẩm, "tier" mở rộng thành cả một cụm rule điều khiển hành vi hệ thống:
BR-TIER-003(derivation): "Số user tối đa = giới hạn theo gói (Starter: 10, Growth: 50, Enterprise: không giới hạn)."BR-TIER-007(constraint): "Khi khách hạ cấp từ Growth xuống Starter mà số user hiện tại > 10, hệ thống chặn thao tác và yêu cầu xóa bớt user trước." Owner: Product Manager.BR-BILLING-011(derivation): "Khi nâng cấp giữa kỳ, phí chênh lệch = (đơn giá gói mới − gói cũ) × số ngày còn lại / số ngày trong kỳ." Owner: Giám đốc Tài chính.
BR-BILLING-011 vào catalog với version và effective date rõ ràng, mọi thay đổi chính sách giá đều được phản ánh đúng — và quan trọng là khi kiểm toán hỏi "tháng 1 tính prorate kiểu gì", họ tra được phiên bản rule đang hiệu lực thời điểm đó.Bài học rút ra: derivation rule (công thức) là nơi dev hay tự "đoán" nhất và cũng là nơi sai nhiều tiền nhất. BA phải viết công thức tường minh, có ví dụ số cụ thể, và gắn version để truy vết theo thời gian.
Tình huống 3 — Ngân hàng số: rule tín dụng và compliance
Một dự án app cho vay tiêu dùng tại một ngân hàng VN (bối cảnh tương tự MB, TPBank). Ở đây business rule không chỉ ảnh hưởng tiền mà còn ảnh hưởng tuân thủ pháp luật. Ví dụ:
BR-CREDIT-021(constraint): "Không phê duyệt khoản vay cho khách hàng dưới 20 tuổi hoặc trên 60 tuổi tại thời điểm kết thúc hợp đồng." Source: Quy định nội bộ + hướng dẫn NHNN. Owner: Khối Quản trị rủi ro.BR-CREDIT-025(derivation): "Hạn mức tối đa = thu nhập trung bình 3 tháng × hệ số theo nhóm rủi ro CIC."
Bài học rút ra: trong các domain bị quản lý chặt (fintech, bảo hiểm, y tế), trường source và rationale không phải tùy chọn — chúng là yêu cầu bắt buộc để chứng minh rule xuất phát từ quy định hợp pháp.
Hướng dẫn từng bước
Đây là quy trình xây dựng một Business Rule Catalog từ đầu mà bạn có thể áp dụng ngay trong dự án thật.
Bước 1 — Xác định phạm vi (scope) theo domain. Đừng cố gom mọi rule của cả công ty trong một lần. Chọn một domain trước, ví dụ "Pricing & Discount" hoặc "Order approval". Người ex-Sales có lợi thế: hãy bắt đầu từ domain bạn thông thạo nhất (chiết khấu, hoa hồng).
Bước 2 — Thu thập rule (elicitation). Phỏng vấn stakeholder, đọc tài liệu chính sách, soi file Excel, xem code cũ, và đặc biệt — săn "luật bất thành văn". Câu hỏi vàng: "Có trường hợp ngoại lệ nào không? Khi nào thì ngược lại?". Ngoại lệ chính là rule ẩn.
Bước 3 — Viết rule ở dạng nguyên tử (atomic). Mỗi rule chỉ nói một điều. Nếu một câu có nhiều "và/hoặc/nhưng", hãy tách ra. "Khách VIP được chiết khấu 8% và miễn phí ship" nên tách thành hai rule riêng, vì chúng có thể thay đổi độc lập.
Bước 4 — Gán thuộc tính. Điền đầy đủ ID, type, owner, source, version, status. Đừng để trống owner — nếu chưa biết owner, đánh dấu "TBD" và đưa vào danh sách câu hỏi mở để theo dõi.
Bước 5 — Phát biểu rule theo văn phong nhất quán. Dùng cấu trúc khẳng định, hiện tại, tránh mơ hồ. Ưu tiên mẫu: "[Điều kiện] thì [hành động/ràng buộc]". Tránh từ mơ hồ như "thường", "đôi khi", "nếu cần".
Bước 6 — Đối chiếu chéo (cross-check) và phát hiện xung đột. Đặt các rule cạnh nhau và hỏi: có rule nào mâu thuẫn không? Có khoảng trống (gap) nào không bao phủ? Đây là lúc bạn phát hiện "đơn 500 triệu được 8%, đơn 500 triệu cho khách VIP thì bao nhiêu?" — một gap chưa ai trả lời.
Bước 7 — Liên kết rule với requirement/use case. Mỗi rule nên trỏ tới nơi nó được sử dụng. Điều này giúp khi rule đổi, bạn biết ngay use case nào bị ảnh hưởng (traceability).
Bước 8 — Quản trị thay đổi. Thiết lập quy trình: ai đề xuất, ai duyệt (owner), tăng version, ghi effective date, thông báo team. Lưu trên Confluence hoặc một bảng tập trung để toàn team truy cập một nguồn sự thật.
Lỗi thường gặp & mẹo
Lỗi 1 — Trộn rule vào trong mô tả requirement. Nhiều BA viết thẳng "8%" vào câu requirement. Khi con số thay đổi, phải sửa khắp nơi. Mẹo: trong requirement chỉ viết "áp dụng chiết khấu theo BR-PRICE-014", còn con số nằm trong catalog.
Lỗi 2 — Rule không nguyên tử. Một rule gánh ba điều kiện khiến không thể test, không thể đổi cục bộ. Mẹo: nếu test case của rule cần nhiều hơn một "kết quả mong đợi", hãy tách rule.
Lỗi 3 — Thiếu owner và version. Đây là lỗi chết người. Không owner = không ai dám duyệt thay đổi = rule "đóng băng" sai. Không version = không truy được lịch sử khi kiểm toán. Mẹo: coi owner và version là trường bắt buộc, để trống là chưa hoàn thành rule.
Lỗi 4 — Bỏ qua ngoại lệ. Người mới thường chỉ ghi rule "happy path". Mẹo: với mỗi rule, luôn hỏi "khi nào rule này KHÔNG áp dụng?". Ngoại lệ thường là rule quan trọng nhất.
Lỗi 5 — Catalog chết. Xây xong rồi để mốc trong một file Word không ai mở. Mẹo: đặt catalog ở nơi sống động (Confluence, Notion), gắn vào quy trình review định kỳ, và mỗi khi có thay đổi chính sách kinh doanh thì cập nhật ngay.
Mẹo dành riêng cho ex-Sales: lợi thế lớn nhất của bạn là cảm nhận được rule nào hay bị "lách" trong thực tế. Bạn biết Sales thường tìm cách cộng dồn khuyến mãi, biết khách hay đòi ngoại lệ. Hãy dùng trực giác đó để truy tìm những rule ẩn mà BA thuần kỹ thuật không bao giờ nghĩ tới.
Bài tập thực hành
Bài tập 1 — Chuyển hóa kinh nghiệm Sales. Lấy chính sách hoa hồng/chiết khấu ở công ty cũ (hoặc bối cảnh giả định) của bạn. Viết tối thiểu 6 business rule, mỗi rule đầy đủ các trường: ID, type, mô tả, owner, source, version, status. Bắt buộc có ít nhất một derivation rule (công thức tính) kèm ví dụ số.
Bài tập 2 — Săn ngoại lệ. Với mỗi rule ở bài 1, viết thêm câu trả lời cho câu hỏi "khi nào rule này không áp dụng?". Bạn sẽ phát hiện ra ít nhất 2 rule ẩn.
Bài tập 3 — Phát hiện xung đột. Cho hai rule: (A) "Khách VIP được chiết khấu 10% mọi đơn hàng"; (B) "Đơn hàng từ chương trình flash sale không được áp dụng chiết khấu nào khác". Hãy: chỉ ra tình huống xung đột, viết một rule thứ ba để giải quyết, và xác định ai là owner đủ thẩm quyền quyết định.
Bài tập 4 — Quản trị version. Giả sử công ty đổi mức chiết khấu đơn lớn từ 8% xuống 6% hiệu lực 01/07/2026. Mô tả cách bạn cập nhật catalog: phiên bản mới ghi gì, phiên bản cũ xử lý ra sao, và làm thế nào để hệ thống vẫn tính đúng cho đơn hàng phát sinh trước ngày hiệu lực.
Tóm tắt
Business Rule Catalog là danh mục tập hợp mọi quy tắc nghiệp vụ của một domain, trong đó mỗi rule là một mệnh đề nguyên tử đi kèm bộ thuộc tính quản trị — quan trọng nhất là ID, owner và version. Người chuyển từ Sales/BD bước vào BA có sẵn vốn quý: bạn đã sống cùng các rule commission, discount, tier mỗi ngày. Việc của bạn là mở rộng tư duy đó ra toàn bộ vòng đời nghiệp vụ (tín dụng, phê duyệt, trạng thái, compliance), tách rule ra khỏi requirement và process, viết chúng tường minh, gán chủ sở hữu và phiên bản, đối chiếu để diệt xung đột, rồi đặt vào một nơi sống động cho cả team tham chiếu.
Một catalog tốt mang lại ba giá trị: dev code đúng logic ngay từ đầu, tester có cơ sở viết test case, và stakeholder ngừng tranh cãi vì có một nguồn sự thật duy nhất. Hãy bắt đầu nhỏ từ domain bạn thông thạo nhất, và nhớ rằng giá trị của một BA giỏi nằm ở chỗ biến mớ "luật bất thành văn" hỗn độn thành tài sản tri thức có cấu trúc của tổ chức.