# Kiểm tra dữ liệu của khách hàng trước khi ký cam kết dự án AI

> Demo chạy mượt trên một file CSV sạch chưa nói được gì nhiều. Câu hỏi thật là dữ liệu production có đủ cho đúng use case mà bạn sắp hứa với khách hay không.

Bản gốc: https://fdetimes.net/vi/bach-khoa/danh-gia-muc-san-sang-du-lieu-cua-khach-truoc-khi-cam-ket-du-an-ai/

Tuần thứ hai tại khách hàng, sau một buổi demo suôn sẻ, giám đốc vận hành hỏi bạn: "Vậy ba tháng nữa có lên production được không?" Agent trong demo trả lời đúng gần như mọi câu. Nhưng nó chạy trên file CSV mà một chuyên viên phân tích đã lọc sạch giúp bạn từ hôm thứ Sáu.

Câu "có" hay "chưa" bạn nói lúc đó sẽ quyết định phần còn lại của engagement. Một bài trên blog Varsity viết rằng công việc của FDE bắt đầu từ dữ liệu production thật, từ review bảo mật và phân quyền. Mà dữ liệu production thì lộn xộn, bị phân quyền, và nằm trong tay những người chẳng có lý do gì để giúp bạn.

Nếu chỉ phát hiện điều đó khi đã build được nửa chừng, mọi lời hứa trước đó biến thành nợ. Vì vậy, việc của FDE là trả lời câu hỏi về dữ liệu trước khi ký cam kết. Việc này hoàn toàn làm được theo từng bước rõ ràng.

## Vì sao dashboard của khách đánh lừa bạn?

Trở ngại đầu tiên nằm ở niềm tin của khách. Easy.bi nhận xét rằng phần lớn doanh nghiệp tầm trung tin dữ liệu của họ tốt chỉ vì dashboard vẫn chạy, rồi nói thẳng: điều đó không có nghĩa là dữ liệu đã sẵn sàng cho AI. Veeam tách bạch hai chuyện này: mức sử dụng nói về hoạt động, còn mức sẵn sàng nói về năng lực.

Lý do khá dễ hình dung. Dashboard tổng hợp hàng nghìn dòng thành một con số, nên vài trăm dòng thiếu dữ liệu sẽ chìm mất. Một agent phải trả lời từng câu hỏi riêng lẻ thì sẽ vấp đúng vào những dòng đó.

**Điểm mấu chốt:** Dashboard chạy tốt không chứng minh được dữ liệu đã sẵn sàng cho AI.

Dashboard còn che đi một điều nữa: mức sẵn sàng luôn gắn với một use case cụ thể. Cùng một bộ dữ liệu có thể đủ cho bài toán này mà thiếu cho bài toán khác. Vì thế đừng chấm "dữ liệu của khách" nói chung, hãy chấm "dữ liệu của khách cho đúng việc X".

Phos AI Labs đưa ra năm tính chất của dữ liệu sẵn sàng cho AI: truy cập được, nhất quán, đầy đủ, chính xác và cập nhật. Easy.bi dùng một bộ khác gồm 4 tiêu chí, mỗi tiêu chí chấm trên thang điểm 1–5 theo mức độ hoàn thiện, trong một đợt đánh giá 5 ngày.

Năm tính chất của Phos đủ để soi bản thân dữ liệu, nhưng chưa trả lời được câu hỏi bạn có được phép dùng nó hay không. Câu hỏi đó có phần riêng, ngay sau ví dụ dưới đây.

## Một ví dụ làm từ đầu đến cuối

Thử hình dung một nhà phân phối phụ tùng muốn có agent trả lời đại lý hai câu: "mã này còn hàng không" và "bao giờ giao". Dashboard tồn kho của họ chạy ổn đã nhiều năm. Bạn viết use case thành một câu: agent phải trả lời đúng tồn kho và ngày giao dự kiến của từng đơn, tại thời điểm đại lý hỏi.

Tiếp theo, bạn xin quyền đọc thẳng vào hệ thống đặt hàng thay vì nhận file export, rồi lấy ngẫu nhiên 200 đơn. Kết quả giả định: chỉ 124 đơn có ngày giao dự kiến. Hai kho dùng hai cách đặt mã sản phẩm khác nhau, và dữ liệu chỉ được một người export thủ công mỗi đêm.

