Dự Án BI: Lấy Yêu Cầu Từ Stakeholder Thế Nào?

Chào bạn, lại là Trí đây! Có một câu hỏi nghe rất hợp lý mà lại hỏng việc: anh chị cần báo cáo gì? Người được hỏi gần như không bao giờ trả lời đúng.

Trả lời nhanh: Người dùng hiếm khi biết chính xác mình cần gì, và càng ít khi nói ra được. Họ tới với một danh sách triệu chứng, còn việc tìm ra nguyên nhân là phần của bạn. Cách làm hiệu quả gồm ba việc: hỏi đúng câu trong buổi làm việc chung, quan sát họ làm việc thật, và chốt chỉ số cùng bảng đích trước khi dựng bất cứ thứ gì.

• Người ít tiếp xúc dữ liệu không biết hệ thống BI làm được những gì
• Một buổi làm việc chung với nhiều phòng ban rẻ hơn ba tháng dựng sai
• Quan sát tại chỗ cho thấy thứ người ta làm, khác với thứ người ta kể
• Chốt chỉ số trước, dựng công cụ sau, không đảo thứ tự
• Yêu cầu sẽ đổi, nên hệ thống phải dựng để sửa được

Cập nhật tháng 9/2026

1. Vì Sao Không Nên Hỏi Stakeholder Họ Cần Gì?

Vì câu trả lời họ đưa ra thường là một giải pháp họ tự nghĩ ra, chứ không phải vấn đề họ đang gặp. Bạn nhận được yêu cầu kiểu "cho tôi một biểu đồ cột theo tháng", trong khi thứ họ thật sự cần là biết vì sao doanh số quý này hụt.

Người ít tiếp xúc với dữ liệu không biết hệ thống BI làm được những gì. Họ không thể yêu cầu thứ họ không biết là có. Vì vậy họ mô tả bằng thứ quen thuộc nhất với họ, thường là một bảng Excel hoặc một biểu đồ họ từng thấy ở đâu đó.

Công việc của bạn không dừng ở chỗ trả lời từng câu hỏi lẻ mỗi ngày. Nó là tìm ra cả nhóm câu hỏi mà đội ngũ đang hỏi, rồi dựng một công cụ để họ tự lấy được câu trả lời. Khác biệt giữa hai cách làm đó quyết định bạn là người phục vụ yêu cầu hay người giải quyết vấn đề.

Bạn thử nhớ lại yêu cầu gần nhất mình nhận được xem: đó là một vấn đề hay một giải pháp đã được đóng gói sẵn?

2. Năm Câu Hỏi Nên Hỏi Trong Buổi Làm Việc Đầu Tiên

Cách hiệu quả để gỡ là tổ chức một buổi làm việc chung với các phòng ban liên quan, thay vì gặp từng người. Lý do thực dụng: các phòng ban thường có nhu cầu chồng lấn mà chính họ không biết, và ngồi chung một phòng sẽ lộ ra.

Năm câu hỏi dưới đây dùng được cho gần như mọi dự án dữ liệu.

1. Cần lấy thông tin gì từ dữ liệu này? Ví dụ hiệu quả của từng nhóm sản phẩm tại từng chi nhánh.
2. Chỉ số cụ thể nào cần đo? Chỉ số bán hàng, chỉ số marketing, hay chỉ số hiệu quả sản phẩm.
3. Dữ liệu lấy từ nguồn nào? Số liệu bán hàng, phản hồi khách hàng, hệ thống thanh toán tại quầy.
4. Ai cần quyền truy cập? Ban lãnh đạo, đội phân tích thị trường, hay cả nhân viên bán hàng.
5. Họ sẽ dùng dữ liệu này để quyết định việc gì? Quyết định giữ hay bỏ sản phẩm, quyết định giá, quyết định ngân sách khuyến mãi.

Câu thứ năm là câu quan trọng nhất và hay bị bỏ qua nhất. Một chỉ số không dẫn tới quyết định nào thì không đáng nằm trên dashboard, dù ai đó có xin cho bằng được.

3. Quan Sát Người Dùng Làm Việc Có Tác Dụng Gì?

Nó cho bạn thấy thứ người ta thật sự làm, khác với thứ người ta kể lại trong phòng họp. Khoảng cách giữa hai thứ này thường lớn hơn bạn tưởng.

Cách làm rất đơn giản. Bạn ngồi cạnh người dùng trong lúc họ làm báo cáo, quan sát từng thao tác, rồi hỏi vì sao họ làm bước đó. Câu hỏi "vì sao" quan trọng hơn câu hỏi "làm gì", vì nó nối công việc hằng ngày của họ với mục tiêu lớn của tổ chức.

