Business Understanding Trong Data Science: Hiểu Đúng Bài Toán Trước Khi Chạm Vào Dữ Liệu

9 trên 10 dự án data science thất bại không phải vì thuật toán sai. Phần lớn thất bại vì ngay từ đầu, team đã trả lời sai câu hỏi. Họ dùng dữ liệu đúng, mô hình đúng, nhưng để trả lời một bài toán mà sếp hoặc khách hàng không thật sự cần. Business Understanding trong data science chính là khoảng dừng lại hỏi cho rõ trước khi chạm vào dữ liệu — và đó cũng là giai đoạn 1 trong chuỗi 10 giai đoạn Data Science Methodology mà John Rollins từ IBM từng tóm tắt.

Bài này đi sâu vào đúng giai đoạn đó. Nếu bạn đang bắt đầu một dự án dữ liệu — dù là đồ án môn học, task sếp giao, hay đề xuất cho khách — thì đây là chỗ để bạn học cách viết ra yêu cầu kinh doanh (business requirements) rõ ràng, để mọi phân tích phía sau không phải làm lại.

Business Understanding trong data science là gì?

Business Understanding là bước đầu tiên trong một dự án dữ liệu: dịch yêu cầu của sếp, khách hàng, hay người dùng cuối thành một bài toán phân tích có thể giải được. Nói đơn giản, đây là lúc bạn ngồi lại, hỏi lại, ghi lại — trước khi mở bất kỳ file dữ liệu nào.

Hình dung thế này: sếp nhắn "em phân tích giúp anh đoàn khách rời bỏ dịch vụ tháng vừa rồi". Câu này nghe rõ, nhưng thật ra còn mơ hồ ở ít nhất 4 chỗ: rời bỏ nghĩa là hủy gói hay không gia hạn? đoàn khách nào — cá nhân hay doanh nghiệp? tháng vừa rồi là tháng nào so với hôm nay? anh muốn biết nguyên nhân, hay muốn biết phải làm gì để giữ họ? Nếu bạn mở file Excel ngay, bạn sẽ phải đoán — và đoán sai là lãng phí cả tuần.

Trong chuỗi Data Science Methodology của Rollins, giai đoạn 1 có nhiệm vụ: xác định bài toán kinh doanh, viết ra mục tiêu đo được (objective), tìm đúng người cần hỏi (stakeholder), và chốt lại bằng một danh sách business requirements — tức những câu cụ thể mà kết quả phân tích phải trả lời được. Từ đó, các giai đoạn sau mới biết cần dữ liệu gì, dùng phương pháp nào.

Câu hỏi mà mọi người nghĩ là câu hỏi, và câu hỏi thật

Một trong những điểm khó nhất của Business Understanding là phân biệt giữa "câu hỏi bề mặt" và "câu hỏi thật". Câu hỏi bề mặt là câu người ta nói ra ngay lúc giao việc. Câu hỏi thật là vấn đề đằng sau mà họ thật sự muốn giải.

Ví dụ quen thuộc: chủ tiệm cà phê nói "anh muốn tăng doanh thu". Nghe thì rõ, nhưng câu hỏi thật có thể là một trong ba hướng: tăng doanh thu bằng cách bán thêm cho khách cũ (giữ chân), bằng cách kéo khách mới (tăng tệp khách hàng), hay bằng cách nâng giá sản phẩm hiện có (tối ưu biên lợi nhuận). Mỗi hướng dẫn đến một bộ dữ liệu và một phương pháp phân tích khác nhau. Nếu bạn không hỏi lại, bạn sẽ làm báo cáo doanh thu tổng — số liệu đẹp, nhưng không giúp chủ tiệm đưa ra quyết định nào.

Cách để bắt được câu hỏi thật không có gì huyền bí: bạn hỏi tiếp. "Anh/chị muốn kết quả này phục vụ cho quyết định gì? Nếu có câu trả lời, anh/chị sẽ làm gì tiếp theo? Ai sẽ là người dùng kết quả này?" Ba câu hỏi này thường đủ để lộ ra bài toán thật.

Câu hỏi quan trọng nhất trong dự án data không phải "dữ liệu nào có sẵn", mà là "sếp mình sẽ đưa ra quyết định gì khi có kết quả".

Goal và Objective khác nhau ở chỗ nào

Hai từ này hay bị dùng lẫn, nhưng trong methodology của Rollins chúng tách bạch. Goal là lý do lớn — thường là mục tiêu kinh doanh dài hạn, kiểu "tăng lợi nhuận", "giảm rủi ro", "giữ chân khách hàng". Objective là đầu việc đo được, có con số, có thời hạn — kiểu "giảm 10% chi phí vận hành trong quý này".

Một Goal có thể có nhiều Objective. Quan trọng hơn: cùng một câu nói của sếp, có thể rơi vào hai Goal khác nhau, và mỗi Goal dẫn đến một hướng phân tích khác hẳn. Ví dụ: sếp nói "phòng kế toán đang tốn kém, em xem giúp".