Phos chấm từng mục trong checklist theo Có/Một phần/Không (2/1/0 điểm), cộng điểm theo từng tiêu chí, và coi tiêu chí nào dưới 70% là lỗ hổng cần lấp trước khi build. RaftLabs, một vendor khác, cũng dùng mốc 70 nhưng trên tổng điểm 100, nên hãy xem con số này là kinh nghiệm của vendor chứ không phải chuẩn ngành.

Lấy tiêu chí "đầy đủ" làm mẫu, giả sử checklist có ba mục. Mỗi đơn có mã hàng: Có, 2 điểm. Tồn kho được ghi theo từng kho: chỉ một kho làm đủ, nên Một phần, 1 điểm. Đơn có ngày giao dự kiến: 124/200 đơn, tức 62%, nên Một phần, 1 điểm.

Tổng là 4/6 điểm, tức khoảng 67%, dưới ngưỡng 70%. Lưu ý tỷ lệ 62% không phải là điểm: nó chỉ là bằng chứng để bạn chọn "Một phần" thay vì "Có". Hai thước đo này khác nhau, và trộn chúng vào nhau là cách nhanh nhất để bảng điểm mất uy tín trước khách.

Bảng điểm giả định cho cả năm tính chất trông như sau:

| Tính chất | Cách kiểm tra | Kết quả giả định | Điểm |
|---|---|---|---|
| Truy cập được | Đọc trực tiếp hay phải nhờ người export? | Export tay mỗi đêm | Không (0), lỗ hổng |
| Nhất quán | Cùng một mã hàng ở hai kho có khớp nhau không? | Hai quy ước khác nhau | Không (0), lỗ hổng |
| Đầy đủ | Ba mục: mã hàng, tồn theo kho, ngày giao | Ngày giao có ở 124/200 đơn | 4/6, dưới 70%, lỗ hổng |
| Chính xác | Đối chiếu một mẫu với số kiểm kê thực tế | Cần khách xác nhận | Chưa chấm |
| Cập nhật | Độ trễ so với lúc đại lý hỏi | Trễ đến một đêm | Không (0) cho use case này |

Chính dòng "cập nhật" cho thấy vì sao phải chấm theo use case. Nếu khách muốn dự báo nhu cầu theo tháng thì dữ liệu trễ một đêm chẳng sao. Nhưng với agent trả lời theo thời gian thực, độ trễ đó đủ để agent báo sai tồn kho.

## Một tiêu chí trượt có đủ để dừng lại không?

Có, và đó là điểm mấu chốt. Ngưỡng của Phos áp cho từng tiêu chí chứ không cho điểm trung bình, nên bốn dòng tốt không bù được một dòng hỏng. Veeam diễn đạt cùng ý theo cách khác: trần của mức sẵn sàng AI luôn bị giới hạn bởi sàn của mức sẵn sàng dữ liệu.

Bản tin Revenue Experts áp logic này vào việc duyệt ngân sách: mỗi sáng kiến AI phải qua bốn phép kiểm dữ liệu cốt lõi, trượt bất kỳ phép nào là bị đánh dấu chưa sẵn sàng, dù các phần khác điểm cao đến đâu. Một trong bốn phép kiểm là chất lượng dữ liệu phải được kiểm tra trong 90 ngày gần nhất.

Áp vào nhà phân phối phụ tùng, câu hỏi đơn giản nhất bạn có thể gửi là: lần cuối ai đó kiểm tra trường ngày giao là khi nào? Nếu không ai trả lời được, người export hằng đêm và tỷ lệ 62% đã nói thay.

## Governance phải được hỏi từ tuần đầu

Bài trên blog Varsity nhắc rằng dữ liệu production bị phân quyền và có chủ. Trong ví dụ trên, thử hỏi: giá bán theo hợp đồng của từng đại lý có được phép hiện trong câu trả lời của agent không? Ai ký duyệt việc đó?

