Menu
Học tập
Khóa học Lộ trình nghề nghiệp Roadmap BA → CPO BA → Product Manager Tài liệu & Sách
Cộng đồng
Cộng đồng Interview Questions
Công cụ
Phân tích CV Theo dõi ứng tuyển Hiring Pipeline Luyện phỏng vấn Tối ưu LinkedIn Đàm phán lương
Tài khoản
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 19 — Data thinking và SQL cho ex-Sales

Từ Sales/BD sang BA: Lộ Trình Chuyển Đổi Bài 19/60

Mở đầu — vì sao bài này quan trọng

Khi còn làm Sales hoặc BD, bạn đã sống chung với data mỗi ngày — chỉ là bạn không gọi nó bằng cái tên đó. Bạn nhìn pipeline để biết tháng này có cán đích không. Bạn đọc forecast để báo cáo sếp. Bạn xem dashboard Salesforce hay HubSpot để biết lead nào "nóng", deal nào sắp rớt. Tất cả những điều đó đều là làm việc với dữ liệu. Vấn đề là: bạn quen với data đã được dọn sẵn, đóng gói đẹp đẽ trên một cái màn hình.

Khi chuyển sang BA, mối quan hệ của bạn với data thay đổi căn bản. Bạn không còn là người tiêu thụ dashboard nữa — bạn trở thành người đặt câu hỏi với dữ liệu thô, người định nghĩa con số đó được tính như thế nào, và người kiểm chứng xem những gì stakeholder nói có khớp với những gì hệ thống ghi nhận hay không. Đây chính là lúc kỹ năng "data thinking" và một ít SQL trở thành vũ khí.

Tin tốt cho bạn: ex-Sales có lợi thế cực lớn ở đây mà nhiều BA trái ngành (từ kế toán, từ QA, từ dev) không có — đó là giác quan kinh doanh. Bạn biết một con số bất thường nghĩa là gì với doanh thu, bạn biết khi nào nên nghi ngờ một báo cáo "đẹp quá". Bài này sẽ giúp bạn ghép cái giác quan đó với khả năng tự mình chạm vào dữ liệu, để khi ngồi họp với dev và team data, bạn không còn phải gật gù cho qua chuyện.

Khái niệm cốt lõi

Data thinking là gì — và khác gì với "đọc dashboard"

Data thinking không phải là biết dùng công cụ. Nó là một thói quen tư duy: trước mỗi quyết định hay yêu cầu, bạn tự hỏi "dữ liệu nào chứng minh điều này?" và "con số này được tính ra từ đâu?".

Khi làm Sales, nếu dashboard báo "tỷ lệ chốt deal 22%", bạn tin và dùng luôn. BA thì phải đào sâu hơn:

  • 22% này tính trên mẫu nào? Tất cả lead, hay chỉ lead đã qua vòng demo?
  • "Chốt" được định nghĩa thế nào — ký hợp đồng, hay đã thu tiền?
  • Khoảng thời gian nào? Tháng này, hay rolling 90 ngày?
Cùng một con số, ba định nghĩa khác nhau có thể cho ra ba kết quả lệch nhau 5–10%. Với BA, việc làm rõ định nghĩa của metric quan trọng hơn cả con số. Đây gọi là hiểu metric definition và data lineage (nguồn gốc dữ liệu — con số đi từ đâu, qua những bước biến đổi nào).

Raw data và data model — thế giới phía sau dashboard

Cái dashboard bạn từng nhìn chỉ là lớp vỏ. Phía sau nó là các bảng dữ liệu (tables) nằm trong database. Mỗi bảng giống một sheet Excel khổng lồ: có cột (columns/fields) và hàng (rows/records).

Ví dụ một hệ CRM đơn giản thường có:

  • Bảng customers (khách hàng): mỗi hàng là một khách, có customer_id, name, phone, created_at.
  • Bảng deals (cơ hội bán hàng): có deal_id, customer_id, value, stage, closed_at.
  • Bảng activities (hoạt động): cuộc gọi, email, meeting gắn với từng deal.