• Nếu Goal là "tăng hiệu quả vận hành" → bạn sẽ tìm dữ liệu về thời gian xử lý chứng từ, sai sót, số giờ làm thêm.
• Nếu Goal là "tăng lợi nhuận ròng" → bạn sẽ tìm dữ liệu về chi phí nhân sự, chi phí phần mềm, và so với doanh thu phòng kế toán hỗ trợ.

Cùng một bộ phận, cùng một câu hỏi bề mặt, nhưng hai bài toán khác nhau. Chốt sai Goal là làm sai cả dự án, dù phần sau bạn có kỹ đến đâu.

5 bước làm rõ bài toán trước khi chạm vào dữ liệu

Rollins gợi ý một quy trình 5 bước để đi từ yêu cầu mơ hồ đến business requirements rõ ràng. Mình viết lại theo giọng dễ nhớ:

1. Hỏi lại: đừng ngại hỏi lại sếp/khách hàng cho đến khi bạn có thể tự nói lại bài toán bằng lời của bạn, và họ gật "đúng rồi, đó là điều tôi cần".
2. Xác định Goal: chốt một Goal rõ ràng, tốt nhất viết thành một câu ngắn.
3. Chia nhỏ thành Objective: mỗi Objective là một đầu việc đo được, có thể giao cho một người làm trong một khoảng thời gian.
4. Tìm stakeholder: những người có dữ liệu, người dùng kết quả, và người ra quyết định — họ không phải lúc nào cũng là một.
5. Chốt business requirements: viết ra 3–5 câu hỏi cụ thể mà kết quả phân tích phải trả lời được. Đây chính là "hợp đồng" giữa bạn và người giao việc.

Trong 5 bước đó, có một vai trò dễ bị bỏ qua: Business Sponsor. Đây là người chịu trách nhiệm định hướng dự án về phía kinh doanh, đảm bảo nguồn lực, và phá vỡ các rào cản khi bạn cần dữ liệu từ phòng ban khác. Khác với stakeholder thông thường (có thể là chuyên viên, nhân viên, khách hàng), Business Sponsor là người có quyền quyết định ngân sách và ưu tiên. Nếu bạn không tìm được người này, dự án rất dễ kẹt ở khâu xin dữ liệu.

Case study bảo hiểm y tế: hiểu sai câu hỏi tốn hàng triệu đô

Ví dụ kinh điển trong bài giảng của Rollins là một công ty bảo hiểm y tế tại Mỹ. Bối cảnh: ngân sách công cho chăm sóc sức khỏe đang bị cắt giảm, công ty phải phân bổ một quỹ giới hạn cho hàng triệu hồ sơ bệnh nhân. Câu hỏi kinh doanh ban đầu nghe rất chung: "làm sao để phân bổ nguồn lực y tế hạn chế sao cho chất lượng chăm sóc tối đa?".

Nếu dừng ở đây, bạn sẽ không biết bắt đầu từ đâu. Nhóm dự án ngồi lại, hỏi tiếp, và chốt lại: Goal là kiểm soát tỷ lệ tái nhập viện (readmission — bệnh nhân xuất viện rồi quay lại nhập viện trong một khoảng thời gian). Tại sao chọn chỉ số này? Vì mỗi lần tái nhập viện, công ty bảo hiểm phải chi trả thêm một đợt điều trị; cắt được readmission đồng nghĩa tiết kiệm ngân sách và nâng chất lượng sống cho bệnh nhân. Số liệu mà Rollins đưa ra trong bài giảng (cần kiểm tra lại từ tài liệu gốc của IBM nếu bạn muốn trích chính xác) là khoảng 30% bệnh nhân suy tim sung huyết tái nhập viện trong vòng 1 năm, và gần 50% trong vòng 5 năm.

Sau khi chốt Goal, nhóm dự án đi sâu hơn: nhóm bệnh nào chiếm tỷ trọng tái nhập viện cao nhất? Câu trả lời là CHF — Congestive Heart Failure, tức suy tim sung huyết, một bệnh mạn tính khiến tim không bơm đủ máu, bệnh nhân dễ phù phổi và phải nhập viện nhiều lần. Từ đó, Objective được chia nhỏ: dự đoán bệnh nhân nào có nguy cơ tái nhập viện cao trong vòng 30–90 ngày sau xuất viện, để nhân viên y tế gọi điện nhắc tái khám và điều chỉnh thuốc kịp thời.

Cuối cùng, nhóm chọn analytic approach là decision-tree model — mô hình cây quyết định. Bạn có thể hình dung nó giống sơ đồ hỏi đáp có/không mà bác sĩ hay dùng trong sách y khoa: bệnh nhân trên 65 tuổi không? Có. Trước đó từng nhập viện vì suy tim không? Có. Đang dùng nhiều hơn 3 loại thuốc tim mạch không? Có. Vậy nguy cơ tái nhập viện cao. Mô hình này dễ giải thích cho bác sĩ và cho cả công ty bảo hiểm, nên phù hợp với bài toán cần sự đồng thuận từ nhiều bên.

Cùng một dữ liệu bệnh nhân, nhưng hỏi "dự đoán bệnh nhân nào sẽ tái nhập viện" hay "giải thích vì sao bệnh nhân tái nhập viện" — là hai bài toán khác nhau, cần hai mô hình khác nhau.