Nếu câu trả lời là bộ phận pháp chế và họ chưa từng nghe về dự án, bạn vừa tìm ra rủi ro lớn nhất. Cũng bài viết ấy nhấn mạnh discovery diễn ra với người vận hành, nên đừng chỉ hỏi người đã ký hợp đồng.

Hãy đưa ba câu hỏi vào buổi discovery đầu tiên: ai sở hữu dữ liệu, ai phê duyệt cho model đọc nó, và trường nào thuộc diện dữ liệu cá nhân hoặc nhạy cảm. Hỏi ở tuần đầu chỉ tốn một email. Phát hiện ra ở tuần thứ mười thì có thể tốn cả dự án.

## Tự làm thế nào, và những lỗi hay gặp

Quy trình có thể gói trong một tuần. Viết use case thành một câu, xin quyền đọc production thay vì nhận file export, lấy mẫu và chấm năm tính chất, rồi hỏi governance. Cuối cùng viết một bản ghi nhớ go/no-go dài một trang, liệt kê từng lỗ hổng, việc cần làm để lấp và người phụ trách.

Lỗi phổ biến nhất là tin vào dashboard của khách. RaftLabs cho rằng phần lớn tổ chức đánh giá mức hoàn thiện dữ liệu của mình cao hơn thực tế 2-3 bậc, và khuyên xử lý tiêu chí yếu nhất trước. Lỗi thứ hai là chấm dữ liệu chung chung, không gắn với use case.

Lỗi ngược lại cũng có thật: chờ dữ liệu hoàn hảo. Easy.bi ghi nhận phần lớn doanh nghiệp tầm trung chỉ ở mức 2-3, và cảnh báo rằng ai đợi đến mức 5 mới bắt đầu thì không bao giờ ship được.

Lỗi tệ nhất là làm đánh giá sau khi đã ký cam kết. Khi đó mọi lỗ hổng bạn tìm ra sẽ bị coi là lời bào chữa thay vì một phát hiện có giá trị.

## Bài tập cho tuần này

Lấy một bộ dữ liệu bạn đang có quyền truy cập, gán cho nó hai use case AI tưởng tượng có nhịp khác nhau: một cần trả lời tức thì, một chỉ cần báo cáo theo tháng. Chấm năm tính chất cho từng use case bằng điểm 2/1/0, rồi khoanh lại những dòng đổi kết luận.

Ghi kết quả thành một dòng có số liệu, kiểu "đánh giá dữ liệu cho một use case agent, phát hiện trường ngày giao chỉ có ở 62% đơn, đề xuất lấp lỗ hổng trước khi build". Đó là dòng đáng đưa vào CV, và là câu chuyện để kể khi mô tả công việc FDE nhắc đến scoping, discovery hay data assessment.

Lần tới có người hỏi "ba tháng nữa có lên production được không", bạn sẽ hỏi lại "cho việc gì" trước khi trả lời.

**Thử ngay tuần này:**

- Chọn một use case mà bạn hoặc khách hàng đang bàn, rồi viết nó thành một câu nêu rõ quyết định mà dữ liệu phải hỗ trợ.
- Lấy 200 bản ghi thật từ production (không lấy từ file export) và tính tỷ lệ bản ghi có đủ những trường mà use case cần.
- Gửi khách ba câu hỏi governance: ai sở hữu dữ liệu này, ai duyệt cho model đọc nó, có trường nào thuộc diện dữ liệu cá nhân.

## Nguồn

- [How to Check Data Readiness for AI Projects](https://phosailabs.com/blog/data-readiness-for-ai)

- [AI Data Readiness: The Assessment Your Team Skips (And Pays For Later)](https://www.easy.bi/blog/ai-data-readiness-assessment/)

- [Gate every AI budget on four data checks](https://revenueexperts.beehiiv.com/p/gate-every-ai-budget-on-four-data-checks)

- [Why Companies Need Forward Deployed Engineers, Not More AI Advice](https://www.interviewbit.com/varsity/blog/?p=808)

- [Is your business actually ready for AI? (The honest assessment)](https://www.raftlabs.com/blog/ai-readiness-assessment-guide)

- [Is Your Data Actually Ready for AI? A Readiness Check by Maturity Level](https://www.veeam.com/blog/ai-readiness-maturity-levels.html)