Mở đầu — vì sao bài này quan trọng
Suốt chín bài trước, bạn đã được trang bị từng mảnh ghép riêng lẻ: BABOK, use case, SQL, BPMN, prioritization, stakeholder management, change management, testing và Agile. Mỗi công cụ tự thân đều mạnh, nhưng trên thực tế chẳng dự án nào "đặt hàng" bạn dùng đúng một kỹ thuật. Bài 10 này là bài tổng hợp — nơi tất cả mảnh ghép gặp nhau trên một sa bàn thật: xây dựng hệ thống Internet Banking cho một ngân hàng quy mô lớn.
Vì sao lại chọn ngân hàng? Vì lĩnh vực ngân hàng ép một BA phải trưởng thành nhanh nhất. Ở đây bạn không có quyền "làm sai rồi sửa". Một requirement viết mơ hồ về hạn mức chuyển tiền có thể dẫn tới rủi ro pháp lý; một quy trình eKYC thiếu bước xác thực có thể khiến ngân hàng bị Ngân hàng Nhà nước (NHNN) tuýt còi; một non-functional requirement về uptime bị bỏ sót có thể khiến hàng trăm nghìn khách hàng không rút được tiền vào đúng dịp Tết. Banking là môi trường mà sự mơ hồ trong yêu cầu phải trả giá bằng tiền thật và niềm tin thật.
Bài học này không dạy bạn thêm kỹ thuật mới. Nó dạy bạn cách một BA thực thụ tư duy xuyên suốt một dự án từ scenario mơ hồ tới bộ requirement có thể bàn giao — đúng thứ mà nhà tuyển dụng và kỳ thi CBAP đều muốn thấy ở bạn.
Khái niệm cốt lõi
Bối cảnh dự án (Project Context)
Ngân hàng ABC — một ngân hàng thương mại cổ phần tầm trung tại Việt Nam — muốn thay thế hệ thống Internet Banking đời cũ bằng một nền tảng số hiện đại. Quy mô:
- 500.000 khách hàng cá nhân (retail) đang sử dụng.
- 10.000 khách hàng doanh nghiệp (corporate) với nhu cầu phê duyệt nhiều cấp.
- Phải tuân thủ quy định của NHNN về định danh điện tử, hạn mức giao dịch và xác thực mạnh.
- Tích hợp với core banking hiện hữu (T24 hoặc tương đương), cổng thanh toán NAPAS, và hệ thống chống gian lận.
- Mục tiêu kinh doanh: tăng tỷ lệ giao dịch số từ 40% lên 75% trong 18 tháng, giảm chi phí vận hành chi nhánh.
Phân tầng stakeholder trong ngân hàng
Điều đầu tiên một BA dày dạn làm khi nhìn scenario này là vẽ bản đồ các bên liên quan, vì ngân hàng có cấu trúc stakeholder phức tạp bậc nhất:
- Business sponsors: Giám đốc khối Ngân hàng số (CDO), Giám đốc khối Bán lẻ.
- Regulatory / Compliance: bộ phận Pháp chế, Tuân thủ — đại diện gián tiếp cho NHNN.
- Risk & Fraud: đặt ra giới hạn về hạn mức, OTP, giám sát giao dịch bất thường.
- IT / Core banking team: chủ sở hữu hệ thống mà bạn phải tích hợp.
- End users: khách hàng cá nhân và doanh nghiệp — hai nhóm có nhu cầu rất khác nhau.
- Operations / Call center: người gánh hậu quả nếu UX kém.
Phân loại requirement theo BABOK
Trong case này, bạn sẽ chạm tới cả bốn tầng requirement theo BABOK:
- Business requirements: tăng tỷ lệ giao dịch số lên 75%, giảm chi phí chi nhánh.
- Stakeholder requirements: khách hàng doanh nghiệp cần luồng phê duyệt hai cấp (maker–checker); khối Bán lẻ cần onboarding eKYC dưới 5 phút.
- Solution requirements (functional + non-functional): "Hệ thống cho phép chuyển khoản liên ngân hàng 24/7 qua NAPAS" (functional); "Hệ thống đáp ứng 2.000 giao dịch/giây với thời gian phản hồi dưới 2 giây" (non-functional).
- Transition requirements: di chuyển 500.000 hồ sơ khách hàng từ hệ thống cũ; chạy song song hai hệ thống trong 3 tháng.
Tình huống thực tế
Ví dụ 1 — Hạn mức chuyển tiền: khi một con số định nghĩa cả luồng nghiệp vụ
Tại Ngân hàng ABC, BA nhận yêu cầu ban đầu từ khối Bán lẻ: "Cho phép khách hàng chuyển tiền nhanh." Câu này nghe đơn giản nhưng giấu trong nó hàng loạt requirement chưa được khai thác.
Khi BA tổ chức buổi elicitation với bộ phận Risk và Compliance, sự thật lộ ra: NHNN quy định giao dịch trên một ngưỡng nhất định (ví dụ trên 10 triệu đồng) phải dùng xác thực mạnh (Smart OTP hoặc sinh trắc học), còn dưới ngưỡng có thể dùng OTP SMS. Đồng thời, mỗi khách hàng có hạn mức ngày tùy theo cấp độ định danh.
Từ một câu mơ hồ, BA bóc tách thành bảng quyết định (decision table):
- Giao dịch ≤ 10 triệu, trong hạn mức ngày → SMS OTP.
- Giao dịch > 10 triệu hoặc tổng ngày vượt ngưỡng → Smart OTP + sinh trắc học.
- Khách hàng chưa nâng cấp eKYC đầy đủ → giới hạn 5 triệu/ngày.
Ví dụ 2 — eKYC: bài toán tích hợp và non-functional ẩn
Khối Ngân hàng số muốn khách hàng mới mở tài khoản hoàn toàn online qua eKYC. BA của ABC từng làm tương tự ở một ngân hàng khác nên biết rằng phần "khó nhằn" không nằm ở luồng chính, mà ở các non-functional và integration requirement.
Khi vẽ luồng nghiệp vụ (BPMN), BA phát hiện luồng eKYC phải gọi tới ba hệ thống bên ngoài: dịch vụ OCR đọc CCCD gắn chip, dịch vụ đối chiếu khuôn mặt (liveness check), và cơ sở dữ liệu định danh quốc gia của Bộ Công an (qua đối tác trung gian). Mỗi điểm tích hợp là một điểm có thể thất bại.
BA đặt câu hỏi mà business sponsor không nghĩ tới: "Nếu dịch vụ liveness check timeout sau 30 giây thì khách hàng thấy gì? Chúng ta retry hay chuyển sang xác thực thủ công tại quầy?" Từ đó sinh ra:
- NFR về độ trễ: phản hồi liveness < 8 giây ở phân vị 95.
- Requirement xử lý lỗi: fallback sang đặt lịch xác thực tại chi nhánh nếu eKYC thất bại 3 lần.
- Requirement về dữ liệu: lưu nhật ký kiểm toán mọi lần đối chiếu để phục vụ thanh tra.
Bài học rút ra: với hệ thống ngân hàng, "happy path" chỉ chiếm một phần nhỏ giá trị công việc của BA. Phần lớn giá trị nằm ở việc đặt câu hỏi về luồng ngoại lệ, điểm tích hợp và non-functional requirement mà không ai chủ động nói ra.
Ví dụ 3 — Maker–Checker cho khách hàng doanh nghiệp
10.000 khách hàng doanh nghiệp của ABC có một nhu cầu mà khách cá nhân không có: phân quyền và phê duyệt nhiều cấp. Kế toán viên (maker) lập lệnh chi lương cho 500 nhân viên; giám đốc tài chính (checker) phê duyệt; với khoản lớn cần thêm một cấp phê duyệt nữa.
Một BA thiếu kinh nghiệm sẽ mô hình hóa đây như "tính năng phê duyệt". BA dày dạn nhận ra đây là một mô hình phân quyền hoàn chỉnh cần use case riêng, role matrix riêng, và ràng buộc nghiệp vụ: maker không được tự duyệt lệnh của chính mình (segregation of duties), lệnh hết hạn nếu không duyệt trong 24 giờ, và mọi hành động phải truy vết được.
Khi viết user story Agile cho phần này, BA tách thành nhiều story nhỏ thay vì một story khổng lồ: tạo lệnh, gửi duyệt, từ chối kèm lý do, duyệt nhiều cấp, thông báo cho người duyệt. Definition of Ready yêu cầu mỗi story phải đính kèm role matrix và business rule tương ứng.
Bài học rút ra: cùng một hệ thống nhưng hai phân khúc khách hàng (retail vs corporate) gần như là hai sản phẩm khác nhau về mặt requirement. BA phải nhận diện sự phân nhánh này sớm để không gộp nhầm thành một luồng chung gây thiếu sót.
Hướng dẫn từng bước
Đây là quy trình tôi khuyên bạn áp dụng khi đối mặt với bất kỳ case study ngân hàng nào — và cũng là khung trả lời cho câu hỏi tình huống trong phỏng vấn BA:
Bước 1 — Hiểu bối cảnh và mục tiêu kinh doanh. Trước khi nghĩ tới tính năng, xác định business requirement gốc: ABC muốn 75% giao dịch số và giảm chi phí chi nhánh. Mọi requirement sau này phải truy vết được về mục tiêu này; cái nào không phục vụ mục tiêu thì cần chất vấn.
Bước 2 — Lập bản đồ stakeholder và lập kế hoạch elicitation. Liệt kê đủ các tầng (business, compliance, risk, IT, end users). Với ngân hàng, đưa Compliance vào từ ngày đầu, không để cuối. Chọn kỹ thuật phù hợp: workshop với business, phỏng vấn với compliance, quan sát với call center.
Bước 3 — Phân rã scope thành các nhóm năng lực (capability). Ví dụ: Onboarding/eKYC, Quản lý tài khoản, Chuyển tiền, Thanh toán hóa đơn, Phê duyệt doanh nghiệp, Bảo mật & xác thực. Cách chia này giúp ưu tiên và lập backlog theo module.
Bước 4 — Mô hình hóa luồng nghiệp vụ trọng yếu. Với mỗi capability, vẽ BPMN cho luồng chính rồi truy luồng ngoại lệ. Đặc biệt chú ý điểm tích hợp với core banking, NAPAS và dịch vụ bên thứ ba.
Bước 5 — Khai thác business rule và non-functional requirement. Đây là phần phân biệt BA ngân hàng với BA thông thường: hạn mức, ngưỡng xác thực, SLA uptime (ví dụ 99,9%), throughput, bảo mật, và yêu cầu kiểm toán (audit trail).
Bước 6 — Ưu tiên hóa. Dùng MoSCoW: eKYC và chuyển tiền là Must; cá nhân hóa dashboard có thể là Could. Cân nhắc cả ràng buộc pháp lý — một số thứ là Must không phải vì khách muốn mà vì luật bắt buộc.
Bước 7 — Đặc tả và truy vết. Viết requirement rõ ràng, gắn vào Requirements Traceability Matrix để mỗi requirement nối với mục tiêu kinh doanh ở một đầu và test case ở đầu kia. Trong ngân hàng, khả năng truy vết này còn phục vụ cả thanh tra.
Bước 8 — Xác nhận và thống nhất. Tổ chức review requirement với đủ các bên, đặc biệt là Compliance ký xác nhận trước khi chuyển sang phát triển.
Lỗi thường gặp & mẹo
Lỗi 1 — Bỏ qua Compliance tới phút chót. Trong ngân hàng, đây là lỗi đắt giá nhất. Mẹo: coi bộ phận Tuân thủ như một "stakeholder phủ quyết" — họ có quyền chặn cả dự án, nên phải tham gia từ đầu.
Lỗi 2 — Chỉ mô hình hóa happy path. Khách hàng nhập sai OTP ba lần, dịch vụ eKYC timeout, tài khoản bị khóa giữa giao dịch — đây mới là nơi requirement dễ thiếu. Mẹo: với mỗi luồng chính, ép bản thân liệt kê ít nhất ba luồng ngoại lệ.
Lỗi 3 — Gộp retail và corporate làm một. Hai phân khúc có nhu cầu phân quyền, hạn mức và UX rất khác. Mẹo: tách stakeholder requirement theo phân khúc ngay từ bước phân rã scope.
Lỗi 4 — Quên non-functional requirement. "Hệ thống cho chuyển tiền" mà không nói rõ uptime, throughput, thời gian phản hồi thì coi như chưa xong. Mẹo: với hệ thống ngân hàng, luôn hỏi về SLA, bảo mật, khả năng mở rộng và audit cho mỗi capability.
Lỗi 5 — Requirement không truy vết được. Khi thanh tra hỏi "tại sao có rule này", bạn phải chỉ ra nguồn. Mẹo: duy trì RTM ngay từ đầu, đừng để cuối dự án mới dựng.
Mẹo vàng: mỗi business rule trong ngân hàng nên được viết kèm "nguồn gốc" (quy định NHNN nào, chính sách nội bộ nào). Điều này cứu bạn vô số tranh cãi về sau.
Bài tập thực hành
Hãy đóng vai BA của Ngân hàng ABC và hoàn thành các nhiệm vụ sau:
- Bản đồ stakeholder: Lập danh sách tối thiểu 8 nhóm stakeholder cho dự án Internet Banking, với mỗi nhóm ghi rõ mối quan tâm chính và rủi ro nếu bỏ sót họ.
- Decision table cho xác thực giao dịch: Dựa trên ví dụ về hạn mức, xây dựng một bảng quyết định đầy đủ với ít nhất 4 nhánh, dựa trên số tiền giao dịch, tổng hạn mức ngày và cấp độ định danh của khách hàng.
- BPMN luồng eKYC: Vẽ luồng nghiệp vụ mở tài khoản online, bao gồm tối thiểu ba điểm tích hợp bên ngoài và hai luồng ngoại lệ (lỗi liveness, timeout OCR).
- Năm non-functional requirement: Viết 5 NFR cho hệ thống, mỗi cái phải có con số đo lường được (ví dụ uptime, throughput, thời gian phản hồi, thời gian khôi phục sau sự cố, dung lượng lưu nhật ký kiểm toán).
- Ưu tiên hóa MoSCoW: Phân loại 10 tính năng (eKYC, chuyển khoản nội bộ, chuyển khoản NAPAS, thanh toán hóa đơn, maker–checker, mở sổ tiết kiệm online, dashboard cá nhân hóa, chatbot hỗ trợ, thông báo đẩy, quản lý hạn mức) vào bốn nhóm M/S/C/W, kèm một câu lý giải cho mỗi tính năng — chú ý phân biệt "khách muốn" với "luật bắt buộc".
Tóm tắt
Bài 10 là điểm hội tụ của toàn bộ chương đầu tiên. Qua case study Ngân hàng ABC — 500.000 khách cá nhân, 10.000 doanh nghiệp, ràng buộc NHNN — bạn đã thấy cách một BA biến một scenario mơ hồ thành bộ requirement có cấu trúc, truy vết được và sẵn sàng bàn giao.
Những điều cốt lõi cần khắc ghi:
- Banking là môi trường nơi sự mơ hồ phải trả giá bằng tiền và niềm tin; vì vậy mỗi requirement đều cần nguồn gốc, điều kiện biên và khả năng truy vết.
- Stakeholder trong ngân hàng phải được phân tầng đầy đủ, đặc biệt là Compliance và Risk — đưa họ vào từ ngày đầu.
- Giá trị lớn nhất của BA nằm ở luồng ngoại lệ, điểm tích hợp và non-functional requirement, chứ không chỉ ở happy path.
- Retail và corporate gần như là hai sản phẩm khác nhau về mặt requirement — đừng gộp nhầm.
- Một quy trình tám bước, từ hiểu mục tiêu kinh doanh tới xác nhận với stakeholder, cho bạn khung làm việc lặp lại được cho bất kỳ dự án ngân hàng nào.