Mở đầu — vì sao bài này quan trọng
Khi còn làm Designer, bạn đã quen với "design system" — nơi mọi màu sắc, spacing, component, và state đều được định nghĩa một lần, đánh tên, và tái sử dụng khắp sản phẩm. Bạn biết chính xác Button/Primary/Disabled trông thế nào, vì nó nằm trong Figma library, có tên, có phiên bản. Không ai vẽ lại nút bấm từ đầu mỗi lần mở màn hình mới.
Vậy mà khi bước sang thế giới nghiệp vụ, phần lớn công ty lại đối xử với quy tắc nghiệp vụ (business rule) một cách hỗn loạn không thể tin nổi: "Đơn hàng trên 500 nghìn thì free ship" nằm rải rác trong đầu anh trưởng phòng, trong một dòng comment code, trong một tin nhắn Slack ba tháng trước, và trong một user story ai đó viết vội. Không ID, không owner, không version. Khi cần thay đổi ngưỡng free ship, không ai dám chắc còn chỗ nào khác cũng đang hard-code con số 500 nghìn.
Đây chính là lợi thế lớn nhất của Designer chuyển sang BA. Bạn đã có sẵn tư duy hệ thống hóa từ design system. Business rule catalog về bản chất chỉ là "design system cho logic nghiệp vụ": một nơi tập trung, đánh số, versioned, và được tham chiếu chéo từ mọi tài liệu khác. Bài này dạy bạn cách xây dựng và duy trì rule book đó — kỹ năng phân biệt một BA nghiệp dư với một BA khiến cả đội dev tin tưởng.
Khái niệm cốt lõi
Business rule là gì (và không là gì)
Business rule là một mệnh đề ràng buộc hoặc dẫn dắt hành vi của nghiệp vụ, độc lập với việc nó được cài đặt bằng công nghệ nào. Ví dụ: "Khách hàng phải đủ 18 tuổi mới được mở tài khoản tín dụng." Quy tắc này đúng dù bạn code bằng Java, dùng Excel, hay xử lý thủ công.
Cần phân biệt rõ ba lớp thường bị nhầm lẫn:
- Business rule: "Khoản vay quá hạn 90 ngày bị phân loại nợ xấu nhóm 3." Đây là quy tắc do nghiệp vụ/luật quy định.
- Requirement (yêu cầu): "Hệ thống phải tự động chuyển nhóm nợ vào 0h mỗi ngày." Đây là điều ta muốn hệ thống làm.
- Implementation (cài đặt): đoạn code cron job thực thi việc chuyển nhóm.
Business rule catalog là gì
Catalog là tập hợp tất cả quy tắc nghiệp vụ của hệ thống, mỗi quy tắc được đánh một ID duy nhất, có phiên bản, có người sở hữu, và có thể được tham chiếu từ user story, use case, hay tài liệu thiết kế.
Hãy hình dung nó như một bảng, mỗi dòng là một rule với các cột:
| Thuộc tính | Mô tả | Ví dụ |
|---|---|---|
| Rule ID | Mã định danh duy nhất, không bao giờ tái sử dụng | BR-ORD-014 |
| Tên rule | Câu ngắn gọn, dễ đọc | Ngưỡng miễn phí vận chuyển |
| Phát biểu | Mệnh đề đầy đủ, không mơ hồ | Đơn hàng có giá trị hàng hóa ≥ 500.000đ được miễn phí vận chuyển nội thành |
| Loại rule | Constraint / Computation / Derivation / Trigger | Constraint |
| Owner | Ai có quyền quyết định thay đổi | Trưởng phòng Vận hành |
| Nguồn | Chính sách, luật, hay quyết định nội bộ | Chính sách KM-2026-03 |
| Version | Phiên bản + ngày hiệu lực | v2, hiệu lực 01/06/2026 |
| Trạng thái | Active / Deprecated / Draft | Active |
| Liên kết | Story/use case đang dùng rule này | US-231, US-245, UC-Checkout |
Vì sao ID và versioning là trái tim của catalog
Điểm mấu chốt không phải là "viết ra các rule" — ai cũng làm được. Điểm mấu chốt là ID ổn định và version có ngày hiệu lực.
ID cho phép mọi tài liệu khác tham chiếu thay vì sao chép. Trong user story bạn chỉ viết: "Acceptance: hệ thống áp dụng BR-ORD-014." Khi rule đổi, bạn sửa một chỗ duy nhất trong catalog, còn story vẫn trỏ đúng. Đây chính xác là nguyên tắc "single source of truth" mà bạn đã dùng với design token: bạn không viết #FF5722 khắp nơi, bạn viết color/brand/primary.
Versioning trả lời câu hỏi kinh điển: "Đơn hàng đặt ngày 20/5 nên áp ngưỡng cũ hay mới?" Nếu rule có v1 (400 nghìn, hết hiệu lực 31/5) và v2 (500 nghìn, từ 1/6), bạn tra cứu được tức thì — điều tối quan trọng cho fintech, banking, kế toán, nơi tranh chấp và audit là chuyện hằng ngày.
Bốn loại rule cần nhớ
Chuẩn phân loại phổ biến (theo tài liệu BABOK và cộng đồng business rules):
- Constraint (ràng buộc) — cấm hoặc bắt buộc: "Không cho phép rút quá số dư khả dụng."
- Computation (tính toán) — công thức: "Phí trễ hạn = 0,03% × số dư nợ × số ngày trễ."
- Derivation (suy diễn) — phân loại/gán nhãn: "Khách chi tiêu ≥ 50 triệu/năm được xếp hạng VIP."
- Trigger/Action (kích hoạt) — điều kiện dẫn tới hành động: "Khi tồn kho < 10, gửi cảnh báo cho purchasing."
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT nội địa và "cơn ác mộng free ship"
Một startup TMĐT ở TP.HCM (gọi là ShopViet) có khoảng 40 người, đội dev 8 bạn. Chính sách free ship được thay đổi trung bình mỗi 6 tuần theo mùa sale. Trước khi có catalog, mỗi lần Marketing đổi ngưỡng, BA gửi một dòng trong Jira, dev đi tìm chỗ code. Có lần ngưỡng free ship hiển thị trên banner là 300 nghìn, nhưng logic tính tiền ở giỏ hàng vẫn là 500 nghìn vì có hai chỗ hard-code khác nhau. Khách chụp màn hình phốt lên Facebook, CSKH nhận bão bình luận suốt một buổi tối.
BA mới (vốn là UX Designer) lập một catalog nhỏ trên Confluence. Rule BR-SHIP-002 phát biểu: "Đơn hàng có giá trị hàng hóa (chưa gồm phí ship) ≥ ngưỡng X được miễn phí ship nội thành; X được cấu hình theo campaign." Cô tách phần "500 nghìn" thành một tham số có version, và liệt kê rõ ba nơi rule được viện dẫn: banner trang chủ, trang giỏ hàng, và email xác nhận. Từ đó, mỗi lần đổi ngưỡng, dev có một checklist ba điểm phải đồng bộ.
Bài học: con số nhảy nhót trong đầu người ta là nguồn gốc của lỗi. Việc gán ID và liệt kê "nơi rule được dùng" biến một chính sách mơ hồ thành một checklist kiểm thử rõ ràng. Đây là tư duy component reuse của Designer áp dụng thẳng vào logic.
Ví dụ 2 — Fintech cho vay tiêu dùng và bài toán audit
Một công ty fintech cho vay tiêu dùng tại Hà Nội (gọi là VayNhanh) bị đối tác ngân hàng yêu cầu audit toàn bộ logic tính lãi và phí phạt. Vấn đề: quy tắc tính phí phạt trễ hạn đã thay đổi bốn lần trong hai năm, nhưng không ai lưu lại phiên bản nào áp dụng cho khoảng thời gian nào. Khi một khách hàng khiếu nại bị tính phí sai cho khoản vay giải ngân tháng 3/2024, đội nghiệp vụ không thể chứng minh rule nào đang hiệu lực lúc đó.
BA của VayNhanh xây một catalog với versioning nghiêm ngặt. Rule BR-FEE-011 được ghi thành:
v1(hiệu lực đến 30/6/2024): Phí phạt = 0,05% × dư nợ gốc × số ngày trễ, tối đa 8%/tháng.v2(hiệu lực từ 1/7/2024): Phí phạt = 0,03% × dư nợ gốc × số ngày trễ, tối đa 5%/tháng, theo Thông tư mới.
v1 → tái tính → khớp. Cuộc audit vốn dự kiến hai tuần rút xuống còn ba ngày.Bài học: trong lĩnh vực bị quản lý (regulated), catalog không phải "nice to have" mà là công cụ pháp lý. Versioning với ngày hiệu lực và nguồn văn bản chính là bằng chứng bảo vệ công ty. Một BA giỏi ở fintech được đánh giá qua chính khả năng duy trì rule book kiểu này.
Ví dụ 3 — Đội SaaS B2B và story chồng chéo
Một công ty SaaS quản lý nhân sự (gọi là NhanSuPro) phục vụ doanh nghiệp vừa. Họ có quy tắc phân quyền phê duyệt nghỉ phép rất rối: "Nghỉ dưới 3 ngày thì quản lý trực tiếp duyệt; từ 3 đến 5 ngày cần thêm trưởng phòng; trên 5 ngày cần cả HR Director." Quy tắc này xuất hiện trong ít nhất năm user story khác nhau, mỗi story lại chép lại logic hơi khác một chút — có story quên mất mốc "trên 5 ngày".
BA tách toàn bộ thành BR-HR-007 với một decision table đính kèm trong catalog, rồi sửa cả năm story chỉ còn viết: "Áp dụng BR-HR-007 cho luồng phê duyệt." Khi khách hàng lớn yêu cầu thêm mốc "trên 15 ngày cần Ban Giám đốc", BA chỉ cập nhật một bảng quyết định, bump version, và mọi story tự động trỏ đúng logic mới.
Bài học: rule bị sao chép vào nhiều story là mầm mống của mâu thuẫn. Catalog + tham chiếu bằng ID loại bỏ trùng lặp, đúng nguyên tắc DRY (Don't Repeat Yourself) mà dev rất trân trọng — và khiến họ tin tưởng BA.
Hướng dẫn từng bước
Bước 1 — Chọn nơi lưu và khung bảng. Với đội nhỏ, một trang Confluence hoặc một Google Sheet là đủ. Đội lớn có thể dùng công cụ chuyên biệt. Quan trọng là có đủ các cột đã liệt kê ở phần khái niệm: ID, tên, phát biểu, loại, owner, nguồn, version, trạng thái, liên kết.
Bước 2 — Thiết kế hệ thống đánh ID. Dùng tiền tố theo domain để dễ đọc: BR-ORD-xxx (order), BR-SHIP-xxx (shipping), BR-FEE-xxx (fee). Quy tắc bất di bất dịch: ID không bao giờ tái sử dụng. Rule bị bỏ thì đánh dấu Deprecated, không xóa và không gán ID đó cho rule khác. Điều này y hệt việc bạn không bao giờ đổi nghĩa một design token đã publish.
Bước 3 — Khai thác rule từ nguồn hiện có. Đi qua từng use case, journey map, spec cũ, và cả code nếu cần. Mỗi khi gặp một mệnh đề "nếu... thì...", một con số ngưỡng, một công thức, hãy tách nó ra thành một dòng rule. Đây là giai đoạn "audit hiện trạng" giống khi bạn kiểm kê component để dựng design system.
Bước 4 — Viết phát biểu rule chuẩn. Mỗi rule là một câu nguyên tử (chỉ một logic), không mơ hồ, và không phụ thuộc UI. Sai: "Nút thanh toán bị mờ nếu chưa đủ tiền." Đúng: "Không cho phép tạo đơn khi số dư khả dụng < tổng giá trị đơn." (Việc làm mờ nút là chuyện UI, không phải rule.)
Bước 5 — Gán loại, owner, nguồn, version. Xác định rõ ai được quyền thay đổi rule (owner nghiệp vụ, không phải dev), rule đến từ đâu, và version đầu tiên là v1 với ngày hiệu lực.
Bước 6 — Tạo liên kết hai chiều. Trong catalog, cột "liên kết" ghi các story dùng rule. Trong mỗi story, phần acceptance criteria trỏ về rule ID. Đây là mầm mống của traceability mà bạn sẽ học sâu ở bài về RTM (Bài 28).
Bước 7 — Thiết lập quy trình thay đổi (change control). Quy định: mọi thay đổi rule phải bump version, ghi ngày hiệu lực, ghi lý do, và owner phê duyệt. Rule cũ không xóa mà chuyển Deprecated. Đây là điều biến catalog từ "tài liệu chết" thành "tài liệu sống".
Lỗi thường gặp & mẹo
Lỗi 1 — Trộn rule với requirement. Viết "Hệ thống hiển thị popup báo lỗi màu đỏ" vào catalog. Đó là UI/requirement, không phải rule. Mẹo: rule phải đúng ngay cả khi bạn xử lý bằng giấy bút, không có phần mềm.
Lỗi 2 — Rule "hai trong một". Nhồi hai logic vào một dòng: "Đơn > 500k free ship và < 100k thì thu phụ phí 10k." Tách thành hai rule riêng để mỗi cái được version độc lập.
Lỗi 3 — Tái sử dụng hoặc đổi nghĩa ID. Cực kỳ nguy hiểm khi có story cũ đang trỏ tới. Luôn tạo ID mới cho rule mới.
Lỗi 4 — Version không có ngày hiệu lực. "v2" mà không biết áp từ khi nào thì vô dụng cho audit. Luôn ghi ngày.
Lỗi 5 — Không có owner nghiệp vụ. Nếu dev là người quyết định ngưỡng free ship, bạn đã sai vai trò. Owner phải là người kinh doanh chịu trách nhiệm.
Mẹo thực chiến:
- Với rule có nhiều điều kiện, luôn kèm decision table thay vì viết câu văn dài dòng — dễ kiểm thử, dễ phát hiện thiếu trường hợp.
- Đặt một buổi review catalog định kỳ (2-4 tuần/lần) với owner để dọn rule Deprecated.
- Tận dụng phản xạ Designer: coi mỗi rule như một "component logic" — nguyên tử, có tên, tái dùng được.
Bài tập thực hành
Cho tình huống: một app đặt lịch spa tại Đà Nẵng có các chính sách sau, đang nằm rải rác trong đầu quản lý:
- Khách đặt lịch phải hủy trước 4 tiếng, nếu không mất 30% tiền cọc.
- Khách hạng Vàng (chi tiêu ≥ 10 triệu/năm) được giảm 15% mọi dịch vụ.
- Khung giờ 18h–21h là giờ cao điểm, phụ thu 20%.
- Không nhận đặt lịch nếu còn dưới 30 phút tới giờ mở cửa.
- Lập catalog dạng bảng cho 4 rule trên, với đủ các cột: ID (tự thiết kế tiền tố domain), tên, phát biểu chuẩn, loại (constraint/computation/derivation/trigger), owner giả định, version.
- Với rule số 2, viết lại phát biểu tách bạch phần "định nghĩa hạng Vàng" (derivation) khỏi phần "áp dụng giảm giá" (computation) — tức là tách thành hai rule có ID riêng.
- Viết một acceptance criteria ngắn cho một user story "Khách hủy lịch" trong đó bạn tham chiếu rule bằng ID thay vì chép lại logic.
- Giả sử chính sách hủy đổi thành "hủy trước 2 tiếng, phạt 50%". Mô tả bạn sẽ cập nhật catalog thế nào (version, ngày hiệu lực, trạng thái rule cũ).
Tóm tắt
- Business rule catalog là "design system cho logic nghiệp vụ": tập hợp mọi quy tắc, mỗi cái có ID duy nhất, version, owner, nguồn, và được tham chiếu chéo từ story/use case.
- Sức mạnh nằm ở ID ổn định (single source of truth, không sao chép logic) và versioning có ngày hiệu lực (bằng chứng cho audit, xử lý tranh chấp).
- Phân biệt rõ rule với requirement và implementation; mỗi rule phải nguyên tử, không mơ hồ, độc lập UI.
- Bốn loại rule: constraint, computation, derivation, trigger — biết loại để chọn cách thể hiện (câu văn, công thức, decision table).
- Lỗi chết người: trộn rule với UI, tái dùng ID, version thiếu ngày, không có owner nghiệp vụ.
- Là Designer, bạn có lợi thế tự nhiên: tư duy component hóa, tái sử dụng, và versioning từ design system chuyển thẳng sang rule book. Catalog chính là nơi kỹ năng cũ của bạn tỏa sáng trong vai trò mới.