Những thứ chỉ quan sát mới thấy: người ta xuất file ra Excel rồi sửa tay vì cột trong hệ thống đặt sai tên; người ta mở ba tab cùng lúc để đối chiếu vì không có chỗ nào gộp sẵn; người ta bỏ qua một nửa dashboard vì không hiểu con số đó nghĩa là gì. Không ai kể những chuyện này trong buổi họp, vì với họ đó là chuyện bình thường.

Chính những quan sát đó giải thích vì sao nhiều dashboard làm xong rồi không ai dùng. Người dựng đã trả lời đúng câu được hỏi, nhưng câu được hỏi lại không phải vấn đề thật.

4. Chốt Chỉ Số Và Bảng Đích Trước Khi Dựng Gì Cả

Chỉ số là một điểm dữ liệu đo được dùng để đánh giá hiệu quả. Bảng đích là vị trí cuối cùng nơi dữ liệu được đổ về để người dùng làm việc trên đó. Cả hai phải được chốt với các bên liên quan trước khi bạn viết dòng mã đầu tiên.

Thứ tự này nghe hiển nhiên mà rất hay bị đảo. Đội kỹ thuật thích bắt đầu bằng việc dựng đường ống vì đó là phần họ giỏi, rồi mới quay lại hỏi cần đo gì. Kết quả là đường ống chạy tốt nhưng chở sai hàng.

Số liệu về hậu quả khá rõ. Khảo sát 1.203 lãnh đạo quản trị dữ liệu do Gartner thực hiện tháng 7/2024 cho thấy 63% tổ chức không có hoặc không chắc mình có thực hành quản trị dữ liệu phù hợp. Gartner dự báo 60% dự án trí tuệ nhân tạo sẽ bị bỏ dở tới năm 2026 vì thiếu dữ liệu sẵn sàng.

Dữ liệu sẵn sàng cho AI không phải việc làm một lần rồi xong. Hãy coi đó là một hoạt động thường xuyên, nơi hạ tầng quản trị dữ liệu liên tục được cải thiện theo các tình huống sử dụng hiện có và sắp tới.

Roxane Edjlali, Senior Director Analyst, Gartner, phát biểu ngày 26/2/2025

Nếu bạn chưa có khung để chốt chỉ số với các bên liên quan, các biểu mẫu chiến lược BI cho bạn ba mẫu dùng được ngay trong buổi làm việc đầu tiên.

5. Ba Cách Lấy Dữ Liệu Từ Hệ Thống Nguồn

Sau khi chốt xong bảng đích, bạn chọn cách đưa dữ liệu về đó. Có ba cách, và lựa chọn phụ thuộc vào việc hệ thống nguồn hỗ trợ tới đâu cùng với nhịp người dùng cần số.

Cách thứ ba đơn giản nhất và cũng tốn tài nguyên nhất. Nhiều đội bắt đầu bằng cách này rồi chuyển sang cách thứ hai khi dữ liệu lớn lên. Phần cơ chế đường ống hoạt động ra sao tôi đã viết riêng trong bài về data pipeline và ETL.

6. Wayfair Làm Thế Nào Khi Dữ Liệu Giá Nằm Rải Rác?

Wayfair là hãng bán lẻ đồ gia dụng trực tuyến có trụ sở tại Boston, do Niraj Shah và Steve Conine lập năm 2002 dưới tên CSN Stores. Năm 2025 công ty đạt doanh thu 12,46 tỷ USD với khoảng 12.800 nhân viên, bán 14 triệu mặt hàng từ hơn 11.000 nhà cung cấp.

Vấn đề của họ đến từ chính quy mô đó. Hệ thống định giá có hàng nghìn đầu vào và đầu ra trên toàn bộ danh mục, thay đổi nhiều lần mỗi ngày, và mỗi thứ được sinh ra theo một cách khác nhau từ một nguồn khác nhau. Đội BI và những người cần dữ liệu giá gặp khó khi tìm, truy vấn và diễn giải trọn bộ dữ liệu, dẫn tới kết luận thiếu và thường là sai.

Cách họ làm đáng chú ý ở chỗ bước đầu tiên không phải bước kỹ thuật. Đội BI lùi lại và làm việc với các bên liên quan để hiểu họ đang dùng dữ liệu thế nào, gồm ba thứ: vấn đề kinh doanh họ đang giải, dữ liệu họ đang dùng và cách họ truy cập, và dữ liệu họ muốn dùng mà chưa lấy được.

