M-Bài 24 — Business Rules — Bóc tách và quản lý

Mở đầu — vì sao bài này quan trọng

Hãy hình dung bạn vừa chuyển từ Marketing sang BA, và trong sprint đầu tiên, dev hỏi bạn một câu rất "nhỏ": "Khách hàng đặt đơn dưới 200.000đ thì có được freeship không anh/chị?". Bạn quay sang hỏi PO, PO hỏi lại sếp vận hành, sếp vận hành nói "tùy chương trình", và cuối cùng cả nhóm mất nửa ngày chỉ để xác nhận một dòng logic. Một tuần sau, cũng câu hỏi đó lại xuất hiện ở một màn hình khác. Đây chính là vấn đề mà Business Rules — quy tắc kinh doanh sinh ra để giải quyết.

Với người làm Marketing, bạn vốn rất quen với "luật chơi": "ngân sách quảng cáo Facebook không vượt 30% tổng budget", "chỉ chạy retarget cho người đã xem video trên 50%", "voucher chỉ áp dụng cho khách mới". Đó đều là business rules. Khác biệt duy nhất là khi làm BA, bạn phải bóc tách chúng ra một cách có hệ thống, viết rõ ràng, và quản lý chúng như một tài sản thay vì để chúng nằm rải rác trong đầu các sếp.

Bài này dạy bạn cách nhận diện, phân loại, đặc tả và quản lý business rules — một trong những kỹ năng "kín" nhất nhưng tạo khác biệt lớn nhất giữa một BA junior và một BA được tin tưởng giao việc khó. Lưu ý: bài này tập trung riêng vào business rules. Việc bóc tách quy trình (BPMN), mô hình dữ liệu (ERD), hay viết user story chuẩn INVEST đã có các bài riêng — ở đây ta soi thẳng vào "luật".

Khái niệm cốt lõi

Business Rule là gì — và không phải là gì

Business Rule (quy tắc kinh doanh) là một phát biểu định nghĩa hoặc ràng buộc một khía cạnh của hoạt động kinh doanh. Nó chi phối hành vi của hệ thống và quy trình, nhưng bản thân nó không phải là một tính năng (feature).

Đây là điểm dễ nhầm nhất với người mới. Phân biệt cho rõ:

• Feature/Requirement: "Hệ thống cho phép khách hàng áp mã giảm giá khi thanh toán." → mô tả cái hệ thống làm được.
• Business Rule: "Mỗi đơn hàng chỉ được áp tối đa 1 mã giảm giá, và mã không áp dụng cho sản phẩm đang trong chương trình flash sale." → mô tả điều kiện, ràng buộc, luật chơi mà tính năng đó phải tuân theo.

Một feature có thể tồn tại mà bị chi phối bởi nhiều business rules. Và một business rule có thể tác động đến nhiều feature khác nhau. Đó là lý do ta phải tách chúng ra: nếu nhét luật vào trong mô tả tính năng, khi luật thay đổi (mà luật kinh doanh thì thay đổi liên tục), bạn sẽ phải đi sửa hàng chục chỗ.

Một đặc tính cốt lõi của business rule tốt theo chuẩn Business Rules Manifesto: rule là declarative (khai báo), không phải procedural (thủ tục). Nghĩa là bạn phát biểu cái gì đúng/cái gì được phép, chứ không mô tả làm thế nào (cách lập trình từng bước). "Khách VIP được giảm 10%" là declarative. "Nếu hạng = VIP thì gọi hàm tính giảm giá rồi trừ vào tổng" là procedural — đó là việc của dev, không phải của rule.

Bốn loại Business Rule (theo Ronald Ross)

Ronald Ross — cha đẻ của lĩnh vực business rules — phân chúng thành 4 nhóm. Nắm vững 4 nhóm này, bạn sẽ bóc tách rule nhanh và đầy đủ hơn hẳn:

1. Definitional rules (Quy tắc định nghĩa) — còn gọi là structural rules. Đây là những luật định nghĩa khái niệm hoặc cách tính toán trong nghiệp vụ. Chúng luôn đúng theo định nghĩa, không thể vi phạm. Ví dụ: "Khách hàng VIP là khách có tổng chi tiêu trong 12 tháng gần nhất ≥ 50 triệu đồng." hoặc "Tổng giá trị đơn hàng = tổng tiền sản phẩm − giảm giá + phí vận chuyển + thuế." Vi phạm definitional rule là điều vô lý — giống như nói "tam giác có 4 cạnh".

2. Operative rules (Quy tắc vận hành) — còn gọi là behavioral rules. Đây là luật chi phối hành vi và có thể bị vi phạm trong thực tế (vì con người/hệ thống có thể làm sai). Ví dụ: "Đơn hàng phải được thanh toán trong vòng 24 giờ kể từ khi tạo, nếu không sẽ tự hủy." Operative rule cần được enforce — và quan trọng: cần xác định mức độ enforcement (sẽ nói ở dưới).

