Bài 1 — Vì sao phần lớn dự án dữ liệu không đổi được gì

Triệu chứng quen thuộc

Công ty mua công cụ phân tích, thuê người, dựng vài chục dashboard. Sáu tháng sau: dashboard không ai mở, mỗi phòng có con số riêng cho cùng một chỉ số, và các quyết định vẫn được đưa ra bằng ý kiến của người cấp cao nhất trong phòng họp.

Nguyên nhân gần như luôn giống nhau: dự án bắt đầu từ công cụ thay vì từ quyết định.

Chuỗi giá trị của dữ liệu

Dữ liệu chỉ tạo giá trị khi đi hết năm bước:

Thu thập → Tin được → Hiểu được → Được dùng → Đổi hành vi

Mỗi bước là một chỗ chuỗi có thể đứt, và chúng đứt theo thứ tự khác nhau ở từng tổ chức:

• Đứt ở bước 2: có dữ liệu nhưng không ai tin nó.
• Đứt ở bước 3: tin nhưng không ai đọc hiểu được.
• Đứt ở bước 4: hiểu nhưng không ai dùng khi quyết.
• Đứt ở bước 5: dùng nhưng không đổi gì.

Phần lớn đầu tư dồn vào bước 1, trong khi đứt gãy thật thường ở bước 2 và 4.

Bắt đầu từ quyết định, không từ dữ liệu

Câu hỏi mở đầu đúng không phải "chúng ta có dữ liệu gì" mà "quyết định nào chúng ta đang đưa ra tệ vì thiếu thông tin".

Với mỗi quyết định, hỏi tiếp:

• Ai đang quyết việc này, và bao lâu một lần?
• Họ đang dựa vào gì?
• Con số nào sẽ làm họ quyết khác đi?

Câu cuối là phép thử quan trọng nhất. Nếu không có con số nào thay đổi được quyết định, đừng đo. Rất nhiều chỉ số tồn tại chỉ vì đo được, không vì ai dùng chúng.

Phân biệt ba loại nhu cầu dữ liệu

• Đo lường: chúng ta đang làm thế nào? Dashboard, báo cáo định kỳ.
• Chẩn đoán: vì sao con số đó thay đổi? Phân tích sâu, theo tình huống.
• Vận hành: dữ liệu chạy trong sản phẩm — gợi ý, cảnh báo, tự động hoá.

Ba loại này cần hạ tầng, độ trễ và mức chính xác khác nhau. Nhầm lẫn chúng dẫn tới xây một hệ thống đắt cho nhu cầu rẻ, hoặc ngược lại.

Sai lầm thường gặp

• Bắt đầu từ công cụ thay vì từ quyết định.
• Đầu tư hết vào thu thập, bỏ qua chỗ chuỗi thật sự đứt.
• Đo mọi thứ đo được, kể cả khi không ai dùng.
• Dùng một kiến trúc cho cả ba loại nhu cầu.

Checklist kết bài

• [ ] Tôi biết chuỗi giá trị dữ liệu đứt ở bước nào trong tổ chức mình.
• [ ] Tôi bắt đầu từ quyết định cần cải thiện, không từ dữ liệu sẵn có.
• [ ] Mỗi chỉ số tôi đo đều có một quyết định gắn với nó.
• [ ] Tôi phân biệt nhu cầu đo lường, chẩn đoán và vận hành.

<!--les-append-->

Chẩn đoán chuỗi đứt ở đâu

Mỗi chỗ đứt có triệu chứng riêng và cách sửa riêng:

Chẩn đoán trước khi đầu tư. Mua thêm công cụ khi chuỗi đứt ở bước 5 là cách tiêu tiền không đổi được gì — và đó là sai lầm phổ biến nhất trong lĩnh vực này.

Bắt đầu từ quyết định, không từ công cụ

Cách làm ngược lại với cách phổ biến:

• Liệt kê 5 quyết định lặp lại mà đội bạn đưa ra mỗi tuần hoặc mỗi tháng.
• Với mỗi quyết định, hỏi: hôm nay chúng ta dựa vào gì?
• Hỏi tiếp: con số nào sẽ làm quyết định này tốt hơn?
• Chỉ xây đúng những con số đó.

