Mở đầu — vì sao bài này quan trọng
Nếu bạn đang làm Finance hoặc Kế toán và muốn chuyển sang BA (Business Analyst), thì câu hỏi đầu tiên — và cũng là câu hỏi quan trọng nhất — không phải là "BA học gì để chuyển" mà là "BA thực sự làm cái gì, và nó liên quan thế nào tới những thứ tôi đã làm hàng ngày?". Rất nhiều người mất sáu tháng đầu chỉ để loay hoay học công cụ (Jira, BPMN, SQL) mà không hiểu bản chất công việc, dẫn đến cảm giác mình đang bắt đầu lại từ con số 0. Đó là một hiểu lầm tốn kém.
Sự thật là: phần lớn công việc BA xoay quanh việc hiểu một quy trình kinh doanh đang chạy thế nào, tìm ra chỗ tắc nghẽn hoặc rủi ro, rồi mô tả chính xác cách hệ thống/phần mềm phải xử lý để giải quyết. Và đoán xem — đó chính xác là tư duy mà một người làm Finance/Kế toán đã rèn luyện suốt nhiều năm. Bạn không bắt đầu từ 0. Bạn bắt đầu từ khoảng 40–50%, chỉ là chưa ai chỉ cho bạn thấy phần vốn liếng đó nằm ở đâu.
Bài học này sẽ làm rõ hai điều: (1) BA thực chất là gì — định nghĩa đúng, không phải định nghĩa marketing — và (2) các quy trình Finance mà bạn đang quen thuộc thực ra là một "sân tập" hoàn hảo để hiểu công việc BA. Sau bài này, bạn sẽ nhìn vào công việc kế toán hiện tại của mình và thấy nó dưới một lăng kính khác: như một chuỗi các business process đang chờ được phân tích.
Khái niệm cốt lõi
BA là gì — định nghĩa đúng
Theo định nghĩa của IIBA (International Institute of Business Analysis — tổ chức chuẩn nghề BA toàn cầu), Business Analysis là việc khám phá nhu cầu (needs) và đề xuất giải pháp (solutions) mang lại giá trị cho các bên liên quan. Nói cho dễ hiểu: BA là người đứng giữa, dịch ngôn ngữ "mong muốn của business" thành ngôn ngữ "yêu cầu để team kỹ thuật xây dựng được".
Hãy bóc tách công việc đó thành bốn hoạt động lõi:
- Hiểu vấn đề và mục tiêu kinh doanh — Vì sao công ty cần làm cái này? Nó tạo ra giá trị gì (giảm chi phí, tăng doanh thu, giảm rủi ro, tuân thủ quy định)?
- Khai thác và phân tích yêu cầu (elicitation & analysis) — Đi hỏi đúng người, đào ra cái họ thực sự cần (thường khác cái họ nói), rồi sắp xếp thành yêu cầu có cấu trúc.
- Mô tả yêu cầu rõ ràng (documentation) — Viết ra dưới dạng tài liệu, sơ đồ quy trình, quy tắc nghiệp vụ để dev và tester hiểu giống nhau.
- Đảm bảo giải pháp đúng (validation) — Kiểm tra lại rằng cái team xây ra đúng với cái business cần.
Vì sao Finance/Kế toán là nền tảng mạnh cho BA
Bây giờ hãy đặt bốn hoạt động lõi của BA cạnh công việc Finance hàng ngày của bạn. Bạn sẽ thấy chúng phản chiếu nhau đến mức đáng kinh ngạc:
- Tư duy quy trình (process thinking): Một bút toán không tồn tại đơn lẻ. Nó nằm trong một chu trình — ví dụ chu trình mua hàng - phải trả (Purchase-to-Pay): đặt hàng, nhận hàng, nhận hóa đơn, đối chiếu 3 chiều (3-way matching), ghi nhận công nợ, thanh toán. Bạn đã quen với việc nhìn một nghiệp vụ như một chuỗi các bước có đầu vào, đầu ra và điều kiện. Đó chính xác là cách BA mô tả một business process.
- Tư duy quy tắc nghiệp vụ (business rules): "Hóa đơn trên 20 triệu phải có phê duyệt của trưởng phòng." "VAT đầu vào chỉ được khấu trừ khi có hóa đơn hợp lệ và thanh toán không dùng tiền mặt với giá trị từ 20 triệu trở lên." Bạn làm việc với business rules mỗi ngày — chúng chính là thứ BA phải đi thu thập và viết thành tài liệu cho hệ thống.
- Tư duy đối chiếu và kiểm soát (reconciliation & control): Khi bạn đối chiếu sổ phụ ngân hàng với sổ kế toán, bạn đang làm chính xác việc một BA làm khi kiểm tra dữ liệu giữa hai hệ thống tích hợp. Tư duy "phải khớp, nếu lệch thì truy nguyên nhân" là một tài sản hiếm trong nghề BA.
- Tư duy chính xác và truy vết (precision & audit trail): Trong kế toán, mọi con số phải có chứng từ, mọi điều chỉnh phải có dấu vết. Khả năng đòi hỏi sự rõ ràng tuyệt đối này khiến tài liệu yêu cầu của một ex-Finance thường rõ ràng, ít mơ hồ hơn nhiều so với người không có nền tảng này.
- Hiểu cách tiền chảy trong doanh nghiệp: Bạn hiểu doanh thu được ghi nhận thế nào, chi phí phân bổ ra sao, dòng tiền vận hành thế nào. Trong rất nhiều dự án phần mềm — đặc biệt fintech, ERP, e-commerce — đây là kiến thức domain mà công ty phải mất công đào tạo cho một BA "tay ngang". Bạn đã có sẵn.
Một điểm phân biệt cần nhớ
Finance/Kế toán nhìn vào kết quả (con số đã xảy ra, báo cáo, tuân thủ). BA nhìn vào cách vận hành tạo ra kết quả đó và cách cải tiến nó. Đây là sự dịch chuyển tư duy quan trọng nhất: từ "ghi nhận điều đã xảy ra" sang "thiết kế cách điều đó nên xảy ra". Chúng ta sẽ đào sâu khác biệt mindset này ở các bài sau, nhưng ngay bây giờ bạn cần ý thức được hướng dịch chuyển.
Tình huống thực tế
Tình huống 1: Kế toán công nợ tại một công ty phân phối FMCG
Chị Hương làm kế toán công nợ phải thu (AR) tại một nhà phân phối hàng tiêu dùng ở TP.HCM, doanh thu khoảng 300 tỷ/năm. Mỗi cuối tháng, chị mất gần một tuần để đối chiếu công nợ với hơn 200 đại lý: tải dữ liệu từ phần mềm kế toán, ghép với file Excel theo dõi đặt hàng của phòng sales, gọi điện xác nhận từng khoản chênh lệch.
Khi công ty triển khai một hệ thống DMS (Distribution Management System) mới, BA của nhà cung cấp phần mềm phỏng vấn chị để hiểu quy trình. Chị Hương, dù chưa biết gì về BA, đã mô tả cực kỳ rõ: "Một khoản phải thu phát sinh khi đơn hàng được giao và khách ký nhận. Hạn thanh toán mặc định là 30 ngày, nhưng đại lý loại A được 45 ngày. Nếu quá hạn 15 ngày thì hệ thống phải khóa không cho đặt đơn mới." Chị vừa đọc ra một loạt business rules và một state machine (trạng thái của khoản phải thu: phát sinh → trong hạn → quá hạn → khóa) mà không hề biết tên gọi kỹ thuật của chúng.
Bài học rút ra: Người làm Finance đã sở hữu sẵn cách diễn đạt quy trình theo bước, theo điều kiện, theo trạng thái. Cái họ thiếu chỉ là từ vựng của nghề BA (business rule, state, validation) chứ không phải tư duy. Sau dự án đó, chị Hương được chính nhà cung cấp phần mềm mời về làm BA cho mảng tài chính — vì họ nhận ra một người hiểu nghiệp vụ AR sâu như vậy hiếm hơn nhiều so với một BA biết viết tài liệu.
Tình huống 2: Chuyên viên FP&A và bài toán tự động hóa báo cáo
Anh Tuấn làm Financial Planning & Analysis tại một chuỗi bán lẻ ở Hà Nội. Công việc của anh là gom số liệu bán hàng từ 40 cửa hàng, lập báo cáo P&L theo cửa hàng mỗi tuần. Anh xây một file Excel khổng lồ với hàng chục công thức VLOOKUP và pivot.
Khi ban giám đốc muốn có dashboard real-time thay vì báo cáo Excel chậm chạp, anh Tuấn là người được hỏi ý kiến đầu tiên — đơn giản vì anh là người hiểu rõ nhất logic đằng sau các con số: doanh thu thuần được tính sau khi trừ chiết khấu và hàng trả lại; chi phí thuê mặt bằng phân bổ theo diện tích; một số cửa hàng nhượng quyền có cách ghi nhận khác. Toàn bộ những logic này, nếu không có anh, đội phát triển dashboard sẽ phải đoán mò và làm sai.
Anh Tuấn nhận ra: việc anh diễn giải "công thức Excel này tương đương quy tắc tính toán gì trong hệ thống" chính là công việc của một BA. Anh đang chuyển requirement từ một công cụ (Excel) sang một hệ thống. Chúng ta sẽ học sâu kỹ năng này ở các bài về automation và reporting requirement, nhưng điểm mấu chốt ở đây là: domain knowledge tài chính của anh là thứ không thể thuê ngoài.
Bài học rút ra: Ở các dự án liên quan đến số liệu tài chính, BA có nền Finance không chỉ "tham gia được" mà còn ở vị trí trung tâm. Bạn là cầu nối tự nhiên giữa logic nghiệp vụ và đội kỹ thuật.
Tình huống 3: So sánh với một BA không có nền tảng nghiệp vụ
Hãy lấy một ví dụ phản chứng để thấy rõ giá trị. Tại một startup fintech cho vay tiêu dùng ở Đông Nam Á, một BA mới ra trường được giao viết yêu cầu cho module tính lãi. Bạn ấy viết: "Hệ thống tính lãi hàng tháng dựa trên số dư nợ." Nghe thì ổn, nhưng dev triển khai xong, kế toán phát hiện sai: lãi phải tính trên dư nợ gốc còn lại theo phương pháp giảm dần (reducing balance), tính theo số ngày thực tế, và có quy tắc làm tròn riêng theo quy định. Dự án phải làm lại phần đó, trễ hai tuần.
Một BA có nền Finance sẽ không bao giờ viết một câu mơ hồ như vậy, vì trong đầu họ đã có sẵn câu hỏi: "Lãi trên dư nợ giảm dần hay cố định? Tính theo 360 hay 365 ngày? Làm tròn đến đồng hay nghìn đồng? Lãi quá hạn tính khác lãi trong hạn thế nào?"
Bài học rút ra: Giá trị lớn nhất bạn mang vào nghề BA không phải là biết vẽ sơ đồ — đó là kỹ năng học được trong vài tuần. Giá trị là bản năng đặt câu hỏi đúng về nghiệp vụ tài chính, thứ mất nhiều năm mới có. Hãy trân trọng và làm nổi bật nó.
Hướng dẫn từng bước
Đây là cách bạn bắt đầu "nhìn công việc Finance của mình bằng con mắt BA" ngay từ tuần này:
- Chọn một quy trình bạn làm hàng ngày. Ví dụ: quy trình duyệt và thanh toán hóa đơn nhà cung cấp, hoặc quy trình khóa sổ cuối tháng.
- Vẽ nó thành các bước tuần tự. Dùng giấy hoặc một sơ đồ đơn giản: bước này → bước kia. Ghi rõ đầu vào (input) và đầu ra (output) của mỗi bước. Ai làm bước nào? (Đây là phôi thai của process flow mà bạn sẽ học chuẩn hóa ở bài BPMN.)
- Liệt kê các điều kiện rẽ nhánh và quy tắc. "Nếu hóa đơn trên X thì cần thêm cấp duyệt." "Nếu thiếu chứng từ thì trả lại." Mỗi câu "nếu... thì..." là một business rule.
- Xác định các trạng thái. Một hóa đơn đi qua những trạng thái nào: chờ duyệt → đã duyệt → đã thanh toán / bị từ chối? Vẽ ra. Bạn vừa tạo một state diagram sơ khai.
- Tìm điểm đau (pain point). Bước nào mất thời gian nhất? Bước nào hay sai? Bước nào phải làm thủ công có thể tự động hóa? Đây là tư duy "tìm cơ hội cải tiến" — trái tim của công việc BA.
- Tự đặt câu hỏi "nếu xây phần mềm cho quy trình này thì cần gì?" Hệ thống cần lưu thông tin gì, kiểm tra điều kiện gì, cảnh báo khi nào? Tập thói quen dịch quy trình thủ công sang yêu cầu hệ thống.
Lỗi thường gặp & mẹo
Lỗi 1: Nghĩ rằng phải vứt bỏ kiến thức Finance để "làm lại từ đầu" với BA. Đây là sai lầm tâm lý phổ biến và tai hại nhất. Kiến thức Finance là lợi thế cạnh tranh, không phải gánh nặng. Mẹo: trong CV và phỏng vấn sau này, hãy định vị mình là "BA có thế mạnh domain tài chính" chứ không phải "kế toán đang tập làm BA".
Lỗi 2: Nhầm BA với việc chỉ viết tài liệu. BA không phải thư ký ghi chép. Cốt lõi là phân tích — hiểu vấn đề, đặt câu hỏi đào sâu, đề xuất giải pháp. Mẹo: với mỗi yêu cầu nghe được, luôn hỏi thêm "Tại sao?" ít nhất một lần để chạm tới nhu cầu thật.
Lỗi 3: Quá tập trung vào con số, quên mất con người và quy trình. Finance huấn luyện bạn yêu sự chính xác, nhưng BA còn cần hiểu vì sao các bên liên quan muốn điều họ muốn — và đôi khi nhu cầu thực khác với điều họ nói ra. Mẹo: dành thời gian quan sát người dùng làm việc thực tế, đừng chỉ tin vào quy trình trên giấy.
Lỗi 4: Dùng quá nhiều thuật ngữ kế toán khi nói với dev. Dev không biết "bút toán kết chuyển" là gì. Mẹo: tập diễn đạt nghiệp vụ tài chính bằng ngôn ngữ logic trung tính (điều kiện, đầu vào, đầu ra, trạng thái) — đây là kỹ năng "phiên dịch" mà BA giỏi nào cũng phải có.
Mẹo vàng: Hãy bắt đầu xây một "từ điển đối chiếu" cá nhân: cột trái là khái niệm Finance bạn đã biết, cột phải là khái niệm BA tương ứng (ví dụ: chu trình kế toán → business process; quy định/chính sách → business rule; đối chiếu → data reconciliation/validation; chứng từ → data record). Cuốn từ điển này sẽ là la bàn cho cả hành trình chuyển đổi của bạn.
Bài tập thực hành
Bài tập 1 — Bóc tách một quy trình (30 phút). Chọn một quy trình tài chính bạn làm thường xuyên nhất. Viết ra: (a) danh sách các bước theo thứ tự, (b) đầu vào và đầu ra mỗi bước, (c) ít nhất 5 business rules, (d) các trạng thái mà đối tượng chính (hóa đơn/đơn hàng/khoản phải thu...) đi qua. Trình bày trên một trang giấy.
Bài tập 2 — Từ điển đối chiếu (20 phút). Lập bảng 2 cột với tối thiểu 8 cặp khái niệm Finance ↔ BA dựa trên công việc thực tế của bạn. Giữ lại và bổ sung dần qua từng bài học.
Bài tập 3 — Săn điểm đau (15 phút). Trong quy trình đã chọn ở Bài tập 1, xác định 3 pain point và với mỗi cái, viết một câu mô tả "nếu có hệ thống, nó nên làm gì để giải quyết". Đây là bản nháp đầu tiên của một yêu cầu (requirement).
Bài tập 4 — Tự định vị (10 phút). Viết 2–3 câu giới thiệu bản thân theo hướng "BA có thế mạnh domain tài chính", nêu bật một quy trình tài chính cụ thể bạn hiểu sâu mà một BA thông thường không có. Đây là hạt giống cho CV và phần phỏng vấn sau này.
Tóm tắt
Bài học này có một thông điệp trung tâm: BA là người khám phá nhu cầu và mô tả giải pháp xoay quanh các business process — và Finance/Kế toán đã cho bạn nền tảng vững chắc về chính những quy trình, quy tắc và sự chính xác đó. Bạn không bắt đầu từ con số 0; bạn bắt đầu với một kho domain knowledge và tư duy process mà nhiều người trong nghề phải mất nhiều năm mới có.
Bốn hoạt động lõi của BA — hiểu vấn đề, khai thác và phân tích yêu cầu, mô tả rõ ràng, và đảm bảo giải pháp đúng — phản chiếu trực tiếp những gì bạn làm khi xử lý một chu trình kế toán: hiểu nghiệp vụ, thu thập chứng từ, ghi nhận chính xác, và đối chiếu kiểm soát. Khác biệt lớn nhất cần ghi nhớ là hướng nhìn: từ "ghi nhận điều đã xảy ra" sang "thiết kế cách điều đó nên xảy ra".
Việc cần làm ngay: tập nhìn các quy trình Finance hàng ngày qua lăng kính BA — bóc tách thành bước, quy tắc, trạng thái và điểm đau; đồng thời bắt đầu xây từ điển đối chiếu Finance ↔ BA của riêng bạn. Ở những bài tiếp theo, chúng ta sẽ đi sâu vào từng kỹ năng chuyển đổi cụ thể — từ phân tích tài chính sang business requirements, từ mindset kế toán sang mindset BA — nhưng nền tảng tư duy bạn vừa thiết lập ở bài này sẽ theo bạn suốt cả khóa.