4 dạng business requirements thường gặp

Từ case bảo hiểm trên, bạn có thể rút ra 4 dạng câu hỏi mà một business requirements thường rơi vào:

• Dự đoán kết quả (predict outcome): bệnh nhân nào sẽ tái nhập viện trong 30 ngày tới?
• Dự đoán mức rủi ro (predict risk): bệnh nhân nào có nguy cơ cao cần được chăm sóc đặc biệt?
• Hiểu chuỗi sự kiện: đâu là những bước trong hành trình điều trị dẫn đến tái nhập viện?
• Áp dụng cho ca mới: khi có một bệnh nhân mới xuất viện, mô hình có cho ra dự đoán hữu ích không?

Một checklist nhỏ: khi bạn viết được 3–5 business requirements cụ thể, mỗi cái rơi vào một trong bốn dạng trên, và mỗi cái đều có thể trả lời bằng dữ liệu sẵn có — bạn đã hiểu đúng bài toán. Nếu bạn chỉ viết được những câu kiểu "phân tích dữ liệu bệnh nhân", bạn chưa đến đâu.

Sai lầm thường gặp khi bỏ qua Business Understanding

Nếu bạn mới làm dữ liệu, mình liệt kê 5 lỗi hay gặp nhất để tránh:

• Chạy trước, hiểu sau: mở file CSV, vẽ biểu đồ, chạy thuật toán — rồi mới nhận ra đang trả lời câu hỏi khác.
• Nhận nguyên câu hỏi của sếp làm bài toán: "tăng doanh thu" là kết quả, không phải bài toán.
• Nhầm Goal với Objective: đặt mục tiêu kiểu "tăng trưởng" mà không có con số, không có thời hạn.
• Bỏ qua stakeholder: chỉ hỏi một người, không kiểm chứng với người dùng kết quả thật sự.
• Không viết business requirements: làm xong mới hỏi "vậy anh/chị muốn biết gì nhỉ?".

Mỗi lỗi này trông nhỏ, nhưng cộng lại có thể tốn cả tháng làm lại. Đây là lý do Business Understanding được Rollins đặt làm giai đoạn 1, không phải giai đoạn 0 hay giai đoạn "làm sau cũng được".

5 điều cần nhớ nếu bạn chỉ đọc một lần

• Business Understanding là bước dịch yêu cầu kinh doanh thành bài toán phân tích — diễn ra trước khi đụng vào dữ liệu.
• Phân biệt câu hỏi bề mặt và câu hỏi thật bằng cách hỏi tiếp: kết quả phục vụ quyết định gì, ai quyết định, thành công nghĩa là gì.
• Goal là lý do lớn, Objective là đầu việc đo được; một Goal có thể có nhiều Objective.
• 5 bước cốt lõi: hỏi lại → chốt Goal → chia Objective → tìm stakeholder (trong đó có Business Sponsor) → viết 3–5 business requirements.
• Một business requirements tốt là câu hỏi cụ thể, rơi vào một trong 4 dạng: dự đoán kết quả, dự đoán rủi ro, hiểu chuỗi sự kiện, hoặc áp dụng cho ca mới.

Nếu bạn muốn xem giai đoạn 1 này nằm ở đâu trong toàn bộ quy trình, có thể xem lại bản đồ 10 giai đoạn của Data Science Methodology. Với bạn đang cần bối cảnh rộng hơn về ứng dụng data science trong kinh doanh thực tế, hoặc đang ở giai đoạn doanh nghiệp bắt đầu với data science như thế nào thì ba bài viết đó sẽ bổ trợ cho nhau. Nếu bạn thích cách đi từ ví dụ đời thường vào case thực tế, bài về các ví dụ data science giải bài toán đời thường cũng dùng cùng phong cách case-driven.

Khi đã chốt business requirements, bước tiếp theo trong chuỗi Methodology là chọn cách tiếp cận phân tích — tức bước tiếp theo sau khi đã hiểu bài toán: chọn phương pháp. Và sau đó là khâu xác định dữ liệu cần thu thập, mà bạn có thể đọc tiếp ở bài về data requirements trong data science. Khi đã có cả bài toán lẫn dữ liệu, bạn sẽ đến giai đoạn hiểu bài toán trước khi chạm vào dữ liệu — tức khâu mô hình hóa.

Một lưu ý nhỏ: số liệu 30% tái nhập viện trong 1 năm và khoảng 50% trong 5 năm được Rollins nêu trong bài giảng Data Science Methodology của IBM. Nếu bạn cần trích dẫn chính xác cho báo cáo hoặc đồ án, hãy kiểm tra lại trực tiếp tài liệu gốc trên trang IBM SkillsBuild hoặc Coursera, vì số liệu này có thể đã được cập nhật theo nghiên cứu mới hơn. Tương tự, nếu bạn dùng bất kỳ công cụ hay framework nào được nhắc trong bài, nên kiểm tra trang chính hãng để chắc chắn tính năng và giá còn đúng ở thời điểm bạn đọc.