Cách này thường cho ra 3–5 chỉ số cần thiết, thay vì 40 dashboard không ai dùng.

Phép thử trước khi xây bất cứ thứ gì

Ba câu, và cả ba phải có câu trả lời cụ thể:

• Ai sẽ mở cái này? Một cái tên, không phải "ban lãnh đạo".
• Bao lâu một lần? Nếu câu trả lời là "khi cần", nó sẽ không được mở.
• Họ sẽ làm gì khác đi tuỳ theo con số? Nếu không trả lời được, đừng xây.

Câu thứ ba loại bỏ phần lớn yêu cầu dashboard, và việc loại bỏ đó là tiết kiệm thật.

Làm ngay

Liệt kê năm dashboard hiện có trong tổ chức bạn. Với mỗi cái, tìm xem ai đã mở nó trong 30 ngày qua. Con số đó thường gây bất ngờ, và nó là điểm khởi đầu trung thực. <!--/les-append-->

<!--case-append-->

Áp dụng vào Căng tin số

Suốt khoá này, mỗi bài sẽ kết thúc bằng cùng một tình huống: Căng tin khu A của Đại học Ánh Dương, nơi Phòng Quản trị – Đời sống và công ty Hòa Bình vừa chạy thử app đặt cơm trước ở quầy cơm trong bốn tuần. Bối cảnh đầy đủ, từ phỏng vấn tới đo lường, nằm trong lộ trình Từ người dùng tới user story; ở đây bạn nhìn nó bằng con mắt của người làm chiến lược dữ liệu cho cả tổ chức.

Điều đáng chú ý là căng tin đã có dữ liệu từ trước khi ai viết dòng code nào. Cô Hạnh ghi sổ suất bỏ đi, trung bình 40 suất mỗi ngày. Máy tính tiền cho thấy 62% doanh thu quầy cơm rơi vào 11:35–12:15. Hộp thư của Chị Lan nhận khoảng 25 email phàn nàn mỗi tháng. Thời khoá biểu cho biết khoảng 2.100 sinh viên có lớp kết thúc 11:30 và lớp kế tiếp 12:45 vào thứ Hai hoặc thứ Tư. Vậy mà mọi quyết định vẫn dựa vào cảm giác. Chuỗi đứt ở đâu?

• Sổ của Cô Hạnh: thu thập rồi, nhưng nằm trong bếp, không ai ngoài cô đọc. Đứt ở bước được dùng.
• Email phàn nàn: thu thập rồi, Chị Lan đọc hiểu được, nhưng Anh Tuấn nghe tới vài tuần sau. Cũng đứt ở bước được dùng, vì không có đường nào đưa nó tới người quyết.
• Doanh thu theo giờ: có trong máy, nhưng chưa ai hỏi câu hỏi nào cần tới nó.

Nếu nhóm bắt đầu bằng "mua công cụ phân tích cho căng tin", họ sẽ đầu tư vào bước thu thập, đúng chỗ không đứt. Bắt đầu từ quyết định thì khác hẳn. Ba quyết định lặp lại đáng cải thiện nhất:

Ba quyết định này cũng rơi vào ba loại nhu cầu khác nhau. Bảng "còn món" và phiếu in cho bếp là vận hành: phải đúng tới từng phút, nhân viên quầy bấm một nút là bảng đổi ngay. Bảng tuần cho Chị Lan là đo lường: chậm một ngày cũng không sao. Câu hỏi "vì sao tuần 3 xếp hàng chỉ còn 15 phút" là chẩn đoán: làm một lần, và câu trả lời là tuần thi giữa kỳ, sinh viên về sớm. Dựng chung một hệ thống thời gian thực cho cả ba là tốn tiền cho thứ không cần.

Phép thử ba câu cũng loại bỏ nhiều thứ nghe hấp dẫn. "Biểu đồ số lượt mở app theo giờ" sẽ do ai mở, và họ làm gì khác đi? Không ai trả lời được, nên chưa xây.

Thử ngay: chọn một trong ba quyết định ở bảng trên và viết ra hôm nay người đó đang dựa vào gì. Nếu câu trả lời là "kinh nghiệm", hãy ghi thêm một con số cụ thể có thể khiến họ đổi ý. <!--/case-append-->