Điều then chốt bạn cần nắm: các bảng liên kết với nhau qua khóa (key). customer_id xuất hiện ở cả customers và deals chính là sợi dây nối hai bảng. Hiểu được cách các bảng nối nhau, bạn sẽ hiểu được "vũ trụ dữ liệu" của sản phẩm — và đây là nền tảng để bạn viết requirement chính xác.

SQL — ngôn ngữ để hỏi chuyện dữ liệu

SQL (Structured Query Language) là cách bạn "đặt câu hỏi" trực tiếp với database. Bạn KHÔNG cần trở thành data engineer. Mức độ một BA cần đạt là đọc hiểu và viết được truy vấn cơ bản đến trung bình. Năm thành phần xương sống:

  • SELECT — chọn cột bạn muốn xem.
  • FROM — từ bảng nào.
  • WHERE — lọc theo điều kiện.
  • GROUP BY — gom nhóm để tính tổng/đếm/trung bình.
  • JOIN — nối hai bảng lại với nhau.
Một truy vấn rất "Sales" để bạn dễ hình dung:

SELECT stage, COUNT(*) AS so_deal, SUM(value) AS tong_gia_tri
FROM deals
WHERE closed_at >= '2026-01-01'
GROUP BY stage;

Câu này nghĩa là: "Đếm số deal và cộng tổng giá trị, gom theo từng giai đoạn (stage), chỉ tính các deal từ đầu năm 2026." Đó chính là cái pipeline report bạn từng xem — nhưng giờ bạn tự tạo ra nó, theo đúng định nghĩa bạn muốn.

JOIN là khái niệm khiến nhiều người mới sợ, nhưng bản chất rất đời thường: nó là phép "ghép hai danh sách dựa trên một cột chung". Muốn biết tên khách hàng của mỗi deal? Bạn nối deals với customers qua customer_id:

SELECT c.name, d.value, d.stage
FROM deals d
JOIN customers c ON d.customer_id = c.customer_id
WHERE d.value > 100000000;

"Lấy tên khách, giá trị và giai đoạn của mọi deal trên 100 triệu đồng."

Tình huống thực tế

Tình huống 1 — Con số "đẹp" che giấu sự thật (SaaS, TP.HCM)

Hùng là cựu BD của một startup SaaS quản lý bán hàng tại TP.HCM, vừa chuyển sang vai trò BA. Trong buổi review quý, Giám đốc Marketing tự hào báo cáo: "Tỷ lệ kích hoạt tài khoản (activation rate) đạt 68%, rất tốt." Cả phòng gật gù.

Nhờ vẫn còn giác quan của dân sales — "tốt quá thì phải nghi" — Hùng xin quyền đọc database và tự chạy một truy vấn. Anh phát hiện công thức dashboard đang tính: activation = số user đăng nhập lần 2 chia tổng user đăng ký. Nhưng định nghĩa "kích hoạt" mà sản phẩm cam kết với khách lại là user đã tạo ít nhất 1 đơn hàng thật.

Khi tính lại theo định nghĩa đúng:

SELECT COUNT(DISTINCT user_id) AS user_kich_hoat
FROM orders
WHERE created_at >= '2026-04-01';

So với tổng user đăng ký, con số thật chỉ là 31%, không phải 68%.

Bài học: Một con số chỉ có nghĩa khi gắn với định nghĩa rõ ràng. Vì Hùng dám đào xuống raw data thay vì tin dashboard, công ty kịp điều chỉnh chiến lược onboarding trước khi đốt thêm ngân sách quảng cáo vào một "thành công" ảo.

Tình huống 2 — JOIN cứu một requirement sai (Fintech, Hà Nội)

Linh, ex-Sales của một công ty fintech cho vay tiêu dùng ở Hà Nội, được giao viết requirement cho tính năng "cảnh báo khách hàng có nguy cơ trễ hạn". Stakeholder mô tả miệng: "Lấy danh sách khách có khoản vay đang hoạt động và đã từng trễ hạn trên 5 ngày."

Thay vì viết requirement dựa trên lời kể, Linh tự kiểm chứng bằng cách nối hai bảng loans và payments:

