Các kỹ năng cần có ở một Data Analyst
DA cần SQL hay Power BI trước? Mình càng làm càng tin: hiểu nghiệp vụ đang chạy số trước, tool để sau. Tool học được theo sprint. Nghiệp vụ thì không nhồi hai tuần là xong.
Bài này xếp các mảnh kỹ năng khi ai đó hỏi: vào DA thì cần gì, và chui vào ngành kiểu nào cho đỡ loạn. Cuối bài có tóm tắt làm việc và phụ lục (checklist nghiệp vụ, thang Why, câu hỏi soi metric) để bạn in hoặc mở lại khi làm task.

1. Ưu tiên số một: hiểu biết nghiệp vụ
Nghiệp vụ ở đây không gói trong một khóa học gọn. Nó là giao của hai chiều.
Chiều thứ nhất: business function.
Trong vận hành doanh nghiệp luôn có các mảng: tài chính kế toán, bán hàng, marketing, nhân sự, hành chính, mua sắm…
Chiều thứ hai: domain / industry.
Lĩnh vực kinh doanh: sản xuất, thương mại bán lẻ, bất động sản, chăm sóc sức khỏe, SaaS…
Hai chiều cắt nhau làm kiến thức cực rộng. Bán hàng B2B khác B2C. Tài chính bất động sản khác tài chính đầu tư. Retention của sản phẩm SaaS khác churn của chuỗi bán lẻ. AR (công nợ) trong logistics khác AR bán lẻ cùng tên trên báo cáo.
Không một cá nhân nào tự tin hiểu hết mọi tổ hợp. Hiểu được điều đó, bạn bớt hoảng khi thấy JD đòi hiểu business. Bạn chỉ cần (và nên) chọn 1-2 mảng để đi sâu trước: một function, một industry, hoặc giao của cả hai nếu job đang đẩy bạn vào đó.
Còn làm sao để có nghiệp vụ? Câu trả lời không sang: làm và trải nghiệm.
Mình từng tin nghiệp vụ có thể train nhanh như train tool. Workshop glossary hai tuần, rồi giao dashboard. Thường thì team vẫn hỏi sai grain, sai owner metric, sai cửa sổ thời gian. Tool còn có shortcut và cheat sheet. Nghiệp vụ thì ít shortcut thật sự: nó nằm ở close tháng với kế toán, đi ca với vận hành, đọc từng dòng hoàn với CS, ngồi họp campaign với marketing đến khi biết số nào là vanity.
Nếu bạn đang học data và chỉ tích lũy tool, hãy để ý: chỗ kẹt phỏng vấn và chỗ kẹt job thật hay nằm ở câu số này phản ánh việc gì trên đời thật.
2. Phương pháp phân tích và sự nhạy với dữ liệu
Với nhiều vị trí DA báo cáo / phân tích doanh nghiệp hiện tại, thống kê cơ bản (đủ để tránh vài kiểu kết luận sai phổ biến) đã mở cửa vào việc. Không phải mọi DA đều cần lao ngay vào thuật toán ML hay track Data Science. Những hướng đó có chỗ đứng rõ ở một số JD và team; nhưng nếu nền nghiệp vụ và thống kê còn mỏng, dễ thành biết model mà không biết câu hỏi business đang hỏi gì.
Để nhạy data có hệ thống hơn, bạn cần vài nền tảng về cách dữ liệu được tổ chức: lược đồ, dữ liệu đa chiều, slowly changing dimension… Mỗi khái niệm chỉ dính khi neo vào việc đang làm. Học SCD trên slide, quên sau một tuần. Học SCD vì bảng khách trên job thật đổi địa chỉ, đổi phân khúc, đổi trạng thái hợp đồng: lúc đó khái niệm mới có chỗ bám.
Còn thứ làm đầu óc nhạy hơn mọi slide modeling: cách tư duy.
Nếu gói gọn stack cho dễ nhớ (không phải thứ tự tuyệt đối mọi công ty):
- Nghiệp vụ (function × industry bạn chọn)
- Phương pháp + tư duy (thống kê đủ dùng, Why, hoài nghi claim)
- Tool (Excel / Sheet → SQL → BI… khi việc đã đòi)
Tool ở tầng ba không có nghĩa là kém quan trọng. Nó có nghĩa: tool không cứu được khi bạn không biết đang đo cái gì.
Năm 2026, AI giúp viết SQL và dựng chart nhanh hơn trước. Chỗ đắt hơn vẫn là domain, chuỗi Why, và dám nghi ngờ metric nghe chắc.
3. Tư duy: Why và hoài nghi khẳng định
Không chỉ dân DA. Làm ngành nào cũng cần vài quan điểm làm việc đủ sắc. Hai tư duy dưới đây mình thấy lặp lại ở những người làm data chịu được với business, không chỉ chịu được với tool.
3.1. Tư duy giải quyết vấn đề: hỏi Why nhiều lần
Muốn gỡ một việc, đừng chỉ lao vào cách làm ngay theo mặt chữ request. Hãy hỏi Why, rồi Why phía sau Why.
Bạn hỗ trợ vận hành. Sếp yêu cầu triển khai quy trình ghi nhận số người vào quán và đặt đồ, để có traffic.
Level 0: làm ngay theo yêu cầu mặt chữ
Mua máy đếm cầm tay. Thuê người ngồi cửa bấm rồi nhập số. Hoặc đề xuất camera / AI nhận diện. Cách nào cũng có thể bị reject vì chi phí, vì vận hành không theo kịp, hoặc vì số đếm tay và cảm nhận ca không khớp nhau.
Level 1: hỏi sếp vì sao cần đếm
Sếp thường cần vài chỉ tiêu kiểu: khách bình quân trên bill, khách theo ngày / ca, cảm nhận giờ cao điểm. Khi hiểu lý do, bạn tự hỏi: có cách gần đúng từ dữ liệu đã có không? Cộng số suất đồ ăn / đồ uống (line item) trên từng bill. Không tuyệt đối: có thể hai người share một suất, hoặc một người order hai phần. Sai số thường chấp nhận được hơn là tưởng, và không đội thêm chi phí thiết bị hay headcount ngồi cửa.
Level 2: đào thêm một tầng
Vì sao sếp cần các chỉ số đó? Chúng phản ánh bàn quay, staffing ca, giờ chết, hay hiệu quả vị trí mặt bằng? Có metric khác cùng trả lời câu hỏi chiến lược hơn không: doanh thu / giờ mở cửa, dish gắn promotion, tỷ lệ bill có đồ uống?
Mỗi lần bạn hỏi Why và gỡ lý do phía sau, số hướng giải pháp mở ra nhiều hơn. Bạn không chỉ là người nhận task đo. Bạn là người giúp business chọn cách đắt ít hơn, đúng việc hơn.
3.2. Tư duy hoài nghi với dữ liệu và khẳng định nghe chắc
Khi một vấn đề được đặt ra trên một câu khẳng định, hãy xem lại cả câu khẳng định đó: bằng định nghĩa, bằng cửa sổ thời gian, bằng logic mẫu.
Hai câu hay gặp trong team data / growth:
Dashboard xanh là team đang tốt.
Xanh theo metric nào? So với target ai đặt, baseline nào, có seasonality không? Có team nào chỉ tối ưu đúng vài ô đang được pin trên trang chủ không?
Doanh thu tăng tháng này = campaign marketing thắng.
Doanh thu tổng hay doanh thu cohort? Có giảm giá / flash sale / thay đổi mix kênh cùng lúc không? Organic có nhích không? Cost để đổi lấy doanh thu đó là bao nhiêu? Nếu không tách được, rất dễ gắn nhầm nguyên nhân.
Cùng một thói quen hoài nghi, áp ra đời thường cũng cứu được bạn khỏi nửa timeline chuyên gia nói chắc: claim nghe cứng, thiếu định nghĩa, thiếu mẫu, thiếu confounder. Bạn không cần phủ nhận hết mọi thứ. Bạn cần hỏi đủ trước khi tin và trước khi ship insight.
Tư duy này quan trọng với DA. Và quan trọng với bất kỳ ai sống trong thời quá nhiều người nói rất chắc trên mạng.
4. Lộ trình chui vào ngành DA (không cần vội title)
Việc đầu tiên và quan trọng: rèn nghiệp vụ. Đừng đặt mục tiêu phải đúng role Data Analyst ngay từ ngày một nếu nền function / industry còn mỏng.
Những role mình thấy gần và dễ chuyển sang DA hơn:
- Kế toán / tài chính
- Sale admin
- Vận hành / hỗ trợ vận hành
- Marketing
- CS hoặc business ops nếu tuần nào cũng đụng request số và quy trình
Tập trung, chịu quan sát: quy trình chạy thế nào, số liệu sinh ra từ đâu, ai dùng số đó để quyết gì. Trong quá trình đó gần như chắc bạn đụng Excel hoặc Google Sheet: tối thiểu pivot, làm sạch nhẹ, đối soát. Đến đó, về bản chất bạn đã đang làm một phần việc của DA rồi. Chỉ chưa có title.
Heuristic thường nghe: dưới khoảng hai năm chịu quan sát và làm gần số, nhiều bạn nắm được quy trình cốt lõi của mảng mình đứng. Nhanh hay chậm phụ thuộc company, độ chủ động, và có ai mentorship không. Đừng biến con số thành deadline tự hành.
Tiếp theo, tự hỏi thành thật: job hiện tại còn giúp mình sâu hơn về nghiệp vụ, về cách đọc số, về công cụ không?
Nếu vẫn học được (domain mới, data bẩn hơn, stakeholder khó hơn): có thể ở lại thêm một nhịp, chủ động xin việc gần analysis. Nếu môi trường đã bão hòa skill và bạn chỉ lặp task không lớn thêm: lúc đó mới tính nhảy. Ưu tiên nơi quy mô lớn hơn, data nhiều hơn (sẽ gặp bẩn, thiếu, trễ: đó là chỗ mình lớn), hoặc đơn vị triển khai dịch vụ DA/BI nếu hợp hướng agency / consulting.
CV giai đoạn này không cần phô thành thạo mười lăm tool. Cần nói rõ:
- Mình hiểu sâu nghiệp vụ nào.
- Mình đã dùng dữ liệu thế nào để hỗ trợ quyết định.
- Trong lĩnh vực / bối cảnh nào.
- Kèm một vài case ngắn (đối soát, giảm lệch, làm rõ nguyên nhân, proxy metric thay đo thủ công, hỗ trợ ca / kênh…).
Đủ gần nghiệp vụ bên tuyển, cửa phỏng vấn thường mở. Khi ngồi phỏng vấn, case thật sẽ bị hỏi. Chỗ này không chém được, và cũng không nên chém.
- Chọn 1-2 mảng nghiệp vụ (function × industry), đừng ôm hết JD.
- Xếp stack: nghiệp vụ → phương pháp + tư duy → tool; AI không thay domain.
- Trước khi build đo đạc: hỏi Why ít nhất hai tầng (lý do metric, rồi mục đích phía sau).
- Trước khi ship insight: soi định nghĩa, cửa sổ thời gian, confounder.
- Vào ngành: rèn role gần + Excel/Pivot trước title DA; CV nói domain + case.
- Nhảy job khi môi trường hết nuôi skill, không nhảy chỉ vì thiếu title.
Không cần có title Data Analyst trên danh thiếp thì bạn mới được phép nghĩ và làm như một DA.
Nếu bạn đang map skill cho 3-6 tháng tới, mở Phụ lục bên dưới và tick vài ô cho đúng mảng đang đứng.
Phụ lục
Phụ lục để soi lại và làm, không thay phần luận ở trên. In riêng hoặc lưu bookmark cũng được.
A. Checklist nghiệp vụ (function × industry)
Bước 1. Chọn phạm vi
- Function mình đang / muốn sâu (vd. tài chính, sales, ops, marketing…)
- Industry mình đang / muốn sâu (vd. retail, F&B, SaaS, logistics…)
- Giao 1-2 mảng đủ hẹp để kể được trong phỏng vấn 5 phút
Bước 2. Năm tín hiệu bạn đang hiểu function (không chỉ thuộc tên metric)
- Kể được quy trình chính: việc bắt đầu từ đâu, kết thúc ở đâu, ai chạm số
- Nêu được grain thường dùng (dòng bill, đơn, khách, ca, SKU…)
- Biết owner gần đúng của 2-3 metric quan trọng (ai định nghĩa, ai chịu khi lệch)
- Phân biệt được vanity metric và metric dùng để quyết (ít nhất 1 cặp trong mảng)
- Chỉ ra 1 chỗ hay lệch giữa hai hệ / hai team (kế toán vs sales, ops vs finance…)
Bước 3. Việc tuần này (chọn 1)
- Ngồi shadow 1 quy trình (close, ca, campaign, đơn hoàn…) và ghi 10 dòng: số sinh ra lúc nào
- Viết glossary 5 metric team hay hỏi (định nghĩa + grain + filter mặc định)
- Lấy 1 dashboard đang dùng và ghi: thiếu definition / owner / cửa sổ thời gian chỗ nào
B. Thang Why (L0 / L1 / L2)
Dùng khi nhận request đo / đếm / làm dashboard vội.
| Level | Câu hỏi | Hành vi hay gặp | Hướng xử lý |
|---|---|---|---|
| L0 | Làm sao để có số theo đúng mặt chữ request? | Mua tool, thuê người đếm, build ngay | Chỉ làm nếu đã rõ cost và metric sẽ được dùng thế nào |
| L1 | Vì sao cần số đó? Chỉ tiêu thật sự là gì? | Hỏi sếp / stakeholder; tìm proxy từ data sẵn có | Ưu tiên dữ liệu hệ thống đã có; chấp nhận sai số có kiểm soát |
| L2 | Chỉ tiêu đó phản ánh quyết định / nút thắt nào? Còn metric nào cùng trả lời? | Đào mục đích: staffing, mặt bằng, mix, funnel… | Đề xuất metric thay thế hoặc bổ sung; tránh đo đúng cái dễ nhưng sai việc |
Nhắc case F&B (minh họa): request đếm người vào quán (L0) → cần khách/bill, khách/ca (L1, proxy line item) → bàn quay / staffing / giờ chết (L2).
- Quyết định nào sẽ đổi nếu có số này?
- Ai dùng số, tần suất ra sao?
- Data nào đã có thể proxy? Sai số chấp nhận được cỡ nào?
- Metric này có owner và definition viết ra chưa?
C. Sáu câu hoài nghi metric / campaign (dùng trong họp)
Copy khi ai đó kết luận quá chắc từ dashboard hoặc từ một đợt campaign.
- Metric này định nghĩa chính xác là gì (công thức, filter, loại trừ)?
- Grain là gì: user, order, session, bill, ngày?
- Cửa sổ thời gian và baseline so sánh là gì (WoW, MoM, YoY, cohort)?
- Có thay đổi đồng thời nào không (giá, mix kênh, season, sự cố hệ thống)?
- Đây là tổng hay cùng một cohort theo thời gian?
- Cost / effort để đổi lấy chuyển động số này là bao nhiêu (nếu đang gán win cho campaign)?
Hai claim hay gặp để luyện:
- Dashboard xanh = team tốt → hỏi (1)(3)(4).
- Doanh thu tăng = marketing thắng → hỏi (1)(2)(4)(5)(6).