Mở đầu — vì sao bài này quan trọng
Hãy hình dung bạn vừa nhận vào làm Business Analyst cho một ngân hàng số. Tuần đầu tiên, một lập trình viên hỏi bạn: "Khách hàng dưới 18 tuổi có được mở thẻ tín dụng không?". Bạn gật đầu chắc nịch là "không". Nhưng tuần sau, phòng pháp chế lại nói: "Nếu có người giám hộ ký bảo lãnh thì vẫn được, theo chính sách mới từ quý này". Vậy đâu mới là câu trả lời đúng?
Vấn đề ở đây không phải là ai đúng ai sai, mà là doanh nghiệp đang vận hành dựa trên những quy tắc kinh doanh (business rules) không được viết ra rõ ràng, nằm rải rác trong đầu nhiều người, trong vài email cũ và trong dòng code mà không ai dám đụng vào. Khi quy tắc nằm trong đầu người, nó sẽ tam sao thất bản, mâu thuẫn nhau và biến mất khi nhân sự nghỉ việc.
Quy tắc kinh doanh chính là phần "luật chơi" định nghĩa cách thức một doanh nghiệp được phép và không được phép hành xử. Đây là một trong những tài sản quan trọng nhất mà một BA phải khám phá, tài liệu hóa và quản lý. Khi bạn làm tốt việc này, đội phát triển code đúng ngay từ đầu, phòng pháp chế yên tâm, và quan trọng nhất: khi chính sách thay đổi, bạn biết chính xác cần sửa ở đâu mà không phải đào bới lại toàn bộ hệ thống. Bài học hôm nay sẽ trang bị cho bạn tư duy và công cụ để biến những "luật bất thành văn" đó thành tài sản có thể quản lý được.
Khái niệm cốt lõi
Quy tắc kinh doanh là gì?
Một 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 nào đó của hoạt động kinh doanh. Nó nhằm khẳng định cấu trúc của doanh nghiệp, hoặc kiểm soát/tác động đến hành vi của doanh nghiệp. Điểm mấu chốt: quy tắc kinh doanh thuộc về nghiệp vụ, không phải về công nghệ. Nó tồn tại độc lập với việc bạn dùng phần mềm nào, ngôn ngữ lập trình gì.
Ví dụ ngắn:
- "Đơn hàng trên 500.000đ được miễn phí giao hàng nội thành."
- "Mỗi tài khoản chỉ được dùng một mã giảm giá cho mỗi đơn."
- "Khách hàng VIP là khách có tổng chi tiêu 12 tháng gần nhất trên 50 triệu đồng."
Phân biệt quy tắc kinh doanh với yêu cầu (requirement)
Đây là chỗ nhiều BA mới hay nhầm. Yêu cầu mô tả hệ thống phải làm gì ("hệ thống phải tự động áp dụng miễn phí ship"). Quy tắc kinh doanh mô tả luật nghiệp vụ đứng sau ("đơn trên 500.000đ được miễn phí ship nội thành"). Một quy tắc có thể được thực thi bởi nhiều yêu cầu khác nhau, và nó vẫn đúng kể cả khi bạn chưa có phần mềm nào. Tách bạch hai thứ này giúp khi luật thay đổi (ví dụ ngưỡng đổi từ 500.000đ sang 300.000đ), bạn chỉ sửa quy tắc, không phải viết lại cả tá yêu cầu.
Bốn loại quy tắc kinh doanh thường gặp
Theo khung tư duy phổ biến trong phân tích nghiệp vụ, ta thường chia quy tắc kinh doanh thành các nhóm:
- Định nghĩa thuật ngữ (Terms/Definitions) — làm rõ một khái niệm nghĩa là gì. Ví dụ: "Khách hàng đang hoạt động" = khách có ít nhất một giao dịch trong 90 ngày gần nhất.
- Sự kiện/Quan hệ (Facts) — phát biểu mối quan 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."
- Ràng buộc (Constraints) hay quy tắc hành vi — quy định điều gì phải/không được làm. Ví dụ: "Không được giao hàng nếu khách chưa thanh toán cọc."
- Suy luận/Tính toán (Derivations/Computations) — quy tắc tạo ra dữ liệu mới từ dữ liệu sẵn có. Ví dụ: "Điểm thưởng = 1% giá trị đơn hàng, làm tròn xuống."
Phân tích quyết định (Decision Analysis) và Bảng quyết định
Khi một quyết định nghiệp vụ phụ thuộc vào nhiều quy tắc cùng lúc, viết từng câu rời rạc sẽ rối và dễ sót trường hợp. Lúc này ta dùng bảng quyết định (decision table) — một bảng liệt kê các điều kiện đầu vào và hành động đầu ra tương ứng.
Cấu trúc cơ bản gồm: các cột điều kiện (input), các cột hành động (output), và mỗi dòng là một "luật" (rule) ứng với một tổ hợp điều kiện. Sức mạnh của bảng quyết định là buộc bạn liệt kê đầy đủ mọi tổ hợp, nhờ đó phát hiện ngay các trường hợp bị bỏ quên hoặc mâu thuẫn.
Ngày nay trong ngành còn có chuẩn DMN (Decision Model and Notation) giúp mô hình hóa quyết định một cách trực quan và chuẩn hóa, nhưng về bản chất nó vẫn xoay quanh tư duy bảng quyết định mà bạn sắp học.
Nguyên tắc vàng: tách quy tắc ra khỏi quy trình
Một nguyên tắc cốt lõi: quy tắc nên được tách rời khỏi quy trình và khỏi code. Khi quy tắc "lương thưởng tính thế nào" bị chôn cứng trong 15 chỗ khác nhau của hệ thống, mỗi lần ban giám đốc đổi chính sách là một cơn ác mộng. Ngược lại, khi quy tắc được quản lý tập trung (trong một tài liệu, một bảng cấu hình, hoặc một công cụ quản lý quy tắc), việc thay đổi trở nên nhanh, an toàn và truy vết được.
Tình huống thực tế
Tình huống 1: Tiki và quy tắc miễn phí vận chuyển
Giả định một sàn thương mại điện tử như Tiki triển khai chương trình "Freeship". Ban đầu, quy tắc chỉ đơn giản: "Đơn trên 250.000đ được miễn phí ship". Đội kỹ thuật viết thẳng con số 250.000 vào code thanh toán.
Sáu tháng sau, marketing muốn nâng cấp: khách thành viên TikiNOW được freeship không cần điều kiện; đơn hàng quốc tế không áp dụng; và ngưỡng cho hàng cồng kềnh là 1.000.000đ. Lúc này quy tắc "một dòng" ngày xưa bùng nổ thành cả chục trường hợp. Vì con số nằm rải rác trong code, mỗi lần đổi là phải nhờ lập trình viên, chờ release, và đã có lần một campaign bị áp sai ngưỡng khiến công ty lỗ phí ship trong hai ngày.
Bài học: Nếu ngay từ đầu BA tài liệu hóa freeship dưới dạng một bảng quyết định với các điều kiện (loại khách, loại hàng, vùng giao, giá trị đơn) và đầu ra (miễn phí / tính phí), đồng thời yêu cầu kỹ thuật đưa các ngưỡng ra thành cấu hình thay vì hard-code, thì mọi thay đổi chính sách sau này chỉ là chỉnh một bảng — không cần đụng code, không cần chờ release.
Tình huống 2: Ngân hàng số và quy tắc duyệt vay tiêu dùng
Một ngân hàng số tại Việt Nam (ví dụ giả định "Ngân hàng VPV") xây dựng tính năng duyệt vay tiêu dùng tự động. Quyết định "có cho vay hay không" phụ thuộc nhiều điều kiện: độ tuổi, thu nhập hàng tháng, điểm tín dụng CIC, và lịch sử nợ xấu.
Ban đầu mỗi điều kiện được phòng tín dụng mô tả bằng lời trong email, dẫn đến mâu thuẫn: một email nói "thu nhập trên 8 triệu là đủ", email khác nói "trên 10 triệu nếu chưa có lịch sử tín dụng". BA quyết định gom tất cả vào một bảng quyết định:
| Tuổi | Thu nhập/tháng | Điểm CIC | Có nợ xấu | Kết quả |
|---|---|---|---|---|
| 20–60 | ≥ 10 triệu | Tốt | Không | Duyệt tự động |
| 20–60 | 8–10 triệu | Tốt | Không | Chuyển thẩm định thủ công |
| 20–60 | bất kỳ | bất kỳ | Có | Từ chối |
| < 20 hoặc > 60 | bất kỳ | bất kỳ | bất kỳ | Từ chối |
Bài học: Bảng quyết định không chỉ để ghi lại quyết định, mà còn là công cụ kiểm tra tính đầy đủ (mọi tổ hợp đều có lối ra) và tính nhất quán (không có hai dòng cho ra kết quả khác nhau với cùng đầu vào). Đây là giá trị mà mô tả bằng văn xuôi không bao giờ đạt được.
Tình huống 3: Chuỗi cà phê và quy tắc tích điểm thành viên
Một chuỗi cà phê (giả định "Cà phê Sài Gòn 24") triển khai app tích điểm. Quy tắc gốc: "1.000đ chi tiêu = 1 điểm, 100 điểm đổi 1 ly miễn phí". Nghe đơn giản, nhưng khi vận hành phát sinh hàng loạt câu hỏi: Điểm có hết hạn không? Mua bằng voucher có được tích điểm không? Nhân viên tự mua có tích không?
BA đã tài liệu hóa thành các quy tắc rõ ràng theo loại:
- Tính toán (derivation): Điểm tích = số tiền thực trả (không gồm voucher) chia 1.000, làm tròn xuống.
- Ràng buộc (constraint): Điểm hết hạn sau 12 tháng kể từ lần tích cuối.
- Định nghĩa (term): "Số tiền thực trả" = tổng hóa đơn trừ phần thanh toán bằng voucher/điểm.
Bài học: Phân loại quy tắc giúp bạn tài liệu hóa đúng chỗ và phát hiện các tương tác nguy hiểm giữa các quy tắc với nhau — đặc biệt là các quy tắc tính toán có thể tạo vòng lặp.
Hướng dẫn từng bước
Dưới đây là quy trình thực hành để bạn xác định, tài liệu hóa và quản lý quy tắc kinh doanh trong một dự án thật.
Bước 1 — Phát hiện quy tắc (Elicitation). Săn tìm quy tắc ở mọi nơi: phỏng vấn người dùng nghiệp vụ, đọc tài liệu chính sách, văn bản pháp luật, và đặc biệt là quan sát những câu bắt đầu bằng "nếu... thì...", "chỉ được phép khi...", "luôn luôn...", "không bao giờ...". Đừng quên khai thác cả các trường hợp ngoại lệ — chúng thường chính là những quy tắc bị giấu kín.
Bước 2 — Phát biểu mỗi quy tắc thành một câu rõ ràng, nguyên tử. Mỗi quy tắc nên độc lập, không mơ hồ, không gộp nhiều ý. "Khách VIP được giảm 10% và miễn phí ship" nên tách thành hai quy tắc riêng để mỗi cái thay đổi được độc lập.
Bước 3 — Phân loại. Gán mỗi quy tắc vào một trong bốn loại (định nghĩa, sự kiện, ràng buộc, tính toán). Việc này quyết định cách bạn sẽ tài liệu hóa và kiểm thử nó.
Bước 4 — Gán mã định danh và thuộc tính quản lý. Mỗi quy tắc cần một ID (ví dụ BR-012), nguồn gốc (ai/văn bản nào ban hành), ngày hiệu lực, người sở hữu nghiệp vụ (business owner), và mức độ ưu tiên. Đây là nền tảng cho việc quản lý và truy xuất sau này.
Bước 5 — Lập bảng quyết định cho các quyết định phức tạp. Khi nhiều quy tắc cùng quyết định một kết quả, dựng bảng quyết định. Liệt kê tất cả điều kiện, sinh ra mọi tổ hợp, gán hành động cho từng tổ hợp. Kiểm tra hai tính chất: đầy đủ (không sót tổ hợp) và nhất quán (không mâu thuẫn).
Bước 6 — Xác nhận với các bên liên quan. Đưa quy tắc và bảng quyết định cho người sở hữu nghiệp vụ và pháp chế xác nhận. Quy tắc chưa được duyệt thì chưa được coi là chính thức.
Bước 7 — Tách quy tắc ra khỏi thiết kế kỹ thuật. Khuyến nghị đội phát triển đưa các giá trị có thể đổi (ngưỡng, tỷ lệ, danh sách) thành cấu hình hoặc dùng công cụ quản lý quy tắc, thay vì hard-code.
Bước 8 — Duy trì và phiên bản hóa. Quy tắc kinh doanh sống và thay đổi theo thời gian. Lưu trữ tập trung (một repository quy tắc), ghi lại lịch sử thay đổi, và liên kết mỗi quy tắc với các yêu cầu/chức năng bị ảnh hưởng để khi cần đổi, bạn biết chính xác phạm vi tác động.
Lỗi thường gặp & mẹo
Lỗi 1 — Chôn quy tắc trong code hoặc trong đầu người. Đây là lỗi đắt giá nhất. Mẹo: mỗi khi nghe ai đó nói một điều kiện nghiệp vụ, hãy hỏi ngay "điều này có được viết ở đâu chính thức không?". Nếu câu trả lời là không, bạn vừa tìm thấy một quy tắc cần tài liệu hóa.
Lỗi 2 — Gộp quy tắc với yêu cầu. Khi bạn viết "hệ thống phải kiểm tra tuổi trên 18", bạn đã trộn lẫn. Tách ra: quy tắc là "khách phải đủ 18 tuổi để mở tài khoản"; yêu cầu là "hệ thống phải chặn đăng ký nếu tuổi dưới 18 và hiển thị thông báo".
Lỗi 3 — Quy tắc mơ hồ. "Khách hàng quan trọng được ưu tiên" là vô dụng vì "quan trọng" và "ưu tiên" không định lượng được. Mẹo: mọi tính từ định tính phải được quy đổi thành tiêu chí đo được.
Lỗi 4 — Bảng quyết định thiếu trường hợp. Rất dễ quên các tổ hợp biên (giá trị bằng 0, âm, null, ranh giới ngưỡng). Mẹo: với mỗi điều kiện số, luôn kiểm tra ba điểm — dưới ngưỡng, đúng ngưỡng, trên ngưỡng. Trường hợp "bằng đúng 500.000đ" có được freeship không? Phải trả lời được.
Lỗi 5 — Không xác định người sở hữu quy tắc. Khi không ai "sở hữu" quy tắc, không ai chịu trách nhiệm cập nhật khi luật đổi. Mẹo: mỗi quy tắc bắt buộc có một business owner tên cụ thể.
Mẹo tổng quát: Hãy coi tập quy tắc kinh doanh như một tài sản sống có vòng đời riêng. Một bộ quy tắc tốt là bộ quy tắc mà người mới vào đọc xong là hiểu doanh nghiệp vận hành thế nào, và khi chính sách đổi thì chỉ cần sửa một chỗ.
Bài tập thực hành
Bài tập 1 — Săn và phát biểu quy tắc. Chọn một dịch vụ bạn dùng hằng ngày (Grab, Shopee, ví MoMo...). Liệt kê tối thiểu 8 quy tắc kinh doanh mà bạn quan sát được (ví dụ chính sách hủy chuyến, điều kiện hoàn tiền, ngưỡng phí dịch vụ). Phát biểu mỗi quy tắc thành một câu nguyên tử, rõ ràng, đo được.
Bài tập 2 — Phân loại. Với 8 quy tắc ở Bài tập 1, gán mỗi quy tắc vào một trong bốn loại (định nghĩa / sự kiện / ràng buộc / tính toán). Giải thích ngắn vì sao bạn xếp loại như vậy.
Bài tập 3 — Dựng bảng quyết định. Cho tình huống phí giao hàng của một shop online với các điều kiện: giá trị đơn (dưới 200k / 200k–500k / trên 500k), khu vực (nội thành / ngoại thành), và loại khách (thường / thành viên). Hãy lập bảng quyết định đầy đủ cho mức phí giao hàng đầu ra. Sau khi lập xong, kiểm tra: có tổ hợp nào bị thiếu không? Có hai dòng nào mâu thuẫn không?
Bài tập 4 — Phát hiện lỗ hổng. Quay lại bảng duyệt vay ở Tình huống 2. Hãy tìm thêm ít nhất hai tổ hợp điều kiện chưa được bảng xử lý, và đề xuất kết quả cho từng tổ hợp đó. Đây chính là kỹ năng quan trọng nhất của một BA giỏi: nhìn ra cái còn thiếu.
Tóm tắt
Quy tắc kinh doanh là phần "luật chơi" định nghĩa cách một doanh nghiệp được phép hành xử, và nó thuộc về nghiệp vụ chứ không phải công nghệ. Nhiệm vụ của BA là phát hiện, phát biểu rõ ràng, phân loại, tài liệu hóa và quản lý những quy tắc này thay vì để chúng nằm ẩn trong code hay trong đầu người.
Bốn loại quy tắc cốt lõi — định nghĩa, sự kiện, ràng buộc, tính toán — giúp bạn tài liệu hóa và kiểm thử đúng cách. Khi một quyết định phụ thuộc nhiều điều kiện, bảng quyết định là công cụ mạnh nhất để đảm bảo tính đầy đủ và nhất quán, đồng thời phơi bày những trường hợp bị bỏ sót trước khi chúng thành sự cố thật.
Cuối cùng, hãy nhớ nguyên tắc vàng: tách quy tắc ra khỏi quy trình và khỏi code, gán cho mỗi quy tắc một ID, một người sở hữu và một vòng đời quản lý. Làm được điều này, bạn biến những "luật bất thành văn" mong manh thành một tài sản bền vững, dễ thay đổi và dễ kiểm soát — đúng giá trị mà một Business Analyst chuyên nghiệp mang lại cho tổ chức.