SELECT l.customer_id, COUNT(p.payment_id) AS so_lan_tre
FROM loans l
JOIN payments p ON l.loan_id = p.loan_id
WHERE l.status = 'active' AND p.days_late > 5
GROUP BY l.customer_id
HAVING COUNT(p.payment_id) >= 1;

Chạy thử, Linh phát hiện điều kiện này gom ra tới 14.000 khách — quá nhiều để gọi là "nguy cơ cao". Đào tiếp, cô nhận ra phần lớn chỉ trễ đúng 1 lần từ hai năm trước rồi trả đều đặn. Linh quay lại làm rõ với stakeholder và bổ sung điều kiện "trễ hạn trong vòng 6 tháng gần nhất", thu hẹp danh sách xuống còn khoảng 1.200 khách thật sự rủi ro.

Bài học: Khả năng tự chạm vào data biến BA từ người "chép lại lời stakeholder" thành người phản biện và tinh chỉnh requirement. Một requirement viết đúng ngay từ đầu tiết kiệm cho team dev hàng tuần làm lại.

Tình huống 3 — Đọc dữ liệu để ưu tiên tính năng (E-commerce, khu vực Đông Nam Á)

Một BA mới chuyển từ Sales tại một sàn thương mại điện tử khu vực ĐNÁ được hỏi: "Nên xây tính năng nào trước — bộ lọc nâng cao hay nút mua nhanh?" Thay vì tranh luận cảm tính, anh truy vấn log hành vi để xem người dùng thực sự bỏ giỏ hàng ở bước nào:

SELECT buoc_thanh_toan, COUNT(*) AS so_phien
FROM checkout_events
WHERE event_date >= '2026-05-01'
GROUP BY buoc_thanh_toan
ORDER BY so_phien DESC;

Dữ liệu cho thấy 41% phiên rớt ngay ở bước chọn địa chỉ giao hàng — chẳng liên quan gì đến cả hai tính năng đang bàn. Quyết định được đổi hướng sang tối ưu form địa chỉ.

Bài học: Data thinking giúp BA đưa ra quyết định ưu tiên dựa trên bằng chứng, chứ không phải dựa trên ai nói to nhất trong phòng họp.

Hướng dẫn từng bước

Đây là lộ trình thực tế để một ex-Sales đi từ "sợ database" đến "tự tin truy vấn":

  • Vẽ sơ đồ data model của sản phẩm bạn đang làm. Xin team dev hoặc data một sơ đồ ERD (Entity Relationship Diagram), hoặc tự liệt kê 5–7 bảng chính và mối liên hệ giữa chúng. Đây là tấm bản đồ của bạn.
  • Học 5 từ khóa SQL cốt lõi. SELECT, FROM, WHERE, GROUP BY, JOIN. Chỉ cần làm chủ năm thứ này, bạn đã trả lời được 80% câu hỏi nghiệp vụ thường gặp.
  • Bắt đầu từ truy vấn bạn đã hiểu nghiệp vụ. Đừng học SQL bằng dữ liệu lạ. Hãy tái tạo lại chính những báo cáo Sales bạn từng xem: tổng doanh thu theo tháng, top khách hàng, tỷ lệ chốt theo nhân viên. Vì bạn đã biết kết quả "đúng" trông như thế nào, bạn sẽ tự kiểm tra được mình.
  • Luôn hỏi về metric definition trước khi viết requirement. Mỗi khi gặp một con số, ghi lại: nó được tính từ bảng nào, lọc điều kiện gì, theo khoảng thời gian nào. Đưa định nghĩa này vào tài liệu.
  • Dùng môi trường an toàn để thực hành. Yêu cầu quyền truy cập read-only vào bản sao database (staging/replica), tuyệt đối không tập trên database production. Công cụ phổ biến tại các công ty VN: Metabase, Redash, DBeaver, hoặc query editor sẵn có.
  • Đối chiếu kết quả với người trong cuộc. Sau khi chạy truy vấn, mang con số đi xác nhận với dev hoặc data analyst. Việc này vừa kiểm tra bạn hiểu đúng, vừa xây dựng uy tín "BA này biết việc".