3. Fact rules / Facts (Sự kiện, mối quan hệ). Phát biểu các mối quan hệ luôn đúng 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 địa chỉ giao hàng." Đây là nền tảng để xây mô hình dữ liệu sau này.

4. Derivation rules (Quy tắc suy diễn). Luật cho phép suy ra một thông tin mới từ thông tin có sẵn, qua tính toán (computation) hoặc suy luận (inference). Ví dụ: "Điểm tích lũy = giá trị đơn hàng / 1.000, làm tròn xuống." "Nếu khách có ≥ 3 đơn bị hoàn trả trong 30 ngày thì hệ thống gắn cờ 'rủi ro cao'."

Mẹo của mentor: khi phỏng vấn stakeholder, cứ tự hỏi "phát biểu này thuộc nhóm nào trong 4 nhóm?". Nếu bạn không xếp được, khả năng cao bạn đang nắm một câu mơ hồ cần đào sâu thêm.

Mức độ thực thi (Enforcement Level)

Với operative rules, không phải luật nào cũng "cấm tuyệt đối". Bạn cần ghi rõ mức enforcement, vì nó quyết định cách dev xử lý:

• Strictly enforced (cưỡng chế tuyệt đối): không cho phép vi phạm, hệ thống chặn cứng. Ví dụ: "Không cho đặt hàng nếu chưa nhập số điện thoại."
• Override allowed (cho phép vượt rào có thẩm quyền): vi phạm được phép nếu có người có quyền duyệt. Ví dụ: "Giảm giá quá 30% phải có Manager phê duyệt."
• Guideline (khuyến nghị): chỉ cảnh báo, không chặn. Ví dụ: "Nên gợi ý khách mua kèm sản phẩm bổ trợ."

Ghi sai mức enforcement là một trong những lỗi đắt giá nhất — chặn cứng một luật đáng lẽ chỉ là khuyến nghị sẽ làm tê liệt vận hành; còn để lỏng một luật đáng lẽ phải cưỡng chế sẽ gây thất thoát.

Tình huống thực tế

Tình huống 1 — Sàn TMĐT kiểu Tiki: mớ bòng bong freeship

Một BA mới (từng làm Marketing) nhận nhiệm vụ làm rõ logic miễn phí vận chuyển cho một sàn TMĐT giả định tên MuaNhanh. Ban đầu, mô tả nhận được chỉ là một dòng: "Freeship cho đơn đủ điều kiện."

Bạn ngồi với team vận hành và bóc ra được loạt rule rời rạc:

• "Đơn ≥ 250.000đ được freeship trong nội thành TP.HCM và Hà Nội."
• "Khách hội viên FreeshipXtra được freeship không giới hạn giá trị, tối đa 4 đơn/tháng."
• "Sản phẩm cồng kềnh (> 20kg) không bao giờ freeship, kể cả khi đủ điều kiện khác."
• "Mỗi đơn chỉ áp dụng một loại freeship — ưu tiên hội viên trước, ngưỡng giá trị sau."

Diễn giải: bốn câu trên thuộc các nhóm khác nhau. Câu cuối là một operative rule về ưu tiên; câu "sản phẩm > 20kg không freeship" là definitional/constraint (luôn đúng, không vượt rào); "4 đơn/tháng" là một ngưỡng cần derivation rule để đếm. BA viết chúng thành bảng, mỗi rule một dòng, gắn ID (FR-001 đến FR-004), và đặc biệt phát hiện một xung đột: chuyện gì xảy ra khi khách FreeshipXtra mua hàng > 20kg? Rule cồng kềnh thắng. Nếu không hỏi, dev sẽ tự đoán — và đoán sai.

Bài học: business rule phải được bóc thành đơn vị nguyên tử (atomic) — mỗi rule một ý — và phải kiểm tra xung đột chéo giữa các rule. Câu "đủ điều kiện" mơ hồ ban đầu thực ra giấu ít nhất 4 luật và 1 xung đột.

Tình huống 2 — Ví điện tử kiểu MoMo: hạn mức giao dịch

Tại một ví điện tử giả định ViVi, BA cần đặc tả luật hạn mức nạp/rút theo quy định ngân hàng nhà nước và chính sách nội bộ. Stakeholder nói: "Tài khoản chưa định danh thì hạn mức thấp, định danh rồi thì cao hơn."

BA bóc ra thành các rule có cấu trúc rõ:

• BR-LIMIT-01 (definitional): "Tài khoản 'đã định danh' là tài khoản đã hoàn tất eKYC và liên kết ngân hàng."
• BR-LIMIT-02 (operative, strictly enforced): "Tài khoản chưa định danh: tổng giao dịch ≤ 20 triệu đồng/tháng."
• BR-LIMIT-03 (operative, strictly enforced): "Tài khoản đã định danh: tổng giao dịch ≤ 100 triệu đồng/tháng."
• BR-LIMIT-04 (derivation): "Hạn mức còn lại = hạn mức tháng − tổng giao dịch đã thực hiện trong tháng dương lịch hiện tại."

Diễn giải: con số 20 triệu và 100 triệu không nên hard-code trong tài liệu tính năng — chúng là tham số của business rule, và sẽ thay đổi khi luật ngân hàng đổi. BA tách chúng thành một rule table riêng để khi NHNN cập nhật, chỉ sửa một bảng thay vì lục toàn bộ spec.

Bài học: với rule chứa con số/ngưỡng từ quy định pháp lý hoặc chính sách hay thay đổi, hãy tách giá trị ra thành tham số quản lý tập trung. Đây gọi là externalize the rule — đừng chôn luật trong code/spec.

Tình huống 3 — Ngân hàng số: quy tắc duyệt mở thẻ tín dụng

Một BA tại một ngân hàng số VN làm dự án mở thẻ tín dụng online. Bộ phận rủi ro đưa ra: "Khách phải đủ điều kiện thì mới duyệt." BA phỏng vấn và bóc được một decision table (bảng quyết định) — công cụ vàng để quản lý rule phức tạp nhiều điều kiện:

Diễn giải: thay vì viết 4 câu "nếu... thì..." rời rạc dễ chồng chéo, BA dùng bảng quyết định để đảm bảo phủ hết mọi tổ hợp và không mâu thuẫn. Đây là cách trình bày business rule chuyên nghiệp khi có nhiều điều kiện kết hợp.

Bài học: khi rule có từ 2 điều kiện trở lên kết hợp với nhau, hãy dùng decision table thay cho văn xuôi. Nó giúp phát hiện lỗ hổng (tổ hợp chưa được định nghĩa) và mâu thuẫn ngay lập tức.

Hướng dẫn từng bước

Đây là quy trình 6 bước để bóc tách và quản lý business rules mà bạn có thể áp dụng ngay từ dự án đầu tiên:

Bước 1 — Phát hiện (Discover). Săn rule từ mọi nguồn: phỏng vấn stakeholder, tài liệu chính sách, quy định pháp lý, email, thậm chí từ những câu "à mà thường thì tụi anh hay...". Tín hiệu nhận diện rule trong lời nói: các từ "phải", "không được", "chỉ khi", "tối đa/tối thiểu", "ngoại trừ", "nếu... thì bắt buộc".

Bước 2 — Bóc thành đơn vị nguyên tử (Atomic). Mỗi rule chỉ chứa một ý. Câu "Khách VIP được giảm 10% và miễn phí ship" phải tách thành 2 rule. Nguyên tử hóa giúp tái sử dụng và sửa đổi độc lập.

Bước 3 — Phân loại (Classify). Xếp mỗi rule vào 1 trong 4 nhóm (definitional / operative / fact / derivation) và xác định mức enforcement nếu là operative.

Bước 4 — Đặt cấu trúc (Express). Viết theo mẫu nhất quán. Một mẫu phổ biến: "[Khi điều kiện X], [chủ thể] [phải/không được/được phép] [hành động/kết quả]." Với rule nhiều điều kiện, chuyển sang decision table. Gán mỗi rule một Rule ID duy nhất (ví dụ BR-001).

Bước 5 — Kiểm tra chất lượng (Validate). Soi từng cặp rule để tìm: mâu thuẫn (conflict), trùng lặp (redundancy), khoảng trống (gap — tổ hợp chưa định nghĩa), và rule "mồ côi" không gắn với nghiệp vụ nào. Đối chiếu lại với stakeholder để xác nhận.

Bước 6 — Quản lý vòng đời (Govern). Lưu rule vào một nơi tập trung — Business Rules Catalog (thường là một trang Confluence hoặc bảng). Mỗi rule cần: ID, phát biểu, loại, enforcement, nguồn (ai/tài liệu nào ban hành), ngày hiệu lực, trạng thái, và rule liên quan. Khi rule thay đổi, bạn cập nhật ở một chỗ và truy vết được ảnh hưởng.

Một mẫu dòng trong catalog:

Lỗi thường gặp & mẹo

Lỗi 1 — Nhét business rule vào trong mô tả tính năng/user story. Khi luật đổi, bạn phải lục từng story. Mẹo: tách rule ra catalog riêng, trong story chỉ tham chiếu Rule ID ("tuân theo BR-007").

