Mở đầu — vì sao bài này quan trọng
Suốt chín bài trước, chúng ta đã nói rất nhiều về lý thuyết: kỹ năng nào chuyển đổi được, BA là gì, làm sao đi từ phân tích tài chính sang business requirements. Nhưng lý thuyết, dù hay đến đâu, vẫn để lại trong đầu bạn một câu hỏi day dứt: "Liệu một người làm kế toán/finance thuần như tôi có thực sự làm được BA không? Và nếu làm được thì con đường đó trông như thế nào trong đời thực?"
Bài này sinh ra để trả lời câu hỏi đó một cách thẳng thắn. Thay vì giảng lý thuyết, tôi sẽ dẫn bạn đi qua những case study chuyển đổi nghề thật trong môi trường fintech Việt Nam — nơi mà nhu cầu tuyển BA hiểu nghiệp vụ tài chính đang bùng nổ. Bạn sẽ thấy chính xác người ta đã tận dụng nền tảng finance như thế nào, vấp ngã ở đâu, mất bao lâu, và đâu là những quyết định bước ngoặt giúp họ "qua cầu".
Tại sao fintech lại là sân chơi vàng cho ex-finance? Vì sản phẩm fintech về bản chất là nghiệp vụ tài chính được số hóa: ví điện tử, cho vay tiêu dùng, thanh toán, quản lý dòng tiền, đối soát giao dịch. Một dev giỏi có thể code, nhưng họ không hiểu vì sao một giao dịch hoàn tiền phải tách thành hai bút toán, hay vì sao báo cáo đối soát cuối ngày không khớp. Bạn — người từng làm finance — hiểu điều đó trong máu. Đó chính là lợi thế cạnh tranh mà bài học này sẽ giúp bạn nhìn ra và khai thác.
Khái niệm cốt lõi
Trước khi vào các câu chuyện, ta cần thống nhất một khung tư duy để "đọc" được mỗi case study. Đừng đọc như đọc truyện — hãy đọc như một nhà phân tích.
Mô hình ba lớp lợi thế của ex-finance
Khi một người từ finance chuyển sang BA tại fintech, lợi thế của họ rơi vào ba lớp:
- Lớp domain (nghiệp vụ): Hiểu bản chất giao dịch, sổ sách, đối soát, hạch toán, thuế, tuân thủ. Đây là thứ khó dạy nhất cho người ngoài ngành, và là vũ khí mạnh nhất của bạn.
- Lớp tư duy (mindset): Thói quen kiểm tra số liệu, đòi hỏi mọi con số phải khớp (reconciliation), tư duy "nếu sai một đồng thì cả hệ thống sai". Tư duy này biến thành kỹ năng viết requirement chặt chẽ, không để lọt edge case.
- Lớp công cụ (tooling): Excel nâng cao, pivot, hàm logic, đôi khi là SQL hay VBA. Đây là phần dễ bị xem nhẹ nhưng lại giúp bạn nhanh chóng làm việc với dữ liệu thật.
"Khoảng trống" cần lấp
Đối lập với lợi thế là khoảng trống. Hầu hết ex-finance khi chuyển BA đều thiếu ba thứ: (1) ngôn ngữ sản phẩm — user story, acceptance criteria, MVP; (2) khả năng giao tiếp với dev và tư duy hệ thống — hiểu API, database, luồng trạng thái; (3) tư duy lấy người dùng làm trung tâm thay vì lấy con số làm trung tâm. Chuyển đổi thành công không phải là vứt bỏ nền finance, mà là giữ nguyên lợi thế và lấp khoảng trống một cách có chủ đích.
Tình huống thực tế
Case 1 — Chị Mai, kế toán tổng hợp chuyển BA mảng đối soát tại một ví điện tử
Chị Mai, 29 tuổi, làm kế toán tổng hợp 5 năm tại một công ty thương mại, mức lương khoảng 16 triệu/tháng. Công việc hằng ngày của chị là khóa sổ, lập báo cáo, và đặc biệt là đối chiếu công nợ — phần việc khiến chị thành thạo trong việc tìm ra "tại sao hai con số không khớp".
Một công ty ví điện tử (giả định tên VíViet, mô hình tương tự MoMo/ZaloPay) đăng tuyển BA cho team đối soát giao dịch (reconciliation). Đây là bài toán đau đầu của mọi fintech: mỗi ngày hàng triệu giao dịch chạy qua ngân hàng, cổng thanh toán, và hệ thống nội bộ; cuối ngày ba nguồn dữ liệu này phải khớp nhau từng đồng. Khi lệch, ai đó phải tìm ra nguyên nhân.
Chị Mai ứng tuyển dù chưa biết viết một user story nào. Điều giúp chị qua vòng phỏng vấn không phải kiến thức BA, mà là khi được hỏi "Nếu báo cáo đối soát lệch 3 triệu, chị xử lý thế nào?", chị đã mô tả ngay quy trình truy vết: đối chiếu theo từng lô, khoanh vùng khoảng thời gian, tách giao dịch hoàn tiền và phí. Người phỏng vấn — một Product Owner — nhận ra chị hiểu bài toán sâu hơn cả vài BA đang có trong team.
Diễn giải: Trong 3 tháng đầu, chị Mai phải học gấp Jira, cách viết acceptance criteria, và đọc luồng dữ liệu giữa các hệ thống. Chị mất ngủ vì những thuật ngữ như "callback", "webhook", "settlement". Nhưng vì chị nắm chắc nghiệp vụ đối soát, chị chỉ cần học cách diễn đạt nó cho dev hiểu. Sau 6 tháng, chị trở thành người viết requirement đối soát tốt nhất team vì chị biết đúng những edge case mà người không làm kế toán sẽ bỏ sót: giao dịch treo qua đêm, phí âm, hoàn tiền một phần.
Bài học rút ra: Hãy ứng tuyển vào đúng mảng mà nền finance của bạn là lợi thế áp đảo (đối soát, kế toán, thanh toán), đừng nhảy vào mảng generic nơi bạn cạnh tranh bằng những thứ mình yếu. Lương khởi điểm BA của chị Mai là 22 triệu — tăng gần 40% so với nghề cũ.
Case 2 — Anh Tuấn, chuyên viên phân tích tài chính chuyển BA mảng tín dụng (lending)
Anh Tuấn từng là Financial Analyst tại một công ty bất động sản, chuyên dựng mô hình tài chính trên Excel — dòng tiền chiết khấu, phân tích độ nhạy, kịch bản lãi suất. Anh chuyển sang một fintech cho vay tiêu dùng (mô hình tương tự FE Credit số hóa hay các app vay nhanh).
Lợi thế của anh nằm ở lớp tư duy và lớp công cụ: anh hiểu cách tính lãi, lịch trả nợ (amortization), nợ xấu, và đặc biệt là tư duy mô hình hóa. Khi team xây dựng tính năng "tính toán khoản vay" cho app, anh không cần ai giải thích vì sao khoản trả góp tháng đầu khác tháng cuối, hay vì sao phải xử lý ngày lễ khi tính kỳ hạn.
Diễn giải: Tuy nhiên anh Tuấn vấp một sai lầm điển hình. Trong sáu tháng đầu, anh viết requirement quá chi tiết về công thức tài chính nhưng quên mất trải nghiệm người vay. Anh mô tả chính xác cách hệ thống tính lãi suất, nhưng không nghĩ đến việc người dùng cần thấy gì trên màn hình, cần được cảnh báo ra sao khi sắp trễ hạn. Một dev đã phản hồi thẳng: "Anh cho em logic, nhưng người dùng cuối không phải kế toán." Đó là cú tát thức tỉnh. Anh bắt đầu đi gặp khách hàng vay, ngồi nghe họ kể vì sao họ sợ bị tính phí ẩn. Từ đó requirement của anh có cả "logic chuẩn" lẫn "sự thấu cảm với người dùng".
Bài học rút ra: Nền finance giúp bạn viết logic không sai một ly, nhưng BA giỏi cần thêm tư duy lấy người dùng làm trung tâm. Đừng để thế mạnh tài chính biến bạn thành "cỗ máy tính công thức". Sau một năm, anh Tuấn lên BA mảng lending core với mức lương 35 triệu.
Case 3 — Chị Hương, kế toán thuế chuyển BA mảng tuân thủ (compliance) tại fintech B2B
Chị Hương làm kế toán thuế 7 năm, quen thuộc với hóa đơn điện tử, kê khai thuế GTGT, và các quy định của Tổng cục Thuế. Chị chuyển sang một fintech cung cấp giải pháp hóa đơn và kế toán cho doanh nghiệp (mô hình tương tự MISA, Kế toán điện tử).
Đây là case mà domain knowledge gần như là toàn bộ lợi thế. Khi nhà nước thay đổi quy định về hóa đơn điện tử (như đợt áp dụng Nghị định 123, Thông tư 78), cả team sản phẩm hoảng loạn vì không ai hiểu luật. Chị Hương trở thành người duy nhất dịch được ngôn ngữ pháp lý sang requirement kỹ thuật: trường dữ liệu nào bắt buộc, định dạng XML ra sao, khi nào hóa đơn được phép hủy/điều chỉnh.
Diễn giải: Khoảng trống của chị Hương là kỹ thuật. Chị không biết XML, không biết API hoạt động thế nào. Nhưng chị không cần trở thành kỹ sư — chị chỉ cần học đủ để giao tiếp. Chị dành 30 phút mỗi sáng học khái niệm kỹ thuật cơ bản, và quan trọng hơn, chị thành thật với dev: "Em giải thích kỹ thuật cho chị, chị giải thích nghiệp vụ thuế cho em, mình bù trừ cho nhau." Sự khiêm tốn đó giúp chị xây được mối quan hệ tốt với team kỹ thuật.
Bài học rút ra: Ở mảng compliance/audit, domain knowledge của ex-finance là vô giá và gần như không thể thay thế. Bạn không cần giỏi kỹ thuật bằng dev — bạn chỉ cần giỏi nghiệp vụ hơn tất cả mọi người, và đủ khiêm tốn để học phần còn lại.
Hướng dẫn từng bước
Từ ba case study trên, đây là lộ trình hành động bạn có thể áp dụng ngay để tự dựng case chuyển đổi của chính mình:
- Xác định "mảng lợi thế" của bạn trong fintech. Lập một bảng: cột trái là kinh nghiệm finance cụ thể của bạn (đối soát, thuế, mô hình tài chính, công nợ, kiểm toán), cột phải là mảng fintech tương ứng cần BA (reconciliation, e-invoice/compliance, lending, payment). Nhắm vào giao điểm mạnh nhất.
- Viết lại CV theo ngôn ngữ "bài toán". Đừng viết "lập báo cáo công nợ". Hãy viết "truy vết và giải quyết chênh lệch dữ liệu giữa nhiều nguồn" — đó chính là ngôn ngữ của reconciliation BA. Dịch mỗi nhiệm vụ finance thành một năng lực BA tương đương.
- Chuẩn bị một "câu chuyện edge case". Như chị Mai với câu hỏi lệch 3 triệu, hãy có sẵn 2-3 tình huống thực tế bạn từng xử lý, kể được mạch lạc theo cấu trúc: bối cảnh → vấn đề → cách bạn truy vết → kết quả. Đây là vũ khí phỏng vấn mạnh nhất của ex-finance.
- Lấp khoảng trống tối thiểu trước khi ứng tuyển. Bạn không cần thành thạo mọi thứ. Hãy học đủ để: viết được một user story + acceptance criteria, hiểu sơ luồng dữ liệu cơ bản (hệ thống gọi nhau qua API), và dùng được Jira. Khoảng 2-4 tuần tự học là đủ để qua vòng đầu.
- Trong 90 ngày đầu, chủ động "trao đổi domain lấy kỹ thuật". Như chị Hương, hãy đề nghị dạy team về nghiệp vụ tài chính, đổi lại nhờ họ giải thích kỹ thuật. Đây là cách xây dựng quan hệ và lấp khoảng trống nhanh nhất.
- Cảnh giác với bẫy "cỗ máy công thức". Như anh Tuấn, ngay từ đầu hãy buộc mình đi gặp người dùng cuối, đừng chỉ ngồi viết logic. Mỗi requirement, tự hỏi: "Người dùng thật sự cần gì, sợ gì?"
Lỗi thường gặp & mẹo
Lỗi 1: Tự ti vì không biết kỹ thuật. Rất nhiều ex-finance nghĩ phải biết code mới làm BA được. Sai. Domain knowledge của bạn quý hơn kỹ năng kỹ thuật mà bất kỳ ai cũng học được. Mẹo: định vị bản thân là "BA hiểu nghiệp vụ tài chính", không phải "BA biết kỹ thuật nửa vời".
Lỗi 2: Viết requirement như viết quy trình kế toán. Khô khan, đầy thuật ngữ chuyên ngành, dev đọc không hiểu. Mẹo: luôn dịch nghiệp vụ sang ngôn ngữ "người dùng làm gì, hệ thống phản hồi gì".
Lỗi 3: Nhảy vào mảng fintech generic. Nếu bạn ứng tuyển BA mảng marketing hay growth, bạn vứt bỏ toàn bộ lợi thế và phải cạnh tranh từ con số 0. Mẹo: chỉ nhắm mảng tài chính lõi — đó là sân nhà của bạn.
Lỗi 4: Quên rằng số liệu không phải tất cả. Finance dạy bạn coi trọng độ chính xác, nhưng BA cũng cần coi trọng trải nghiệm và tốc độ ra MVP. Mẹo: học cách chấp nhận "đủ tốt để ship" thay vì "hoàn hảo tuyệt đối".
Mẹo vàng: Trong fintech VN hiện nay, một BA vừa hiểu nghiệp vụ kế toán/thuế/tín dụng vừa biết viết requirement là "của hiếm". Mức lương cho nhóm này thường cao hơn BA thông thường 15-25% vì rất khó tuyển. Hãy biến nền finance thành tấm vé đặc biệt của bạn, đừng giấu nó đi.
Bài tập thực hành
- Dựng "bản đồ lợi thế" cá nhân. Liệt kê 5 nhiệm vụ finance bạn làm thành thạo nhất, rồi ghép mỗi nhiệm vụ với một mảng fintech cần BA (reconciliation, lending, payment, e-invoice/compliance, treasury). Khoanh tròn giao điểm mà bạn mạnh nhất — đó là mục tiêu nghề nghiệp ưu tiên của bạn.
- Soạn câu chuyện edge case. Viết ra một tình huống thực tế bạn từng xử lý chênh lệch số liệu hoặc một quy định phức tạp, theo cấu trúc: bối cảnh → vấn đề → cách truy vết → kết quả. Luyện kể trong 90 giây. Đây sẽ là câu trả lời phỏng vấn ấn tượng nhất của bạn.
- Phân tích case theo mô hình ba lớp. Đọc lại Case 1, 2, 3. Với mỗi nhân vật, xác định họ thắng nhờ lớp nào (domain/mindset/tooling) và thiếu lớp nào. Sau đó tự đánh giá: bản thân bạn đang mạnh và yếu ở lớp nào?
- Viết thử một câu CV "dịch ngược". Lấy một dòng mô tả công việc finance hiện tại của bạn, viết lại theo ngôn ngữ BA. Ví dụ: "Đối chiếu công nợ hàng tháng" → "Phân tích và xử lý chênh lệch dữ liệu giữa nhiều hệ thống nguồn, đề xuất quy trình đối soát."
Tóm tắt
Chuyển từ finance/kế toán sang BA trong fintech Việt Nam không phải là một canh bạc liều lĩnh — nó là một nước đi chiến lược, miễn là bạn đi đúng cách. Ba case study trong bài cho thấy cùng một công thức thành công: nhắm vào mảng mà nền finance là lợi thế áp đảo (đối soát, tín dụng, tuân thủ), giữ chặt domain knowledge của mình, và khiêm tốn lấp khoảng trống về ngôn ngữ sản phẩm cùng kỹ năng kỹ thuật cơ bản.
Chị Mai thắng nhờ domain đối soát. Anh Tuấn suýt vấp vì biến mình thành cỗ máy công thức, rồi thoát ra nhờ học cách lắng nghe người dùng. Chị Hương biến kiến thức thuế thành thứ không ai thay thế được. Điểm chung: không ai trong số họ vứt bỏ quá khứ finance — họ biến nó thành vũ khí.
Trong thị trường fintech VN đang khát BA hiểu nghiệp vụ tài chính, bạn không phải là "người tay ngang yếu thế". Bạn là người mang theo một thứ mà cả team sản phẩm đang thiếu. Hãy đi vào phỏng vấn với tâm thế đó. Ở bài tiếp theo, chúng ta sẽ đào sâu vào sự khác biệt nền tảng giữa tư duy finance và tư duy BA — chìa khóa để bạn không lặp lại sai lầm của anh Tuấn.