Sau khi nghe xong, họ thiết kế một hệ thống nhắm ba đích: mọi dữ liệu cần thiết đều sẵn có và dễ hiểu, hệ thống chạy hiệu quả và không trễ, và thiết kế mở rộng được khi dữ liệu lớn thêm. Bản thiết kế đó được trình lại cho các bên liên quan duyệt trước khi dựng.

Kết quả là một bộ dữ liệu hợp nhất, nơi giá bán lẻ, các đầu vào chi phí và tình trạng sản phẩm nằm cùng một chỗ lần đầu tiên. Người dùng thôi phải tự nối các nguồn với nhau, và những quy trình chắp vá tốn kém được bỏ đi.

7. Câu Hỏi Thường Gặp

Doanh nghiệp nhỏ có cần làm buổi làm việc chung không?

Cần, chỉ là ngắn hơn. Với công ty dưới 20 người, một buổi 90 phút với ba tới bốn người dùng chính là đủ. Điểm quan trọng nằm ở chỗ họ ngồi cùng nhau, không phải ở chỗ buổi họp kéo dài bao lâu.

Stakeholder là ai trong một dự án BI?

Là bất kỳ ai chịu ảnh hưởng từ hệ thống bạn dựng. Thường gồm người ra quyết định dựa trên số, người nhập dữ liệu vào hệ thống nguồn, đội kỹ thuật quản lý hệ thống đó, và người dùng cuối mở báo cáo hằng ngày. Bỏ sót nhóm nào thì nhóm đó sẽ phản đối lúc bàn giao.

Nếu các phòng ban yêu cầu trái ngược nhau thì xử lý sao?

Đưa cả hai yêu cầu về câu hỏi thứ năm: quyết định nào sẽ được đưa ra dựa trên số này. Mâu thuẫn thường tan khi hai bên thấy họ đang phục vụ hai quyết định khác nhau, và giải pháp là hai khung nhìn trên cùng một bộ dữ liệu.

Yêu cầu đổi liên tục thì phải làm gì?

Chấp nhận rằng nó sẽ đổi và dựng hệ thống để sửa được. Việc xây quy trình BI là việc lặp đi lặp lại, không phải việc làm một lần. Điều cần giữ ổn định là bảng đích và định nghĩa chỉ số, còn khung nhìn bên trên thì đổi được dễ hơn nhiều.

Làm sao biết mình đã lấy đủ yêu cầu?

Khi bạn mô tả lại được công việc hằng ngày của người dùng bằng lời của chính họ, và họ gật đầu. Chưa tới mức đó thì bạn vẫn đang đoán. Một cách kiểm nhanh là viết ba câu mô tả họ sẽ làm gì vào sáng thứ Hai với hệ thống mới, rồi đưa họ đọc.

Người dùng nói không biết mình cần gì thì sao?

Đừng ép họ trả lời. Chuyển sang quan sát, và hỏi về việc họ đang làm thay vì việc họ muốn có. Câu trả lời hữu ích thường nằm trong thao tác thủ công mà họ lặp lại mỗi tuần.

8. Lời Kết Từ Tác Giả

Phần khó nhất của nghề BI không nằm ở SQL hay công cụ. Nó nằm ở chỗ ngồi nghe một người không rành kỹ thuật kể về công việc của họ, và dịch được nỗi bực dọc đó thành một bản thiết kế hệ thống.

Việc nên làm tuần này nếu bạn đang có một yêu cầu chờ xử lý: trước khi dựng, hỏi người gửi yêu cầu đúng một câu rằng họ sẽ ra quyết định gì dựa trên con số này. Câu trả lời sẽ cho bạn biết nên dựng cái gì, và đôi khi cho biết không nên dựng gì cả.

Một chuyện tôi vẫn chưa gỡ được. Sách vở nói phải nghe kỹ các bên liên quan, nhưng trong nhiều công ty Việt Nam thì người quyền lực nhất trong phòng hay là người có yêu cầu mơ hồ nhất, và phản đối họ thì rủi ro. Tôi chưa có công thức nào ổn cho tình huống đó. Nếu bạn từng vượt qua, kể tôi nghe cách bạn làm.

Bài này có ích thì chia sẻ cho người đang làm dự án dữ liệu, và theo dõi blog để nhận bài mới.

9. Nguồn Tham Khảo

• Gartner, "Lack of AI-Ready Data Puts AI Projects at Risk", 26/2/2025. Khảo sát 1.203 lãnh đạo quản trị dữ liệu, thực hiện tháng 7/2024
• Wikipedia, mục về Wayfair, cho các số liệu doanh thu, nhân sự và quy mô danh mục năm 2025
• Boston Globe, bài lược sử Wayfair, 13/2/2020, cho giai đoạn CSN Stores và việc hợp nhất thương hiệu