Business Analysis Core Concept Model(BACCM)
Sáu khái niệm Change, Need, Solution, Stakeholder, Value, Context tạo thành bộ khung tư duy của BABOK v3. Sáu cái gắn chặt nhau, đổi một cái là phải xem lại năm cái còn lại.
Định nghĩa
Chương 2 của BABOK v3 giới thiệu một mô hình chỉ có sáu ô, không mũi tên quy trình, không thứ tự. Nhìn qua thì đơn giản tới mức dễ bỏ qua. Nhưng nếu dùng đúng, sáu ô này là bộ câu hỏi kiểm tra nhanh cho bất kỳ yêu cầu nào rơi vào tay bạn.
Sáu khái niệm ngang hàng nhau, không cái nào là gốc. Thay đổi một cái buộc bạn phải xem lại năm cái còn lại.
Sáu khái niệm
| Khái niệm | Câu hỏi tự đặt | Ví dụ trong một dự án app giao hàng |
|---|---|---|
| Change — thay đổi | Ta đang làm cho cái gì khác đi | Tài xế tự nhận đơn thay vì chờ điều phối gọi |
| Need — nhu cầu | Vấn đề hoặc cơ hội thật sự là gì | Điều phối viên gọi 200 cuộc mỗi ngày, sai sót cao |
| Solution — giải pháp | Cách nào đáp ứng được nhu cầu | App cho tài xế, hoặc quy trình gán đơn tự động |
| Stakeholder — bên liên quan | Ai bị ảnh hưởng, ai quyết định | Tài xế, điều phối, kế toán, khách hàng cuối |
| Value — giá trị | Được gì, mất gì, ai hưởng | Giảm thời gian gán đơn, giảm sai địa chỉ |
| Context — bối cảnh | Ràng buộc xung quanh là gì | Tài xế dùng điện thoại cũ, sóng 3G ở tỉnh chập chờn |
Sáu khái niệm này cũng là từ vựng nền cho toàn bộ phần còn lại của BABOK, nên hiểu sai một cái là đọc các chương sau bị lệch theo.
Cách dùng như một checklist
Mỗi khi nhận một yêu cầu mới, chạy nhanh sáu câu hỏi trên. Nếu có ô nào bạn trả lời không được, đó chính là chỗ cần đi hỏi thêm trước khi viết bất cứ dòng đặc tả nào.
Ô hay trống nhất theo trải nghiệm của mình là Value và Context. Người ta mô tả rất kỹ tính năng muốn có, nhưng hỏi "cái này giúp ai tiết kiệm được gì" thì im lặng, và hỏi "hiện tại đang có ràng buộc gì" thì được câu trả lời là không có gì đâu, cứ làm đi.
Ví dụ thực tế
"Sao mình không cho khách đặt lịch trước trên app, khỏi phải ngồi bốc số?" Câu hỏi rơi ra giữa một buổi họp sản phẩm ở ngân hàng, và nghe thì hợp lý tới mức chẳng ai cãi.
Chạy BACCM trước khi gật:
- Change: khách chọn giờ trước thay vì tới lấy số thứ tự.
- Need: giờ cao điểm 11h–13h ở bảy chi nhánh trung tâm, khách chờ trung bình 43 phút.
- Solution: đặt lịch qua app là một phương án. Nhưng còn phương án khác là mở thêm quầy trong khung giờ đó, hoặc chuyển ba nghiệp vụ đơn giản nhất lên online hẳn.
- Stakeholder: khách hàng, giao dịch viên, trưởng chi nhánh, đội vận hành app, bộ phận tuân thủ.
- Value: giảm thời gian chờ. Nhưng đo bằng gì, và nếu khách đặt lịch rồi không tới thì quầy trống có tính là thiệt hại không.
- Context: quy định định danh khách hàng, chỉ tiêu doanh số của giao dịch viên, và một hệ thống xếp hàng đã có sẵn từ 2019 chưa có API.
Chính ô Context lôi ra được vấn đề lớn nhất: hệ thống xếp hàng cũ không có API, nên hoặc phải tích hợp qua database, hoặc phải thay luôn. Câu hỏi đó nếu để tới lúc dev bắt tay vào làm mới phát hiện thì đã trễ ba tuần.
Chỗ dễ hiểu sai
Nhiều người coi BACCM như một quy trình sáu bước, làm từ Change tới Context. Không phải. Nó là sáu góc nhìn cùng tồn tại, bạn xoay qua xoay lại chứ không đi một chiều.
Một nhầm lẫn khác là gộp Need với Solution. Khi khách nói "tôi cần một dashboard", đó là solution họ đã tự nghĩ ra. Need nằm phía sau, có thể là "trưởng phòng phải chờ tới thứ hai mới biết doanh số tuần trước". Tách được hai cái này ra là bạn đã làm được phần khó nhất của nghề.
Lấy một yêu cầu đang nằm trong backlog của bạn, điền thử sáu ô. Ô nào trống là một câu hỏi bạn còn nợ ai đó.
