Mở đầu — vì sao bài này quan trọng
Có một sự thật mà nhiều người làm Finance/Kế toán không nhận ra cho đến khi họ ngồi vào ghế BA: kỹ năng kỹ thuật (đọc báo cáo, viết requirement, vẽ process flow) chỉ chiếm khoảng 40% công việc thực tế của một Business Analyst. 60% còn lại là làm việc với con người — phỏng vấn người dùng để hiểu họ thực sự cần gì, dàn xếp khi hai phòng ban muốn hai thứ trái ngược nhau, thuyết phục một sếp kế toán già khó tính rằng hệ thống mới sẽ không phá vỡ quy trình kiểm soát của ông ấy.
Đây chính là chỗ mà rất nhiều bạn Finance vấp ngã khi chuyển sang BA. Trong môi trường Finance/Kế toán, bạn quen với việc làm việc với số liệu — và số liệu thì không cãi lại bạn, không có "ý kiến riêng", không giấu thông tin vì sợ mất việc. Nhưng khi làm BA, "dữ liệu đầu vào" của bạn lại đến từ con người: những người thường nói một đằng làm một nẻo, mô tả quy trình theo cách họ nghĩ nó vận hành chứ không phải cách nó thực sự vận hành.
Tin tốt là: nền tảng Finance cho bạn những lợi thế cực lớn trong mảng này — sự tỉ mỉ, tư duy đặt câu hỏi hoài nghi, khả năng phát hiện điểm bất nhất. Bài này sẽ dạy bạn hai nhóm kỹ năng cốt lõi: User Research (nghiên cứu người dùng để hiểu nhu cầu thật) và Stakeholder Management (quản lý và làm việc với các bên liên quan). Đây không phải kỹ năng "mềm" mơ hồ — đây là kỹ năng có phương pháp, có quy trình, và hoàn toàn học được.
Khái niệm cốt lõi
User Research là gì và khác gì với việc "hỏi cho biết"
User Research là quá trình có hệ thống để tìm hiểu nhu cầu, hành vi, khó khăn (pain points) và bối cảnh làm việc của người dùng cuối — những người sẽ thực sự dùng hệ thống/giải pháp mà bạn xây. Điểm mấu chốt nằm ở chữ "có hệ thống": bạn không chỉ ngồi hỏi vu vơ "anh muốn gì", mà phải có giả thuyết, có câu hỏi được thiết kế sẵn, có cách ghi nhận và phân tích.
Với người Finance, hãy hình dung thế này: làm User Research giống như đối chiếu sổ sách (reconciliation). Khi đối chiếu, bạn không tin con số trên một báo cáo duy nhất — bạn so chéo từ nhiều nguồn (sổ cái, sao kê ngân hàng, hóa đơn) để tìm ra sự thật. User Research cũng vậy: bạn không tin lời một stakeholder duy nhất, mà thu thập từ nhiều người, nhiều góc nhìn, rồi tìm ra "sự thật" về nhu cầu thực sự.
Một nguyên tắc kinh điển bạn phải khắc cốt ghi tâm: người dùng giỏi mô tả vấn đề của họ, nhưng dở trong việc đề xuất giải pháp. Khi kế toán nói "tôi cần thêm một nút export ra Excel", đó thường không phải nhu cầu thật — nhu cầu thật là "tôi cần kiểm tra lại số liệu mà tôi không tin tưởng vào hệ thống". Việc của BA là đào sâu xuống dưới câu nói bề mặt đó.
Stakeholder là ai và vì sao phải "quản lý" họ
Stakeholder là bất kỳ ai có lợi ích, ảnh hưởng, hoặc bị tác động bởi dự án: sponsor (người chi tiền), end-user (người dùng cuối), dev team, phòng ban liên quan, bộ phận compliance, thậm chí khách hàng bên ngoài. Mỗi nhóm có mong muốn riêng, và thường mâu thuẫn nhau.
"Quản lý stakeholder" nghe có vẻ như chính trị văn phòng, nhưng thực chất là một kỹ năng phân tích: bạn phải biết ai có quyền lực (power) đến đâu, ai quan tâm (interest) đến mức nào, rồi điều chỉnh cách giao tiếp cho phù hợp. Công cụ kinh điển là Power/Interest Grid (ma trận Quyền lực/Quan tâm):
- Quyền lực cao + Quan tâm cao → Quản lý sát sao (Manage Closely): họp thường xuyên, cập nhật liên tục. Đây thường là sponsor, trưởng phòng nghiệp vụ.
- Quyền lực cao + Quan tâm thấp → Giữ hài lòng (Keep Satisfied): không làm phiền quá nhiều nhưng đừng để họ bất ngờ. Ví dụ: CFO chỉ quan tâm kết quả cuối.
- Quyền lực thấp + Quan tâm cao → Giữ thông tin (Keep Informed): nhóm end-user nhiệt tình, họ cung cấp insight quý nhưng ít quyền quyết định.
- Quyền lực thấp + Quan tâm thấp → Theo dõi (Monitor): cập nhật tối thiểu.
Lợi thế "ẩn" của người Finance trong hai kỹ năng này
Bạn có ba vũ khí mà dân IT thuần thường thiếu:
- Ngôn ngữ nghiệp vụ chung: Khi phỏng vấn một kế toán trưởng, bạn nói được "hạch toán", "bút toán điều chỉnh", "đối ứng tài khoản 131/331". Stakeholder lập tức tin tưởng bạn vì bạn "là người trong nghề". Một BA xuất thân IT phải mất hàng tuần để xây dựng độ tin cậy này.
- Tư duy hoài nghi có kỷ luật (professional skepticism): Dân kiểm toán/kế toán được rèn để không tin con số ngay, phải tìm bằng chứng. Đây chính xác là tư duy cần có khi đào pain point.
- Khả năng cấu trúc hóa: Bạn quen biến mớ hỗn độn thành báo cáo gọn gàng — kỹ năng này áp dụng thẳng vào việc tổng hợp findings từ user research.
Tình huống thực tế
Ví dụ 1: Cái nút export "giả tạo" tại một công ty fintech cho vay ở TP.HCM
Lan, một kế toán tổng hợp 6 năm kinh nghiệm, vừa chuyển sang làm BA tại một công ty fintech cho vay tiêu dùng (giả định, quy mô ~200 nhân viên). Dự án đầu tiên: nâng cấp module đối soát thanh toán. Đội vận hành (operations) yêu cầu rất rõ ràng: "Cho chúng tôi nút export toàn bộ giao dịch ra Excel mỗi cuối ngày."
BA "tay mơ" sẽ ghi luôn requirement đó vào tài liệu và chuyển cho dev. Nhưng Lan, với phản xạ kế toán, thấy ngờ ngợ: tại sao đã có hệ thống mà còn phải export ra Excel để làm gì? Cô ngồi quan sát trực tiếp (kỹ thuật observation) một bạn ops làm việc trong 2 tiếng. Cô phát hiện: bạn ops export ra Excel rồi dùng hàm VLOOKUP để đối chiếu với file sao kê từ đối tác thanh toán (payment gateway), vì hệ thống hiện tại không hiển thị mã giao dịch của đối tác.
Vậy nhu cầu thật không phải "nút export" — mà là "tự động đối soát giao dịch hệ thống với sao kê đối tác". Lan đề xuất xây tính năng auto-reconciliation. Kết quả: thay vì 3 tiếng làm thủ công mỗi ngày, đội ops chỉ mất 15 phút xử lý ngoại lệ. Con số tiết kiệm: ~60 giờ công/tháng.
Bài học: Đừng bao giờ nhận requirement ở dạng "giải pháp" rồi ghi chép lại. Hãy hỏi "5 lần Tại sao" (5 Whys) để đào xuống nhu cầu gốc. Quan sát thực tế (contextual inquiry) tiết lộ những thứ mà phỏng vấn không bao giờ chạm tới.
Ví dụ 2: Khi hai stakeholder muốn hai thứ trái ngược — dự án ERP tại một doanh nghiệp sản xuất
Tại một công ty sản xuất hàng tiêu dùng (giả định, doanh thu ~500 tỷ/năm), dự án triển khai phân hệ kế toán của ERP gặp bế tắc. Phòng Kế toán muốn hệ thống bắt buộc nhập đầy đủ chứng từ, mã chi phí, mã đối tượng trước khi cho ghi sổ — để đảm bảo dữ liệu sạch cho báo cáo. Phòng Kinh doanh thì phản đối kịch liệt: họ cần tạo đơn hàng nhanh, không muốn bị chặn vì thiếu vài trường thông tin.
Hùng — BA xuất thân kế toán — lập Power/Interest Grid: Giám đốc Tài chính (CFO) là sponsor, quyền lực cao + quan tâm cao → phải quản lý sát. Trưởng phòng Kinh doanh quyền lực cao + quan tâm trung bình → phải giữ hài lòng. Hai bên đang xung đột trực tiếp.
Thay vì chọn phe, Hùng tổ chức một buổi workshop chung. Anh dùng kỹ năng Finance để "phiên dịch": anh chỉ cho phòng Kinh doanh thấy rằng nếu dữ liệu sai, cuối tháng kế toán phải truy lại từng đơn, và chính đơn hàng của họ sẽ bị treo không xuất được hóa đơn VAT — ảnh hưởng doanh số ghi nhận. Giải pháp dung hòa: cho phép tạo đơn với thông tin tối thiểu (nhu cầu của Sales), nhưng đặt trạng thái "chờ bổ sung" và chặn bước xuất hóa đơn cho đến khi đủ thông tin kế toán (nhu cầu của Accounting).
Bài học: Xung đột stakeholder hiếm khi giải quyết bằng cách chọn ai đúng ai sai. BA giỏi tìm "lợi ích chung ẩn" phía sau hai lập trường đối nghịch. Người Finance có lợi thế đặc biệt vì hiểu được hệ quả tài chính của mỗi lựa chọn — đó là đòn bẩy thuyết phục cực mạnh.
Ví dụ 3: Phỏng vấn sai người tại một ngân hàng
Một BA mới vào nghề tại một ngân hàng (giả định) được giao tìm hiểu quy trình phê duyệt hạn mức tín dụng để số hóa. Cô phỏng vấn trưởng phòng tín dụng — người mô tả một quy trình 5 bước rất gọn gàng, "chuẩn sách giáo khoa". Cô viết requirement dựa trên đó. Khi hệ thống ra mắt, các chuyên viên thực thi phản đối dữ dội: thực tế họ làm 11 bước, với vô số trường hợp ngoại lệ mà sếp họ không hề biết hoặc đã quên.
Vấn đề: cô chỉ phỏng vấn người mô tả quy trình lý tưởng (sếp), mà bỏ qua người vận hành quy trình thật (chuyên viên). Đây là cái bẫy "as-imagined vs as-done" — quy trình như tưởng tượng khác xa quy trình như thực thi.
Bài học: Luôn phỏng vấn ở nhiều cấp. Sếp cho bạn bức tranh chiến lược và quy trình "nên là"; nhân viên tuyến đầu cho bạn sự thật về quy trình "đang là" với mọi ngoại lệ. Một BA Finance tốt biết rằng "quy trình trên giấy" và "quy trình thực tế" cũng khác nhau như "bảng cân đối kế toán đẹp" và "dòng tiền thật".
Hướng dẫn từng bước
Đây là quy trình thực hành một vòng User Research kết hợp Stakeholder Management cho một yêu cầu nghiệp vụ:
Bước 1 — Lập bản đồ stakeholder (Stakeholder Mapping). Liệt kê tất cả những ai liên quan. Với mỗi người, đánh giá Power (quyền lực) và Interest (mức quan tâm), đặt họ vào Power/Interest Grid. Xác định rõ ai là người ra quyết định cuối, ai cung cấp thông tin, ai có thể cản trở dự án.
Bước 2 — Xác định mục tiêu nghiên cứu. Trước khi gặp ai, hãy viết ra: "Tôi cần hiểu điều gì?". Ví dụ: "Hiểu vì sao quy trình đối soát hiện tại mất 3 giờ và đâu là điểm nghẽn." Mục tiêu rõ giúp bạn không lan man.
Bước 3 — Chọn kỹ thuật phù hợp. Bốn kỹ thuật cốt lõi:
- Phỏng vấn (Interview): hiểu sâu một cá nhân, hợp với stakeholder cấp quản lý.
- Quan sát (Observation/Contextual Inquiry): xem người dùng làm việc thật, lộ ra cái họ không nói.
- Khảo sát (Survey): thu thập dữ liệu định lượng từ nhiều người.
- Workshop: dung hòa nhiều bên cùng lúc, hợp khi có xung đột.
Bước 5 — Thực hiện và ghi nhận. Trong buổi phỏng vấn, lắng nghe nhiều hơn nói (nguyên tắc 80/20: bạn nói 20%, họ nói 80%). Ghi lại nguyên văn pain point, đừng vội diễn giải. Quan sát cả ngôn ngữ cơ thể và những chỗ họ ngập ngừng.
Bước 6 — Tổng hợp và đối chiếu chéo. Gom findings từ nhiều nguồn, tìm điểm trùng và điểm mâu thuẫn. Khi hai người nói khác nhau về cùng một quy trình — đó là vàng, vì nó chỉ ra chỗ quy trình thực sự có vấn đề.
Bước 7 — Xác nhận lại (Validation). Trình bày lại những gì bạn hiểu cho stakeholder: "Theo những gì tôi nghe được, vấn đề là... đúng không ạ?". Bước này tránh việc bạn hiểu sai mà cứ thế làm tiếp.
Lỗi thường gặp & mẹo
Lỗi 1: Hỏi giải pháp thay vì hỏi vấn đề. Khi stakeholder nói "tôi cần tính năng X", người mới thường ghi luôn. Mẹo: luôn hỏi ngược "Nếu có tính năng đó, nó giúp anh giải quyết điều gì?" để chạm tới nhu cầu gốc.
Lỗi 2: Câu hỏi dẫn dắt (leading questions). "Chắc anh muốn báo cáo nhanh hơn đúng không?" — câu này gài sẵn câu trả lời. Người Finance đôi khi quá tự tin vào hiểu biết nghiệp vụ nên vô tình áp đặt. Mẹo: giữ tư duy "người mới đến", để stakeholder dẫn dắt.
Lỗi 3: Chỉ phỏng vấn cấp cao. Như ví dụ 3, bỏ qua người vận hành tuyến đầu là sai lầm chết người. Mẹo: với mọi quy trình, luôn nói chuyện với ít nhất một người thực sự làm việc đó hằng ngày.
Lỗi 4: Mặc định "vì là người Finance nên tôi đã hiểu hết". Đây là cái bẫy lớn nhất của dân chuyển nghề. Quy trình ở công ty A khác công ty B, và bối cảnh số hóa thay đổi mọi thứ. Mẹo: dùng kiến thức nền để hỏi câu sâu hơn, không phải để bỏ qua việc hỏi.
Lỗi 5: Bỏ quên stakeholder "ẩn". Bộ phận compliance, kiểm toán nội bộ, IT security thường bị quên cho đến phút chót — rồi họ bác bỏ cả thiết kế. Mẹo: trong bước mapping, hỏi "ai có thể nói KHÔNG với dự án này?".
Mẹo vàng — kỹ thuật "im lặng có chủ đích": Sau khi stakeholder trả lời, đừng vội hỏi tiếp. Im lặng 3-4 giây. Sự im lặng tạo áp lực dễ chịu khiến họ nói thêm — và phần "nói thêm" đó thường mới là thông tin giá trị nhất.
Bài tập thực hành
Bài 1 — Lập Stakeholder Map. Hãy chọn một quy trình bạn từng làm thời Finance (ví dụ: quy trình duyệt thanh toán nhà cung cấp). Liệt kê tất cả stakeholder liên quan, vẽ Power/Interest Grid cho họ. Với mỗi nhóm, ghi rõ chiến lược giao tiếp (manage closely / keep satisfied / keep informed / monitor).
Bài 2 — Biến giải pháp thành vấn đề. Cho yêu cầu: "Tôi cần thêm cột ghi chú vào báo cáo công nợ." Hãy viết ra chuỗi 5 câu hỏi "Tại sao" để đào tới nhu cầu gốc thật sự. Tự đặt ra câu trả lời hợp lý cho mỗi câu.
Bài 3 — Thiết kế bộ câu hỏi phỏng vấn. Giả sử bạn cần tìm hiểu vì sao quy trình quyết toán cuối tháng của một phòng kế toán mất quá lâu. Viết 8 câu hỏi phỏng vấn mở (không dẫn dắt), trong đó có ít nhất 2 câu áp dụng kỹ thuật 5 Whys.
Bài 4 — Tình huống xung đột. Phòng Kế toán muốn kiểm soát chặt, phòng Sales muốn tốc độ. Viết một đoạn 150 từ mô tả cách bạn sẽ điều phối buổi workshop để tìm giải pháp dung hòa, vận dụng lợi thế hiểu biết tài chính của bạn.
Tóm tắt
User Research và Stakeholder Management là phần "con người" chiếm tới 60% công việc BA — và cũng là chỗ người Finance dễ vấp nhất nhưng cũng có lợi thế lớn nhất. Hãy nhớ ba điều cốt lõi:
- User Research là reconciliation cho con người: đừng tin một nguồn, đối chiếu chéo nhiều góc nhìn, đào xuống nhu cầu gốc bằng 5 Whys và quan sát thực tế. Người dùng giỏi mô tả vấn đề nhưng dở đề xuất giải pháp — đừng nhận requirement ở dạng giải pháp.
- Stakeholder Management là phân tích, không phải chính trị: dùng Power/Interest Grid để xác định ai cần quản lý sát, ai cần giữ hài lòng. Khi có xung đột, tìm lợi ích chung ẩn thay vì chọn phe — và tận dụng hiểu biết tài chính để "phiên dịch" hệ quả cho từng bên.
- Lợi thế Finance của bạn là có thật: ngôn ngữ nghiệp vụ chung, tư duy hoài nghi có kỷ luật, khả năng cấu trúc hóa. Nhưng đừng để nó thành cái bẫy "tôi đã hiểu hết" — hãy dùng nó để hỏi sâu hơn, không phải để bỏ qua việc hỏi.