Lỗi 2 — Viết rule theo kiểu thủ tục (procedural) thay vì khai báo (declarative). "Hệ thống lấy ngày sinh, trừ ngày hiện tại, nếu < 18 thì báo lỗi" là mô tả cách làm. Hãy viết: "Khách hàng phải đủ 18 tuổi trở lên để đăng ký." Để cách thực hiện cho dev.

Lỗi 3 — Bỏ quên mức enforcement. Mọi operative rule đều phải nói rõ: chặn cứng, cho override, hay chỉ cảnh báo. Thiếu thông tin này, dev sẽ tự quyết — thường là chặn cứng quá mức.

Lỗi 4 — Không kiểm tra xung đột giữa các rule. Như tình huống freeship: khách VIP mua hàng cồng kềnh thì rule nào thắng? Luôn rà các cặp rule có thể "đụng nhau" và định nghĩa rõ thứ tự ưu tiên.

Lỗi 5 — Hard-code con số ngưỡng vào spec. Các giá trị như hạn mức, % giảm giá, số ngày hết hạn thường thay đổi. Tách chúng thành tham số trong rule table để dễ bảo trì.

Mẹo từ Marketing chuyển sang: bạn vốn giỏi tư duy "segment + điều kiện" (ai, khi nào, được gì) từ việc set up campaign và automation. Đó chính xác là tư duy business rule. Hãy tận dụng — chỉ cần thêm tính kỷ luật về ID, phân loại và catalog.

Mẹo công cụ: với decision table phức tạp, hãy dùng kỹ thuật phủ tổ hợp — liệt kê mọi giá trị có thể của từng điều kiện rồi nhân chéo, đảm bảo không sót dòng nào. Đây là cách phát hiện gap hiệu quả nhất.

Bài tập thực hành

Bài 1 — Phân loại. Cho 5 phát biểu sau, xếp mỗi cái vào 1 trong 4 loại (definitional / operative / fact / derivation):

• "Mỗi giỏ hàng thuộc về đúng một tài khoản."
• "Điểm thưởng = 1% giá trị đơn hàng."
• "Đơn hàng phải được xác nhận trong 2 giờ, nếu không sẽ chuyển sang trạng thái chờ xử lý."
• "Khách hàng thân thiết là khách có ≥ 10 đơn thành công."
• "Giảm giá vượt 50% phải có Giám đốc duyệt."

Bài 2 — Bóc tách nguyên tử. Lấy câu sau và tách thành các rule nguyên tử, gán ID, ghi enforcement: "Voucher SINHNHAT chỉ áp dụng cho khách đăng ký trên 6 tháng, đơn tối thiểu 300.000đ, không dùng chung voucher khác, và mỗi khách dùng tối đa 1 lần."

Bài 3 — Decision table. Một app gọi xe giả định tính phụ phí giờ cao điểm. Điều kiện: khung giờ (cao điểm / bình thường) và thời tiết (mưa / không mưa). Phụ phí: cao điểm + mưa = +40%; cao điểm + không mưa = +20%; bình thường + mưa = +15%; bình thường + không mưa = 0%. Hãy vẽ decision table phủ đủ 4 tổ hợp và viết chúng dưới dạng derivation rule.

Bài 4 — Thực chiến. Chọn một sản phẩm bạn dùng hằng ngày (Shopee, Grab, ngân hàng số...). Quan sát và viết lại ít nhất 8 business rules bạn suy ra được từ hành vi của nó, lập thành một Business Rules Catalog mini với đủ cột ID, phát biểu, loại, enforcement.

Tóm tắt

Business rule là luật chơi chi phối hành vi của hệ thống và quy trình — chúng định nghĩa, ràng buộc, và suy diễn, nhưng không phải là tính năng. Theo Ronald Ross, có 4 loại: definitional (định nghĩa/cấu trúc), operative (vận hành, có thể vi phạm, cần enforcement), fact (mối quan hệ), và derivation (suy diễn/tính toán). Một rule tốt phải declarative (khai báo cái gì đúng), atomic (một ý), có ID và mức enforcement rõ ràng.

Quy trình quản lý gồm 6 bước: phát hiện → nguyên tử hóa → phân loại → đặt cấu trúc (dùng decision table khi nhiều điều kiện) → kiểm tra (xung đột, trùng, gap) → quản lý vòng đời trong một Business Rules Catalog tập trung. Tách rule ra khỏi spec tính năng, externalize các con số ngưỡng, và luôn rà xung đột chéo — đó là những thói quen biến bạn từ một người chỉ "chép yêu cầu" thành một BA thực sự kiểm soát được logic nghiệp vụ. Với nền Marketing, tư duy "ai — khi nào — được gì" của bạn đã là một khởi đầu rất tốt; hãy thêm vào đó tính kỷ luật và bạn sẽ bóc tách rule sắc bén hơn nhiều đồng nghiệp.