Mở đầu — vì sao bài này quan trọng
Nếu bạn đến từ Finance hoặc Kế toán, hãy thử đếm trong đầu xem mình đã từng làm bao nhiêu báo cáo. Báo cáo doanh thu theo tháng, P&L theo từng business unit, bảng cân đối, báo cáo công nợ phải thu chia theo aging bucket, dashboard cash flow cho ban giám đốc... Con số đó chắc chắn lên đến hàng trăm, thậm chí hàng nghìn lần xuất file Excel. Đây chính là một trong những "siêu năng lực ẩn" lớn nhất mà bạn mang theo khi chuyển sang nghề BA — nhưng hầu hết người mới chuyển ngành lại không nhận ra nó.
Khi làm BA, bạn sẽ không còn tự tay ngồi dựng báo cáo trong Excel nữa. Thay vào đó, bạn viết reporting requirement (yêu cầu báo cáo) để đội dev hoặc đội BI (Business Intelligence) xây dựng dashboard, báo cáo tự động trên hệ thống. Vai trò của bạn đổi từ "người làm báo cáo" sang "người định nghĩa báo cáo phải trông như thế nào, lấy số từ đâu, tính toán ra sao". Và bên cạnh đó, bạn còn phải biết vẽ wireframe — bản phác thảo bố cục màn hình — để dev và stakeholder hình dung được dashboard sẽ hiển thị ra sao trước khi viết một dòng code.
Bài này tập trung đúng hai kỹ năng đó: vẽ wireframe cho màn hình báo cáo/dashboard, và viết reporting requirement đầy đủ để dev không phải hỏi đi hỏi lại. Đây là phần "đất diễn" tự nhiên nhất của dân Finance trong nghề BA — hãy tận dụng triệt để.
Khái niệm cốt lõi
Wireframe là gì và tại sao BA cần vẽ
Wireframe là bản phác thảo bố cục giao diện ở mức thô — chỉ có khung, vị trí các thành phần, không màu mè, không font chữ đẹp. Hãy hình dung nó giống như bản vẽ kiến trúc của ngôi nhà: bạn cần biết phòng khách ở đâu, cửa sổ hướng nào, trước khi quyết định sơn màu gì. Với màn hình báo cáo, wireframe trả lời các câu hỏi: bộ lọc (filter) nằm ở đâu, các con số tổng (KPI card) hiển thị trên cùng hay bên cạnh, biểu đồ loại nào đặt ở vị trí nào, bảng chi tiết nằm dưới cùng ra sao.
BA vẽ wireframe không phải để đẹp, mà để giao tiếp. Một bức wireframe giúp ba nhóm người cùng "nhìn thấy" sản phẩm: stakeholder xác nhận đúng nhu cầu, dev hiểu phải build gì, designer biết phải đẹp hóa cái gì. Quan trọng: wireframe của BA cố tình xấu — nếu bạn vẽ quá đẹp, stakeholder sẽ tranh luận về màu sắc thay vì về logic dữ liệu.
Reporting requirement gồm những gì
Một reporting requirement hoàn chỉnh phải trả lời được sáu câu hỏi mà chính bạn — với kinh nghiệm Finance — đã luôn ngầm hiểu khi làm báo cáo:
- Mục đích & người dùng: Ai xem báo cáo này, để ra quyết định gì? Báo cáo cho CFO khác hoàn toàn báo cáo cho nhân viên thu hồi công nợ.
- Metrics & công thức: Mỗi con số tính như thế nào? Đây là phần dân Finance làm tốt nhất. "Doanh thu thuần" là gì — đã trừ chiết khấu chưa, đã trừ hàng trả lại chưa, ghi nhận theo thời điểm nào?
- Dimensions (chiều phân tích): Số liệu được cắt theo những chiều nào — theo thời gian, theo chi nhánh, theo sản phẩm, theo khách hàng?
- Filters & parameters: Người dùng được lọc theo gì? Khoảng thời gian, loại giao dịch, trạng thái...
- Data source & refresh: Số lấy từ bảng nào, hệ thống nào? Cập nhật real-time hay mỗi đêm (batch)?
- Format & visualization: Hiển thị dạng bảng, biểu đồ cột, đường, hay KPI card? Định dạng số (phân tách hàng nghìn, đơn vị triệu/tỷ, số thập phân).
Sự khác biệt chí mạng: định nghĩa metric
Đây là nơi giá trị của dân ex-Finance bùng nổ. Một dev giỏi vẫn có thể build sai báo cáo nếu metric không được định nghĩa rõ. Ví dụ kinh điển: "tỷ lệ nợ xấu". Tử số là gì — dư nợ quá hạn trên 90 ngày? Mẫu số là tổng dư nợ tại thời điểm nào — đầu kỳ, cuối kỳ, hay bình quân? Một BA xuất thân kế toán sẽ tự động đặt ra những câu hỏi này, trong khi BA non-Finance có thể bỏ sót và để dev "đoán".
Một số nguyên tắc trình bày số liệu
Vì là người làm báo cáo lâu năm, bạn cần truyền lại "gu" trình bày cho dev: số tiền nên có dấu phân cách hàng nghìn, số âm (lỗ) hiển thị màu đỏ hoặc trong ngoặc đơn theo chuẩn kế toán, phần trăm làm tròn mấy chữ số, đơn vị tiền tệ ghi rõ (VND hay nghìn VND). Những chi tiết này dev không tự biết — bạn phải viết ra trong requirement.
Tình huống thực tế
Tình huống 1 — Dashboard công nợ tại một công ty phân phối FMCG
Chị Hương, từng là kế toán công nợ tại một nhà phân phối hàng tiêu dùng ở TP.HCM với khoảng 1.200 đại lý, chuyển sang làm BA. Dự án đầu tiên của chị là xây dashboard "Aging công nợ phải thu" thay cho file Excel mà phòng kế toán vẫn gửi tay mỗi sáng thứ Hai.
Thay vì nói với dev một câu mơ hồ "làm cho tôi báo cáo công nợ", chị viết requirement rõ ràng: metric chính là dư nợ phải thu, cắt theo các aging bucket 0–30, 31–60, 61–90 và trên 90 ngày; chiều phân tích theo đại lý, theo nhân viên kinh doanh phụ trách, theo khu vực; filter theo ngày chốt và theo trạng thái đại lý. Chị định nghĩa rõ "ngày quá hạn" tính từ ngày đến hạn ghi trên hóa đơn chứ không phải ngày xuất hóa đơn — một chi tiết mà dev đã định làm sai.
Wireframe của chị đặt bốn KPI card tổng dư nợ theo từng bucket trên cùng, một biểu đồ cột chồng (stacked bar) theo khu vực ở giữa, và bảng chi tiết từng đại lý có thể click để xem hóa đơn ở dưới.
Bài học: Định nghĩa metric chính xác (ngày quá hạn tính từ đâu) đã ngăn một lỗi nghiệp vụ ngay từ vòng requirement. Đó là giá trị mà chỉ người có nền Finance mới nhìn ra ngay.
Tình huống 2 — Báo cáo doanh thu cho ban lãnh đạo một chuỗi F&B
Anh Tuấn, cựu chuyên viên phân tích tài chính tại một chuỗi cà phê khoảng 80 cửa hàng, được giao làm BA cho dự án dashboard doanh thu real-time. Stakeholder là CEO, người chỉ muốn "mở điện thoại ra là thấy hôm nay bán được bao nhiêu".
Anh không nhảy vào liệt kê chỉ số. Anh phỏng vấn CEO và phát hiện điều cốt lõi: CEO không cần xem 80 cửa hàng cùng lúc, mà cần thấy ngay top 5 cửa hàng tệ nhất so với cùng kỳ tuần trước để gọi điện chấn chỉnh. Từ insight đó, anh viết requirement với metric "doanh thu lũy kế trong ngày", so sánh với cùng giờ cùng thứ tuần trước (week-over-week theo thời điểm), và một bảng xếp hạng cửa hàng có cảnh báo đỏ khi giảm quá 15%.
Về data source, anh ghi rõ số liệu lấy từ hệ thống POS, refresh mỗi 15 phút, và cảnh báo dev rằng doanh thu phải loại trừ các đơn đã hủy và đơn test của nhân viên — một vấn đề dữ liệu mà anh biết từ kinh nghiệm đối soát doanh thu trước đây.
Bài học: Reporting requirement tốt bắt đầu từ quyết định mà người dùng cần ra, không phải từ danh sách số liệu. Và kiến thức "số nào là số sạch" của dân Finance giúp tránh báo cáo sai từ gốc dữ liệu.
Tình huống 3 — Wireframe cứu một buổi họp tại fintech
Một bạn BA từng làm kiểm toán nội bộ, nay làm tại một công ty fintech cho vay tiêu dùng ở Hà Nội, kể lại buổi họp với phòng vận hành về dashboard theo dõi tỷ lệ giải ngân. Lần đầu bạn ấy chỉ mô tả bằng lời, kết quả là mỗi người trong phòng tưởng tượng một kiểu, họp 90 phút không chốt được gì.
Buổi sau, bạn ấy mang theo một wireframe vẽ tay chụp lại: phía trên là bộ lọc theo sản phẩm vay và theo kênh, ba KPI card (số hồ sơ nộp, tỷ lệ duyệt, tỷ lệ giải ngân thành công), một biểu đồ phễu (funnel) thể hiện hồ sơ rơi rụng qua từng bước, và bảng chi tiết theo ngày. Chỉ trong 20 phút, phòng vận hành chỉ tay vào wireframe và nói "cái phễu này phải tách theo lý do từ chối nữa". Yêu cầu được làm rõ ngay tại chỗ.
Bài học: Một wireframe xấu nhưng cụ thể đánh bại mười câu mô tả hay. Hình ảnh biến cuộc tranh luận trừu tượng thành cuộc trao đổi cụ thể.
Hướng dẫn từng bước
Bước 1 — Xác định người dùng và quyết định họ cần ra. Trước khi nghĩ đến con số, hỏi: ai xem báo cáo này, họ làm gì sau khi xem? Một báo cáo phục vụ hành động, không phải để trưng bày. Viết một câu duy nhất: "Báo cáo này giúp [ai] quyết định [điều gì]".
Bước 2 — Liệt kê metrics và định nghĩa từng cái bằng công thức. Với mỗi chỉ số, viết rõ tử số, mẫu số, điều kiện lọc, thời điểm ghi nhận. Đây là lúc tận dụng tối đa nền Finance. Đừng để bất kỳ metric nào ở dạng "ai cũng hiểu" — vì dev không hiểu như bạn.
Bước 3 — Xác định dimensions và filters. Báo cáo này cắt theo chiều nào, người dùng được lọc theo gì? Ghi rõ giá trị mặc định của mỗi filter (ví dụ: mặc định hiển thị tháng hiện tại).
Bước 4 — Làm rõ data source và tần suất cập nhật. Số lấy từ hệ thống/bảng nào, real-time hay batch, mấy giờ chạy. Đồng thời ghi chú các quy tắc làm sạch dữ liệu (loại đơn hủy, loại giao dịch test...).
Bước 5 — Vẽ wireframe. Bố cục theo nguyên tắc đọc từ trên xuống, trái sang phải: filter trên cùng, KPI tổng quan kế tiếp, biểu đồ ở giữa, bảng chi tiết dưới cùng. Đánh số (annotation) từng vùng và ghi chú metric/filter tương ứng. Bạn có thể vẽ tay, dùng Balsamiq, Figma, hay thậm chí draw.io — công cụ không quan trọng bằng việc nó cụ thể.
Bước 6 — Đặc tả format hiển thị. Định dạng số, đơn vị, màu cảnh báo, quy tắc làm tròn, cách hiển thị số âm. Ghi rõ định dạng xuất file nếu cần (Excel, PDF).
Bước 7 — Định nghĩa edge case. Khi không có dữ liệu thì hiển thị gì? Mẫu số bằng 0 thì tỷ lệ hiện ra sao? Quyền xem — ai được thấy báo cáo nào?
Bước 8 — Review với stakeholder và dev. Đưa wireframe và bảng metric cho cả hai phía xác nhận trước khi dev bắt tay làm.
Lỗi thường gặp & mẹo
Lỗi 1 — Mô tả metric mơ hồ. Viết "doanh thu" mà không nói doanh thu gộp hay thuần, đã ghi nhận hay đã thu tiền. Mẹo: với mỗi metric, bắt buộc có một dòng công thức. Nếu bạn không viết được công thức, nghĩa là requirement chưa xong.
Lỗi 2 — Wireframe vẽ quá đẹp. Khi bạn dùng màu mè và icon lung linh, stakeholder sẽ góp ý về thẩm mỹ thay vì về logic. Mẹo: giữ wireframe ở mức xám trắng, dùng placeholder cho biểu đồ.
Lỗi 3 — Quên tần suất refresh và độ trễ dữ liệu. Người dùng tưởng số real-time nhưng thực ra cập nhật mỗi đêm, dẫn đến mất niềm tin. Mẹo: luôn ghi rõ "dữ liệu tính đến thời điểm X" hiển thị ngay trên màn hình.
Lỗi 4 — Bỏ qua edge case mẫu số bằng 0. Tỷ lệ chuyển đổi khi chưa có đơn nào sẽ gây lỗi chia cho 0. Mẹo: luôn đặc tả "khi không có dữ liệu hiển thị dấu gạch ngang hoặc N/A".
Lỗi 5 — Đưa quá nhiều thứ vào một màn hình. Dân Finance hay tham, muốn nhồi mọi con số. Mẹo: mỗi dashboard phục vụ một câu hỏi chính. Nếu cần thêm, tách màn hình hoặc làm drill-down.
Mẹo vàng tận dụng nền Finance: Hãy viết một "data dictionary" nhỏ kèm theo requirement — bảng định nghĩa từng thuật ngữ nghiệp vụ. Đây là thứ dân Finance làm cực nhanh và là tài sản quý giá mà cả đội dev lẫn BA khác đều biết ơn bạn.
Bài tập thực hành
Chọn một báo cáo Excel bạn từng làm thời còn ở Finance (ví dụ: báo cáo doanh thu theo chi nhánh, báo cáo công nợ, hoặc báo cáo dòng tiền). Sau đó thực hiện:
- Viết một câu mô tả người dùng và quyết định họ cần ra từ báo cáo này.
- Lập bảng metric: liệt kê tối thiểu 4 chỉ số, mỗi chỉ số kèm công thức rõ ràng (tử số, mẫu số, điều kiện).
- Xác định ít nhất 3 dimensions và 3 filters kèm giá trị mặc định.
- Ghi rõ data source giả định và tần suất refresh.
- Vẽ tay một wireframe trên giấy A4: bố trí filter, tối thiểu 3 KPI card, 1 biểu đồ phù hợp (nêu lý do chọn loại biểu đồ đó), 1 bảng chi tiết. Đánh số annotation cho từng vùng.
- Liệt kê 3 edge case và cách xử lý.
Tóm tắt
Dân Finance bước vào nghề BA với một lợi thế hiếm có ở mảng reporting: bạn đã làm hàng trăm báo cáo, hiểu sâu công thức nghiệp vụ, biết số nào là số sạch, và có "gu" trình bày số liệu. Việc cần làm là dịch toàn bộ kinh nghiệm ngầm đó thành reporting requirement tường minh — gồm mục đích, người dùng, metric kèm công thức, dimensions, filters, data source, tần suất refresh, format và edge case — để dev hoặc đội BI build đúng ngay từ đầu. Bên cạnh đó, wireframe là vũ khí giao tiếp: một bản phác thảo bố cục xấu nhưng cụ thể giúp stakeholder và dev cùng nhìn thấy sản phẩm, biến tranh luận trừu tượng thành trao đổi rõ ràng. Hãy luôn nhớ: requirement tốt bắt đầu từ quyết định người dùng cần ra, mỗi metric phải có công thức, và wireframe nên đủ xấu để mọi người tập trung vào logic thay vì màu sắc. Đây chính là sân nhà của bạn — hãy biến nó thành điểm sáng nổi bật trong hồ sơ chuyển ngành.