Lỗi thường gặp & mẹo

  • Tin dashboard tuyệt đối. Dashboard chỉ phản ánh định nghĩa của người đã dựng nó — có thể sai, có thể lỗi thời. Luôn truy ngược về định nghĩa gốc.
  • Quên rằng JOIN có thể nhân đôi dữ liệu. Khi nối một bảng "một" với một bảng "nhiều" (một khách có nhiều deal), số hàng phình lên. Nếu vô tình SUM giá trị khách hàng sau khi join, bạn sẽ cộng trùng. Mẹo: luôn kiểm tra số hàng trước và sau JOIN.
  • Nhầm COUNT(*) với COUNT(DISTINCT ...). Đếm số dòng khác với đếm số khách hàng duy nhất. Một khách mua 5 lần là 5 dòng nhưng chỉ 1 người. Nhầm chỗ này là nguồn gốc của vô số báo cáo sai.
  • Quên điều kiện thời gian và trạng thái. Dữ liệu thường lẫn cả bản ghi test, bản đã hủy (status = 'cancelled'), bản đã xóa mềm (deleted_at). Không lọc, con số của bạn sẽ phồng lên giả tạo.
  • Mẹo lớn nhất cho ex-Sales: Hãy biến giác quan kinh doanh thành "máy dò nói dối". Mỗi khi một con số khiến bạn thấy "ngon bất thường" hoặc "tệ vô lý", đó chính là tín hiệu nên mở SQL ra kiểm chứng. Trực giác của bạn từ thời bán hàng vẫn còn nguyên giá trị — giờ nó có thêm công cụ để chứng minh.

Bài tập thực hành

  • Vẽ data model. Lấy một sản phẩm bạn quen (CRM cũ của bạn, một app đặt đồ ăn, một sàn TMĐT). Liệt kê 5 bảng chính và vẽ mối liên hệ giữa chúng bằng giấy. Chỉ rõ cột khóa nối các bảng.
  • Viết 3 truy vấn từ ngôn ngữ nghiệp vụ. Diễn đạt thành SQL (chỉ cần viết ra, chưa cần chạy):
- "Tổng doanh thu theo từng tháng của năm 2026." - "Top 10 khách hàng có giá trị deal lớn nhất, kèm tên khách." - "Số deal đang ở giai đoạn 'negotiation' của mỗi nhân viên sales."

  • Săn lỗi định nghĩa. Chọn một metric trong báo cáo công ty bạn (hoặc một báo cáo Sales bạn từng dùng). Viết ra: nó được tính từ đâu, lọc điều kiện gì, có khoảng thời gian nào. Đặt ít nhất 2 câu hỏi phản biện về định nghĩa của nó.
  • (Nâng cao) Thực hành thật. Cài DBeaver hoặc dùng một dataset mẫu miễn phí (ví dụ database chinook hay northwind), chạy lại đúng 3 truy vấn ở bài 2 và đối chiếu kết quả với suy luận bằng tay của bạn.

Tóm tắt

Là ex-Sales, bạn đã quen tiêu thụ data dưới dạng dashboard, pipeline và forecast được dọn sẵn. Bước nhảy sang BA đòi hỏi bạn chuyển từ người đọc số thành người chất vấn số: hiểu raw data nằm trong các bảng, biết các bảng nối nhau qua khóa, và tự đặt câu hỏi với dữ liệu bằng SQL ở mức cơ bản đến trung bình.

Bạn không cần giỏi như data engineer — chỉ cần làm chủ SELECT, FROM, WHERE, GROUP BY, JOIN, cộng thói quen luôn truy về định nghĩa của mỗi metric. Quan trọng nhất: giác quan kinh doanh từ nghề bán hàng chính là lợi thế độc nhất của bạn — nó mách bảo bạn khi nào một con số "có mùi", và SQL cho bạn công cụ để chứng minh. Khi bạn tự chạm được vào dữ liệu, requirement bạn viết ra sẽ chính xác hơn, quyết định ưu tiên dựa trên bằng chứng, và uy tín của bạn trong mắt đội dev sẽ tăng lên rõ rệt.

Trước Tiếp