PoC AI thất bại không phải vì công nghệ AI không đủ tốt, mà vì dự án thử nghiệm được thiết kế, đo lường và vận hành sai ngay từ đầu. Phần lớn PoC AI không đi vào vận hành vì chọn sai bài toán, dữ liệu chưa sẵn sàng, kỳ vọng không thực tế, người dùng cuối không tham gia, hoặc không có kế hoạch và ngân sách cho giai đoạn sau PoC. Bài viết này phân tích 10 sai lầm phổ biến nhất khiến PoC AI thất bại, kèm dấu hiệu nhận biết, hậu quả và cách phòng tránh cho từng sai lầm, cùng checklist đánh giá PoC trước khi quyết định mở rộng hay dừng lại.
PoC — Proof of Concept, chứng minh khái niệm — là một dự án nhỏ, có giới hạn rõ ràng, nhằm trả lời một câu hỏi duy nhất: giải pháp AI này có tạo ra giá trị đủ lớn, với chi phí và rủi ro chấp nhận được, để doanh nghiệp đầu tư tiếp hay không. PoC không phải là một buổi demo công nghệ, không phải là một dự án sản phẩm thu nhỏ, và càng không phải là một cuộc thi xem mô hình nào đạt độ chính xác cao nhất. Một PoC thành công có thể kết luận không nên triển khai — đó vẫn là thành công, vì doanh nghiệp đã học được điều đó với chi phí nhỏ thay vì chi phí lớn. Ngược lại, một PoC chạy tốt trong phòng thí nghiệm nhưng không bao giờ đi vào vận hành là một PoC thất bại, dù báo cáo cuối kỳ có đẹp đến đâu.
Vì sao chủ đề này quan trọng ngay lúc này? AI tạo sinh, mô hình ngôn ngữ lớn và các công cụ AI có sẵn đã hạ thấp rào cản để bắt đầu một PoC: một đội ngũ nhỏ có thể xây dựng bản thử nghiệm trong vài tuần, thậm chí vài ngày. Nhưng rào cản để đưa AI vào vận hành thật — dữ liệu sạch và ổn định, tích hợp hệ thống, quy trình làm việc mới, giám sát mô hình, chi phí vận hành, sự chấp nhận của người dùng — không hề hạ thấp theo. Khoảng cách giữa làm được một bản demo ấn tượng và vận hành AI mỗi ngày trong doanh nghiệp chính là nơi hầu hết PoC thất bại. Bài viết này đi thẳng vào khoảng cách đó.
PoC AI là gì? Mục tiêu thật sự của một PoC AI
PoC AI là một thử nghiệm có giới hạn về phạm vi, thời gian và ngân sách, nhằm chứng minh rằng một giải pháp AI cụ thể giải quyết được một bài toán kinh doanh cụ thể, với mức độ hiệu quả có thể đo lường được. Định nghĩa này có ba thành phần không thể thiếu. Thứ nhất, bài toán kinh doanh cụ thể: PoC phải gắn với một vấn đề thật, có người chịu trách nhiệm về vấn đề đó, và có giá trị kinh tế nếu giải quyết được. Thứ hai, mức độ hiệu quả có thể đo lường: PoC phải định nghĩa trước thế nào là thành công, bằng con số và bằng cách đo mà mọi bên cùng đồng ý. Thứ ba, giới hạn rõ ràng: PoC có ngày bắt đầu, ngày kết thúc, phạm vi người dùng, phạm vi dữ liệu và ngân sách tối đa — vượt quá giới hạn đó thì đó không còn là PoC nữa.
Mục tiêu thật sự của PoC không phải là chứng minh AI làm được điều gì đó ấn tượng, mà là giảm rủi ro cho quyết định đầu tư tiếp theo. Trước khi bỏ ra hàng trăm triệu hoặc hàng tỷ đồng để triển khai AI trên toàn doanh nghiệp, lãnh đạo cần biết: liệu giải pháp này có thực sự giải quyết được bài toán hay không, dữ liệu của doanh nghiệp có đủ tốt hay không, người dùng có chấp nhận dùng hay không, và chi phí vận hành có nằm trong ngân sách hay không. PoC trả lời những câu hỏi đó bằng bằng chứng thực tế — đo được trên dữ liệu thật, với người dùng thật — thay vì bằng slide trình bày hay lời hứa của nhà cung cấp. Một tổ chức coi dừng PoC là thất bại sẽ không bao giờ làm PoC đúng cách: họ sẽ cố gắng cứu mọi PoC bằng mọi giá, kéo dài PoC vô thời hạn, hoặc diễn giải kết quả theo hướng có lợi, và cuối cùng sẽ đầu tư vào những giải pháp không đáng đầu tư.
Cuối cùng, PoC cần được phân biệt với ba khái niệm hay bị nhầm lẫn. Demo là một buổi trình diễn: nhà cung cấp cho doanh nghiệp xem AI làm được gì trên dữ liệu mẫu, trong môi trường được chuẩn bị sẵn. Demo không chứng minh được gì về doanh nghiệp của bạn. Prototype là một bản mẫu kỹ thuật: đội ngũ kỹ thuật xây dựng một phiên bản đơn giản để kiểm tra tính khả thi về mặt công nghệ. Prototype trả lời câu hỏi có làm được không, chứ không trả lời câu hỏi có nên làm không. Pilot là một đợt triển khai thử trên quy mô nhỏ nhưng trong môi trường vận hành thật: pilot diễn ra sau khi PoC đã chứng minh giá trị, và mục tiêu của pilot là kiểm tra khả năng vận hành, chứ không phải kiểm tra tính khả thi. Nhầm lẫn PoC với demo, prototype hay pilot là một trong những nguyên nhân khiến PoC thất bại — phần tiếp theo sẽ đi vào mười sai lầm cụ thể, bắt đầu từ việc chọn sai bài toán.
PoC AI khác gì một dự án AI thông thường?
Một dự án AI thông thường bắt đầu khi doanh nghiệp đã quyết định đầu tư: có ngân sách, có đội ngũ, có lộ trình triển khai và có cam kết về kết quả. PoC diễn ra trước quyết định đó, và mục tiêu của PoC chính là cung cấp thông tin để ra quyết định. Vì vậy PoC có những đặc điểm khác biệt căn bản. Thứ nhất, PoC có thời gian ngắn: thường từ 4 đến 12 tuần, đủ dài để thử nghiệm nghiêm túc nhưng đủ ngắn để không biến thành một dự án kéo dài. Thứ hai, PoC có phạm vi hẹp: một bài toán, một nhóm người dùng, một tập dữ liệu, một chỉ số thành công chính. Thứ ba, PoC có tiêu chí dừng rõ ràng: những điều kiện nào thì dừng, những điều kiện nào thì mở rộng, và ai là người quyết định. Thứ tư, PoC chấp nhận thất bại: một PoC kết luận không nên đầu tư vẫn là một PoC thành công, vì nó đã tiết kiệm cho doanh nghiệp một khoản đầu tư lớn vào một giải pháp không hiệu quả.
Một dự án AI thông thường cũng khác PoC ở chỗ nó có trách nhiệm vận hành: khi dự án kết thúc, hệ thống phải chạy ổn định, có người chịu trách nhiệm bảo trì, có ngân sách vận hành và có quy trình xử lý sự cố. PoC không có những trách nhiệm đó — và đó chính là lý do PoC có thể thất bại ngay cả khi kết quả kỹ thuật rất tốt: PoC chứng minh được AI làm được điều gì đó, nhưng không chứng minh được AI làm được điều đó trong điều kiện vận hành thật, với chi phí vận hành thật, và với sự chấp nhận của người dùng thật. Nhiều sai lầm trong phần tiếp theo xuất phát từ việc nhầm lẫn hai loại dự án này: đối xử với PoC như một dự án sản phẩm, hoặc đối xử với dự án sản phẩm như một PoC kéo dài.
Khi nào doanh nghiệp nên làm PoC AI, và khi nào không nên?
Doanh nghiệp nên làm PoC khi có một bài toán kinh doanh cụ thể, có dữ liệu để thử nghiệm, có người dùng sẵn sàng tham gia, và có một quyết định đầu tư đang chờ kết quả PoC. Nói cách khác, PoC có ý nghĩa khi câu trả lời của nó sẽ thay đổi quyết định của doanh nghiệp: nếu PoC thành công thì đầu tư tiếp, nếu PoC thất bại thì dừng lại hoặc thay đổi hướng đi. PoC cũng nên làm khi có sự không chắc chắn lớn về tính khả thi hoặc về giá trị: doanh nghiệp chưa biết dữ liệu của mình có đủ tốt hay không, chưa biết người dùng có chấp nhận giải pháp hay không, hoặc chưa biết chi phí vận hành có nằm trong ngân sách hay không. Trong những trường hợp đó, PoC là cách rẻ nhất để giảm sự không chắc chắn trước khi cam kết lớn.
Doanh nghiệp không nên làm PoC khi bài toán chưa rõ ràng (chúng ta hãy thử AI xem có gì hay không), khi không có dữ liệu để thử nghiệm, khi không có người dùng nào sẵn sàng tham gia, hoặc khi quyết định đầu tư đã được đưa ra rồi và PoC chỉ là thủ tục để hợp thức hóa quyết định đó. Doanh nghiệp cũng không nên làm PoC khi giải pháp đã được chứng minh rõ ràng trong ngành và có thể mua sẵn hoặc triển khai trực tiếp với rủi ro thấp: trong trường hợp đó, làm PoC chỉ tốn thời gian và làm chậm quyết định. Cuối cùng, doanh nghiệp không nên làm PoC khi PoC được đề xuất chỉ vì đối thủ cũng đang làm AI hay ban lãnh đạo muốn thấy AI trong doanh nghiệp — một PoC không có bài toán thật sẽ không bao giờ chứng minh được giá trị thật, dù kết quả kỹ thuật có tốt đến đâu.
10 sai lầm khiến PoC AI thất bại
Mười sai lầm dưới đây là những nguyên nhân phổ biến nhất khiến PoC AI không đi vào vận hành, dựa trên những gì đã quan sát được từ các doanh nghiệp đã triển khai PoC AI trong nhiều lĩnh vực khác nhau. Mỗi sai lầm được phân tích theo cùng một cấu trúc: sai lầm là gì, cơ chế khiến nó gây thất bại, dấu hiệu nhận biết sớm, hậu quả nếu không khắc phục, và cách phòng tránh. Doanh nghiệp có thể dùng phần này như một danh sách kiểm tra trước khi bắt đầu PoC của mình: nếu phát hiện một trong mười sai lầm đang tồn tại trong dự án của mình, hãy dừng lại và khắc phục trước khi đầu tư thêm.
Sai lầm 1: Chọn sai bài toán — PoC giải quyết vấn đề không ai quan tâm
Chọn sai bài toán là sai lầm nghiêm trọng nhất và cũng là sai lầm phổ biến nhất khiến PoC AI thất bại. Nhiều PoC được xây dựng xung quanh những bài toán mà đội kỹ thuật thấy thú vị, hoặc những bài toán mà công nghệ AI giải quyết tốt, nhưng không phải là những bài toán mà doanh nghiệp thực sự cần giải quyết. Ví dụ, một doanh nghiệp xây dựng PoC để phân loại email tự động, trong khi vấn đề thực sự của họ là tỷ lệ chốt đơn thấp vì nhân viên bán hàng không theo dõi khách hàng tiềm năng kịp thời. PoC phân loại email có thể đạt độ chính xác rất cao, nhưng nó không tạo ra giá trị kinh doanh nào, bởi việc phân loại email không phải là nút thắt của doanh nghiệp. Khi PoC kết thúc, lãnh đạo nhìn vào kết quả và hỏi: vậy thì sao? — và không ai trả lời được.
Chọn sai bài toán thường xảy ra theo ba cách. Cách thứ nhất là chọn bài toán theo công nghệ chứ không theo nhu cầu: đội ngũ thấy một công nghệ AI mới và tìm một bài toán để áp dụng nó, thay vì bắt đầu từ một vấn đề kinh doanh thật rồi tìm công nghệ phù hợp. Cách thứ hai là chọn bài toán quá lớn hoặc quá mơ hồ: chẳng hạn cải thiện trải nghiệm khách hàng nói chung, thay vì một bài toán cụ thể như giảm thời gian trả lời khách hàng từ 24 giờ xuống 2 giờ. Cách thứ ba là chọn bài toán không có người chịu trách nhiệm: không có giám đốc bộ phận nào coi bài toán đó là của mình, không có ai sẵn sàng ký xác nhận rằng bài toán này đáng giải quyết, và không có ai sẵn sàng thay đổi quy trình làm việc nếu PoC thành công. Nếu không tìm được một chủ bài toán sẵn sàng ký tên vào cam kết đó, doanh nghiệp nên coi đó là tín hiệu cảnh báo và dừng lại để tìm bài toán khác.
Dấu hiệu nhận biết: PoC được mô tả bằng ngôn ngữ công nghệ nhiều hơn ngôn ngữ kinh doanh; khi hỏi bài toán này tạo ra giá trị gì, đội dự án trả lời bằng độ chính xác của mô hình thay vì bằng tiền, thời gian hoặc mức độ hài lòng của khách hàng; không có giám đốc bộ phận nào tham gia họp định kỳ của dự án; hoặc PoC được chọn vì đội kỹ thuật muốn thử một công nghệ mới, chứ không phải vì doanh nghiệp đang gặp một vấn đề cụ thể.
Hậu quả: PoC có thể thành công về mặt kỹ thuật nhưng vẫn bị dừng lại sau khi kết thúc, vì không ai có lý do để tiếp tục đầu tư. Tệ hơn, một PoC giải quyết sai bài toán có thể làm lãnh đạo mất niềm tin vào AI nói chung: họ nhìn vào PoC và kết luận rằng AI không tạo ra giá trị, trong khi thực tế là PoC đã được đặt sai bài toán ngay từ đầu. Niềm tin đã mất thì khó lấy lại, và doanh nghiệp có thể bỏ lỡ những ứng dụng AI thực sự có giá trị chỉ vì một PoC sai bài toán.
Cách phòng tránh: Trước khi bắt đầu PoC, hãy viết ra một trang mô tả bài toán theo cấu trúc: bài toán là gì, ai đang gặp bài toán đó, bài toán gây ra thiệt hại bao nhiêu tiền hoặc bao nhiêu giờ mỗi tháng, và giá trị kinh tế nếu giải quyết được là bao nhiêu. Sau đó, yêu cầu giám đốc bộ phận sở hữu bài toán ký xác nhận vào trang mô tả đó, và cam kết tham gia vào dự án với thời gian cụ thể mỗi tuần. Nếu không tìm được một chủ bài toán sẵn sàng ký, doanh nghiệp nên coi đó là tín hiệu cảnh báo và dừng lại để tìm bài toán khác. Ngoài ra, hãy kiểm tra xem bài toán có nằm trong top 3 ưu tiên của bộ phận đó trong quý này hay không: nếu không, PoC sẽ không nhận được sự quan tâm cần thiết khi dự án gặp khó khăn.
Sai lầm 2: Dữ liệu chưa sẵn sàng — PoC chạy trên dữ liệu mẫu thay vì dữ liệu thật
Dữ liệu chưa sẵn sàng là sai lầm kỹ thuật phổ biến nhất khiến PoC AI thất bại. Nhiều PoC được xây dựng trên dữ liệu mẫu, dữ liệu đã được làm sạch thủ công, hoặc dữ liệu từ một thời điểm cụ thể, rồi khi đưa vào vận hành thật, mô hình gặp phải dữ liệu thiếu, dữ liệu sai, dữ liệu không nhất quán và dữ liệu đến muộn — những vấn đề mà dữ liệu mẫu không bao giờ thể hiện. Một PoC có thể đạt độ chính xác 95% trên dữ liệu mẫu nhưng chỉ đạt 60% trên dữ liệu thật, và khoảng cách đó đủ để biến một PoC có vẻ thành công thành một giải pháp không thể dùng được. Điều nguy hiểm là dữ liệu mẫu che giấu vấn đề: đội dự án nghĩ rằng dữ liệu của doanh nghiệp đã sẵn sàng, trong khi thực tế là họ chưa bao giờ thử nghiệm với dữ liệu thật.
Dữ liệu chưa sẵn sàng thường xuất hiện dưới ba dạng. Dạng thứ nhất là dữ liệu không đầy đủ hoặc không chính xác: nhiều trường dữ liệu quan trọng bị bỏ trống, bị nhập sai, hoặc bị ghi theo những quy ước khác nhau giữa các bộ phận. Ví dụ, cùng một khách hàng có thể được ghi là Công ty TNHH ABC trong hệ thống bán hàng và ABC Co. trong hệ thống chăm sóc khách hàng, khiến AI không nhận ra đó là cùng một khách hàng. Dạng thứ hai là dữ liệu không đại diện: dữ liệu huấn luyện chỉ phản ánh một phần của thực tế — chẳng hạn chỉ có dữ liệu của khách hàng ở thành phố lớn, chỉ có dữ liệu của những tháng cao điểm, hoặc chỉ có dữ liệu của những trường hợp dễ xử lý. Dạng thứ ba là dữ liệu không ổn định: dữ liệu đến không đều, bị cập nhật muộn, hoặc bị thay đổi định dạng mà không báo trước. Cả ba dạng đều khiến mô hình hoạt động tốt trong PoC nhưng thất bại trong vận hành thật, bởi PoC thường dùng dữ liệu đã được chọn lọc và làm sạch, trong khi vận hành thật phải đối mặt với dữ liệu nguyên bản.
Dấu hiệu nhận biết: đội dự án mất nhiều thời gian làm sạch dữ liệu hơn thời gian xây dựng mô hình; dữ liệu PoC được lấy từ một file Excel do một nhân viên chuẩn bị thủ công, chứ không phải từ hệ thống vận hành; khi hỏi dữ liệu sẽ được cập nhật như thế nào sau khi PoC kết thúc, không ai trả lời được; hoặc đội dự án thừa nhận rằng họ đã loại bỏ nhiều trường hợp khó khỏi dữ liệu huấn luyện vì những trường hợp đó làm giảm độ chính xác.
Hậu quả: PoC chứng minh được giá trị trên dữ liệu mẫu, doanh nghiệp quyết định đầu tư, rồi phát hiện ra rằng dữ liệu thật không đủ tốt để vận hành giải pháp — và việc làm sạch dữ liệu, xây dựng đường ống dữ liệu và thiết lập quy trình quản trị dữ liệu tốn thêm nhiều tháng và nhiều chi phí hơn cả việc xây dựng mô hình. Trong nhiều trường hợp, doanh nghiệp phải dừng dự án giữa chừng vì không thể giải quyết vấn đề dữ liệu trong ngân sách còn lại, và khoản đầu tư vào PoC trở thành chi phí chìm.
Cách phòng tránh: Trước khi bắt đầu PoC, hãy dành ít nhất hai tuần để đánh giá dữ liệu: dữ liệu nằm ở đâu, có đầy đủ hay không, có chính xác hay không, có được cập nhật thường xuyên hay không, và có những trường hợp đặc biệt nào mà dữ liệu không phản ánh được. Xây dựng một hồ sơ dữ liệu ngắn gọn, liệt kê từng nguồn dữ liệu, số lượng bản ghi, tỷ lệ trường bị thiếu, và những vấn đề chất lượng đã biết. Quan trọng nhất: PoC phải chạy trên dữ liệu thật, lấy trực tiếp từ hệ thống vận hành, với cùng quy trình làm sạch mà doanh nghiệp sẽ dùng khi vận hành thật. Nếu dữ liệu thật quá tệ để làm PoC, hãy coi đó là kết quả của PoC: doanh nghiệp cần đầu tư vào dữ liệu trước khi đầu tư vào AI. Ngoài ra, hãy đặt ra một điểm dừng dữ liệu: nếu sau hai tuần đánh giá mà dữ liệu vẫn chưa đủ tốt để thử nghiệm, hãy dừng PoC và chuyển sang dự án cải thiện dữ liệu.
Sai lầm 3: Không định nghĩa rõ thế nào là thành công — PoC không có vạch đích
Nhiều PoC bắt đầu mà không ai định nghĩa rõ thế nào là thành công, và khi PoC kết thúc, không ai biết PoC đã thành công hay thất bại. Đội dự án đo lường độ chính xác của mô hình, tốc độ xử lý, hoặc mức độ hài lòng của vài người dùng thử, nhưng những con số đó không trả lời được câu hỏi quan trọng nhất: giải pháp này có tạo ra giá trị kinh tế đủ lớn để đầu tư tiếp hay không. Khi không có tiêu chí thành công rõ ràng từ đầu, PoC sẽ bị đánh giá theo cảm tính: người ủng hộ sẽ nói PoC thành công vì mô hình chạy tốt, người phản đối sẽ nói PoC thất bại vì không thấy giá trị, và lãnh đạo sẽ không có căn cứ nào để ra quyết định ngoài cảm nhận chủ quan của từng người.
Sai lầm này thường xuất hiện theo hai dạng. Dạng thứ nhất là đo lường chỉ số kỹ thuật thay vì chỉ số kinh doanh: PoC báo cáo độ chính xác 92%, thời gian phản hồi 200 mili giây, hoặc mức độ hài lòng 4,5 trên 5, nhưng không ai biết những con số đó có ý nghĩa gì đối với doanh nghiệp. Độ chính xác 92% là tốt hay chưa đủ? Thời gian phản hồi 200 mili giây có tạo ra khác biệt cho khách hàng hay không? Mức độ hài lòng 4,5 trên 5 có tương ứng với việc khách hàng sẽ mua nhiều hơn hay không? Nếu không gắn chỉ số kỹ thuật với chỉ số kinh doanh — thời gian tiết kiệm được, chi phí giảm được, doanh thu tăng thêm, tỷ lệ khách hàng rời bỏ giảm đi — thì những con số kỹ thuật chỉ là những con số đẹp trên slide, không phải là bằng chứng để ra quyết định. Dạng thứ hai là đặt mục tiêu mơ hồ, không đo được: tài liệu PoC chứa những từ như hoàn toàn tự động, không cần con người, chính xác tuyệt đối, ngay lập tức — những từ không thể đo lường và không thể kiểm chứng. Một PoC được mô tả bằng những từ như vậy sẽ không bao giờ có vạch đích rõ ràng, bởi không ai có thể xác định được khi nào thì hoàn toàn tự động hay chính xác tuyệt đối đã đạt được.
Dấu hiệu nhận biết: tài liệu PoC không có mục tiêu chí thành công, hoặc chỉ có những mục tiêu chung chung như cải thiện hiệu quả hoặc nâng cao trải nghiệm khách hàng; khi hỏi PoC cần đạt con số nào để được coi là thành công, đội dự án trả lời bằng những con số kỹ thuật như độ chính xác 99% hay tự động hóa 100% mà không giải thích được những con số đó liên quan đến giá trị kinh doanh như thế nào; hoặc không có ai trong dự án nói rõ thế nào là đủ tốt, và mọi người đều có một định nghĩa khác nhau về thành công.
Hậu quả: PoC kết thúc trong tranh cãi: đội dự án nói PoC thành công vì mô hình đạt độ chính xác cao, lãnh đạo nói PoC chưa chứng minh được giá trị vì không thấy tác động kinh doanh, và người dùng nói PoC không giải quyết được vấn đề của họ. Kết quả là PoC bị kéo dài thêm vài tuần hoặc vài tháng để thu thập thêm bằng chứng, hoặc bị dừng lại trong sự thất vọng của tất cả các bên, hoặc tệ hơn — được mở rộng thành một dự án lớn dựa trên những bằng chứng không rõ ràng, và thất bại với chi phí lớn hơn nhiều.
Cách phòng tránh: Trước khi bắt đầu PoC, hãy định nghĩa đủ tốt bằng con số, với ba thành phần: một chỉ số kinh doanh chính, một ngưỡng tối thiểu để coi là thành công, và một cách đo mà mọi bên cùng đồng ý. Ví dụ: PoC được coi là thành công nếu chatbot trả lời đúng 80% câu hỏi thường gặp mà không cần nhân viên can thiệp, giúp giảm thời gian xử lý yêu cầu của khách hàng xuống dưới 2 phút, và được đo bằng cách so sánh kết quả của chatbot với kết quả của nhân viên trong cùng một khoảng thời gian, trên cùng một tập câu hỏi. Hãy viết tiêu chí thành công này vào tài liệu PoC, cho tất cả các bên cùng ký xác nhận, và cam kết không thay đổi tiêu chí trong quá trình thực hiện PoC: một khi tiêu chí đã được thống nhất, không ai có thể di chuyển vạch đích sau khi PoC kết thúc.
Sai lầm 4: Không có người dùng cuối tham gia — PoC được xây dựng trong phòng kín
Nhiều PoC được xây dựng bởi đội kỹ thuật và một vài người quản lý, mà không có sự tham gia của những người sẽ dùng giải pháp mỗi ngày. Khi PoC kết thúc và giải pháp được giới thiệu cho người dùng cuối, họ phát hiện ra rằng giải pháp không phù hợp với cách họ làm việc, không xử lý được những trường hợp đặc biệt mà họ gặp hàng ngày, hoặc yêu cầu họ thay đổi quy trình theo cách mà họ không sẵn sàng thay đổi. Người dùng cuối không phải là trở ngại cho PoC — họ là nguồn thông tin quan trọng nhất về việc giải pháp có thực sự giải quyết được bài toán hay không. Một PoC không có người dùng cuối tham gia là một PoC được xây dựng dựa trên giả định, chứ không phải dựa trên thực tế.
Người dùng cuối mang đến ba thứ mà không ai khác mang được. Thứ nhất, họ biết những trường hợp đặc biệt và những ngoại lệ mà dữ liệu không thể hiện: những mẹo mà chỉ người làm lâu năm mới biết, những khách hàng có yêu cầu đặc biệt, những tình huống mà quy trình chính thức không áp dụng được. Thứ hai, họ biết giải pháp cần tích hợp vào quy trình làm việc của họ như thế nào: họ dùng công cụ nào, họ chuyển đổi giữa các hệ thống ra sao, và họ có bao nhiêu thời gian cho mỗi tác vụ. Thứ ba, họ là người quyết định giải pháp có được dùng hay không: dù lãnh đạo có ra lệnh, người dùng vẫn có thể dùng giải pháp một cách hình thức, dùng song song với cách làm cũ, hoặc tìm cách lách qua giải pháp nếu họ thấy nó gây phiền toái. Một PoC không có người dùng cuối tham gia sẽ không phát hiện ra những vấn đề này cho đến khi đã quá muộn.
Dấu hiệu nhận biết: trong các buổi họp của dự án, không có ai là người sẽ dùng giải pháp hàng ngày; khi giải pháp được giới thiệu cho người dùng cuối lần đầu tiên, phản ứng đầu tiên của họ là cái này không dùng được cho trường hợp của tôi; hoặc người dùng cuối chỉ được mời tham gia vào cuối PoC, để kiểm thử chấp nhận, thay vì tham gia từ đầu để định hình giải pháp.
Hậu quả: PoC đạt kết quả kỹ thuật tốt nhưng bị người dùng từ chối khi triển khai, và doanh nghiệp phải quay lại sửa giải pháp — tốn thêm thời gian và chi phí — hoặc phải chấp nhận một giải pháp mà người dùng dùng một cách miễn cưỡng, với hiệu quả thấp hơn nhiều so với kỳ vọng. Tệ hơn, người dùng có thể báo cáo rằng AI không hiệu quả, không phải vì AI thực sự không hiệu quả, mà vì AI được thiết kế cho một quy trình mà họ không dùng. Lãnh đạo nghe báo cáo đó và kết luận rằng AI không phù hợp với doanh nghiệp, trong khi thực tế là PoC đã không lắng nghe người dùng ngay từ đầu.
Cách phòng tránh: Ngay từ tuần đầu tiên của PoC, hãy mời ít nhất hai hoặc ba người dùng cuối tham gia vào dự án, với thời gian cụ thể mỗi tuần — không phải với vai trò người kiểm thử ở cuối dự án, mà với vai trò người đồng thiết kế từ đầu. Hãy để họ tham gia vào việc định nghĩa bài toán, vào việc kiểm thử giải pháp trong quá trình xây dựng, và vào việc đánh giá kết quả cuối cùng. Ngoài ra, hãy quan sát họ làm việc thực tế trong một buổi, thay vì chỉ hỏi họ làm việc như thế nào: những gì người ta nói về cách họ làm việc thường khác với những gì họ thực sự làm. Một buổi quan sát thực tế có thể tiết lộ những vấn đề mà mười cuộc phỏng vấn cũng không phát hiện ra.
Sai lầm 5: Đo sai cách, đo trên dữ liệu không đại diện, không có đường cơ sở
Một PoC có thể đo được một con số ấn tượng nhưng vẫn không chứng minh được gì, nếu cách đo sai, dữ liệu đo không đại diện, hoặc không có đường cơ sở để so sánh. Sai lầm này tinh vi hơn những sai lầm khác, bởi PoC có vẻ như đã được đo lường nghiêm túc: có con số, có bảng, có biểu đồ. Nhưng những con số đó không trả lời được câu hỏi quan trọng nhất: giải pháp AI này có tốt hơn cách làm hiện tại hay không, và tốt hơn bao nhiêu. Một PoC đo được độ chính xác 90% nghe rất ấn tượng — cho đến khi biết rằng cách làm thủ công hiện tại cũng đạt 88%, và 2% chênh lệch đó không đủ để bù chi phí triển khai. Một PoC đo được thời gian xử lý giảm 50% nghe rất tốt — cho đến khi biết rằng dữ liệu đo chỉ bao gồm những trường hợp dễ, còn những trường hợp khó vẫn cần con người xử lý với thời gian không đổi. Một PoC đo lường mà không có đường cơ sở là một PoC chưa trả lời được câu hỏi quan trọng nhất: vậy thì sao?
Đo sai cách thường xảy ra theo ba cơ chế. Cơ chế thứ nhất là đo trên dữ liệu không đại diện: PoC được đánh giá trên một tập dữ liệu đã được chọn lọc — những trường hợp dễ, những khách hàng điển hình, những thời điểm thuận lợi — trong khi vận hành thật phải đối mặt với mọi trường hợp, kể cả những trường hợp khó và bất thường. Cơ chế thứ hai là đo chỉ số không liên quan đến giá trị kinh doanh: PoC đo độ chính xác của mô hình thay vì đo thời gian tiết kiệm được, đo số lượng câu trả lời đúng thay vì đo mức độ hài lòng của khách hàng, đo tốc độ xử lý thay vì đo chi phí giảm được. Cơ chế thứ ba là không có đường cơ sở: PoC không đo cách làm hiện tại trước khi triển khai AI, nên không thể so sánh AI với cách làm cũ, và không thể biết AI có thực sự tốt hơn hay không. Nhiều PoC bỏ qua bước đo đường cơ sở vì cho rằng cách làm cũ không cần đo — nhưng nếu không biết điểm xuất phát, doanh nghiệp sẽ không bao giờ biết mình đã tiến được bao xa.
Một vấn đề đặc biệt nghiêm trọng khi đo AI tạo sinh là đánh giá chất lượng đầu ra bằng cảm tính thay vì bằng tiêu chí cụ thể. Với mô hình phân loại hoặc dự báo, độ chính xác là một con số khách quan. Với AI tạo sinh — viết email, tóm tắt văn bản, trả lời khách hàng — chất lượng đầu ra khó đo hơn nhiều: một bản tóm tắt có thể đọc trôi chảy nhưng bỏ sót thông tin quan trọng, một email có thể lịch sự nhưng không thuyết phục, một câu trả lời có thể đúng về mặt kỹ thuật nhưng không phù hợp với khách hàng cụ thể. Nhiều PoC đánh giá AI tạo sinh bằng cách hỏi vài người dùng xem họ có hài lòng hay không, mà không định nghĩa trước những tiêu chí cụ thể như: bản tóm tắt có giữ lại tất cả những điểm quan trọng hay không, email có chứa thông tin sai hay không, câu trả lời có tuân thủ chính sách của doanh nghiệp hay không. Khi không có tiêu chí cụ thể, việc đánh giá trở thành cảm tính, và kết quả PoC trở thành ý kiến của người đánh giá, chứ không phải bằng chứng.
Dấu hiệu nhận biết: PoC không đo đường cơ sở trước khi bắt đầu; PoC chỉ báo cáo một con số duy nhất mà không giải thích con số đó có ý nghĩa gì; dữ liệu đánh giá được chọn lọc mà không nói rõ tiêu chí chọn lọc; hoặc khi hỏi AI tốt hơn cách làm hiện tại bao nhiêu, đội dự án không trả lời được vì họ chưa bao giờ đo cách làm hiện tại.
Hậu quả: PoC đưa ra một con số ấn tượng nhưng lãnh đạo không tin, vì họ không biết con số đó được đo như thế nào và so sánh với cái gì. Hoặc ngược lại, PoC đưa ra một con số ấn tượng và lãnh đạo tin, rồi đầu tư lớn, rồi phát hiện ra rằng trong vận hành thật, giải pháp không tốt hơn cách làm cũ bao nhiêu — và khoản đầu tư trở thành lãng phí. Cả hai trường hợp đều làm tổn hại niềm tin vào AI: trường hợp đầu làm lãnh đạo mất niềm tin vào đội dự án, trường hợp sau làm lãnh đạo mất niềm tin vào AI.
Cách phòng tránh: Trước khi bắt đầu PoC, hãy đo đường cơ sở: cách làm hiện tại đạt kết quả gì, với chi phí bao nhiêu, trong thời gian bao lâu. Sau đó, hãy định nghĩa ba lớp chỉ số cho PoC: chỉ số kỹ thuật (mô hình chính xác đến đâu), chỉ số vận hành (quy trình nhanh hơn bao nhiêu, chi phí giảm bao nhiêu), và chỉ số kinh doanh (doanh thu tăng thêm, khách hàng hài lòng hơn, rủi ro giảm đi). Hãy đo cả ba lớp, trên dữ liệu đại diện cho vận hành thật, và so sánh với đường cơ sở. Với AI tạo sinh, hãy định nghĩa tiêu chí đánh giá cụ thể trước khi bắt đầu: bản tóm tắt phải giữ lại những thông tin nào, email phải tuân thủ những quy định nào, câu trả lời phải chính xác về những điểm nào — và hãy để người có chuyên môn đánh giá theo những tiêu chí đó, thay vì hỏi cảm tính chung chung.
| Lớp chỉ số | Ví dụ | Câu hỏi cần trả lời |
|---|---|---|
| Chỉ số kỹ thuật | Độ chính xác, thời gian phản hồi | Mô hình làm việc tốt đến đâu? |
| Chỉ số vận hành | Thời gian tiết kiệm, chi phí giảm | Quy trình cải thiện bao nhiêu? |
| Chỉ số kinh doanh | Doanh thu, hài lòng khách hàng | Giải pháp có tạo ra giá trị thật không? |
Sai lầm 6: Kiểm thử sai cách — PoC đo điểm cao trên dữ liệu đã nhìn thấy
Một PoC có thể báo cáo kết quả kiểm thử rất tốt nhưng vẫn thất bại trong vận hành thật, nếu cách kiểm thử sai. Sai lầm này có nhiều dạng, nhưng tất cả đều có chung một hậu quả: đội dự án tin rằng mô hình của mình tốt hơn thực tế, và quyết định mở rộng dựa trên niềm tin sai lầm đó. Kiểm thử là bước mà PoC chứng minh giá trị của mình — nếu kiểm thử sai, mọi kết luận của PoC đều sai theo.
Dạng phổ biến nhất của kiểm thử sai cách là rò rỉ dữ liệu giữa tập huấn luyện và tập kiểm thử: dữ liệu kiểm thử vô tình chứa những mẫu mà mô hình đã nhìn thấy trong quá trình huấn luyện, hoặc chứa thông tin gợi ý đáp án. Mô hình đạt điểm cao trong kiểm thử vì nó nhìn trộm đáp án, chứ không phải vì nó đã học được quy luật. Một dạng khác là kiểm thử trên dữ liệu không đại diện: đội dự án chỉ kiểm thử trên các trường hợp đẹp — những trường hợp dễ, điển hình, không có ngoại lệ — trong khi vận hành thật đầy rẫy những trường hợp khó và bất thường. Một dạng nữa là kiểm thử trong môi trường khác với môi trường vận hành: PoC được kiểm thử trên dữ liệu đã được làm sạch, trong khi dữ liệu vận hành thật thì bẩn, thiếu và không nhất quán.
Một vấn đề đặc biệt nghiêm trọng khi kiểm thử AI tạo sinh là đánh giá bằng cảm tính thay vì bằng tiêu chí cụ thể. Với mô hình phân loại hoặc dự báo, kiểm thử là việc so sánh dự đoán với đáp án đúng — một việc khách quan. Với AI tạo sinh, kiểm thử là việc đánh giá chất lượng của văn bản, câu trả lời hoặc bản tóm tắt mà AI tạo ra — một việc mang tính chủ quan cao. Nhiều PoC đánh giá AI tạo sinh bằng cách cho vài người đọc thử và hỏi họ có hài lòng hay không, mà không định nghĩa trước những tiêu chí cụ thể. Kết quả là một PoC có thể được đánh giá là thành công chỉ vì người đánh giá dễ tính, hoặc bị đánh giá là thất bại chỉ vì người đánh giá khó tính. Ngoài ra, AI tạo sinh có một vấn đề mà mô hình truyền thống không có: hallucination. Mô hình ngôn ngữ lớn có thể trả lời trôi chảy nhưng sai sự thật, và nếu kiểm thử không bao gồm việc kiểm tra tính chính xác của thông tin, PoC sẽ không phát hiện ra vấn đề này cho đến khi khách hàng nhận được thông tin sai.
Dấu hiệu nhận biết: đội dự án không thể giải thích rõ dữ liệu kiểm thử được lấy từ đâu và được tách khỏi dữ liệu huấn luyện như thế nào; kết quả kiểm thử tốt một cách đáng ngờ, cao hơn nhiều so với kỳ vọng hợp lý; PoC chỉ được kiểm thử trên những trường hợp dễ; hoặc khi hỏi làm thế nào để biết mô hình sẽ hoạt động tốt trên dữ liệu mới, đội dự án trả lời bằng niềm tin chứ không phải bằng phương pháp kiểm thử cụ thể.
Hậu quả: PoC được mở rộng dựa trên kết quả kiểm thử sai, rồi thất bại trong vận hành thật với chi phí lớn hơn nhiều. Doanh nghiệp mất tiền, mất thời gian, và mất niềm tin — không chỉ vào đội dự án mà vào cả AI. Tệ hơn, một PoC kiểm thử sai có thể che giấu những vấn đề nghiêm trọng như rò rỉ dữ liệu hoặc hallucination, và những vấn đề đó chỉ lộ ra khi giải pháp đã ảnh hưởng đến khách hàng thật.
Cách phòng tránh: Hãy tách dữ liệu kiểm thử khỏi dữ liệu huấn luyện một cách nghiêm ngặt: dữ liệu kiểm thử phải là dữ liệu mà mô hình chưa bao giờ nhìn thấy, và phải đại diện cho dữ liệu vận hành thật — bao gồm cả những trường hợp khó và bất thường. Hãy kiểm thử trên dữ liệu mới, thu thập sau khi mô hình đã được huấn luyện, thay vì chỉ kiểm thử trên dữ liệu cũ đã có từ trước. Với AI tạo sinh, hãy định nghĩa tiêu chí đánh giá cụ thể trước khi kiểm thử: bản tóm tắt phải giữ lại những thông tin nào, câu trả lời phải chính xác về những điểm nào, và hãy để người có chuyên môn đánh giá theo những tiêu chí đó trên một mẫu đủ lớn. Cuối cùng, hãy kiểm thử cả những trường hợp biên: dữ liệu thiếu, dữ liệu sai định dạng, câu hỏi mơ hồ, yêu cầu bất thường — bởi vận hành thật đầy rẫy những trường hợp như vậy, và một mô hình chỉ hoạt động tốt trên trường hợp đẹp thì không phải là một mô hình tốt.
Sai lầm 7: Không tính đến tích hợp và vận hành thực tế — PoC chạy được nhưng không dùng được
Nhiều PoC chứng minh được mô hình AI hoạt động tốt trong môi trường thử nghiệm, nhưng không chứng minh được mô hình đó có thể tích hợp vào hệ thống hiện có và vận hành mỗi ngày hay không. Khi PoC kết thúc và doanh nghiệp bắt đầu triển khai, họ phát hiện ra rằng dữ liệu không chảy được từ hệ thống hiện có sang AI, kết quả của AI không quay lại được hệ thống nghiệp vụ, hoặc quy trình làm việc phải thay đổi quá nhiều để dùng AI. Một PoC chỉ tập trung vào mô hình mà không quan tâm đến tích hợp và vận hành là một PoC chưa hoàn thành: nó chứng minh được một phần của bài toán, nhưng bỏ qua phần khó nhất và tốn kém nhất của việc triển khai AI.
Tích hợp và vận hành bao gồm nhiều lớp mà PoC thường bỏ qua. Lớp thứ nhất là tích hợp dữ liệu: dữ liệu từ hệ thống hiện có đến được AI như thế nào, với tần suất nào, và ai chịu trách nhiệm khi dữ liệu bị lỗi hoặc đến muộn. Lớp thứ hai là tích hợp hệ thống: kết quả của AI quay lại hệ thống nghiệp vụ như thế nào, ai nhìn thấy kết quả đó, và họ làm gì với nó. Lớp thứ ba là tích hợp quy trình: quy trình làm việc của người dùng thay đổi như thế nào khi có AI, ai chịu trách nhiệm kiểm tra kết quả của AI, và điều gì xảy ra khi AI sai. Lớp thứ tư là vận hành và giám sát: ai theo dõi hiệu năng của mô hình sau khi triển khai, ai xử lý khi mô hình suy giảm, và ai chịu trách nhiệm khi hệ thống gặp sự cố. Một PoC không chạm đến bốn lớp này sẽ cho ra một giải pháp có thể chạy được nhưng không thể dùng được — giống như một chiếc xe chạy tốt trên đường thử nhưng không có đường để đi trong thành phố.
Dấu hiệu nhận biết: PoC được xây dựng hoàn toàn tách biệt với hệ thống hiện có, dùng dữ liệu được xuất ra file thay vì lấy trực tiếp từ hệ thống; Nhà cung cấp nói tích hợp rất dễ dàng nhưng không chỉ ra cụ thể sẽ tích hợp như thế nào; hoặc khi hỏi ai sẽ vận hành giải pháp sau khi PoC kết thúc, không ai trả lời được. Một dấu hiệu khác là PoC không có bất kỳ thử nghiệm tích hợp nào: không có lần nào dữ liệu thực tế chảy qua toàn bộ quy trình, từ hệ thống nguồn sang AI rồi trở lại hệ thống nghiệp vụ, với người dùng thật tham gia.
Hậu quả: PoC thành công nhưng doanh nghiệp phát hiện ra rằng việc tích hợp tốn nhiều thời gian và chi phí hơn cả việc xây dựng mô hình, hoặc quy trình làm việc phải thay đổi quá nhiều để dùng AI. Trong nhiều trường hợp, doanh nghiệp phải xây dựng lại giải pháp từ đầu để tích hợp được với hệ thống hiện có, và khoản đầu tư vào PoC trở thành lãng phí. Tệ hơn, một PoC không tính đến tích hợp có thể tạo ra một giải pháp mà không ai có thể vận hành: không có người theo dõi hiệu năng, không có quy trình xử lý sự cố, và không có ngân sách bảo trì.
Cách phòng tránh: Ngay từ khi thiết kế PoC, hãy vẽ sơ đồ luồng dữ liệu đầy đủ: dữ liệu đi từ đâu, qua những hệ thống nào, đến AI, rồi kết quả quay lại đâu, và ai nhìn thấy kết quả đó. Hãy yêu cầu đội dự án chứng minh ít nhất một lần trong PoC rằng dữ liệu thực tế có thể chảy qua toàn bộ quy trình đó, với người dùng thật tham gia — một lần chạy end-to-end còn có giá trị hơn mười lần kiểm thử mô hình trong môi trường tách biệt. Ngoài ra, hãy mời người chịu trách nhiệm vận hành hệ thống hiện có tham gia vào PoC từ đầu, và hãy hỏi họ: để vận hành giải pháp này mỗi ngày, cần những gì, và những gì có thể gây khó khăn. Cuối cùng, hãy dự trù ngân sách và thời gian cho tích hợp và vận hành ngay từ khi lập kế hoạch PoC, chứ không phải đợi đến khi PoC kết thúc mới bắt đầu tính.
Sai lầm 8: Không tính chi phí vận hành — PoC rẻ nhưng vận hành đắt
Nhiều PoC được phê duyệt vì chi phí thử nghiệm thấp, nhưng bị dừng lại sau khi kết thúc vì chi phí vận hành cao hơn nhiều so với dự tính. Chi phí PoC thường chỉ bao gồm thời gian của đội dự án và một khoản phí dùng thử công cụ AI — những chi phí một lần, có thể kiểm soát được. Chi phí vận hành thì khác: nó là chi phí lặp lại hàng tháng, bao gồm phí gọi API mô hình ngôn ngữ lớn, chi phí hạ tầng và lưu trữ, chi phí giám sát và bảo trì mô hình, chi phí hỗ trợ người dùng, và chi phí tái huấn luyện định kỳ. Một giải pháp AI có thể rẻ khi thử nghiệm với 100 người dùng, nhưng trở nên đắt đỏ khi vận hành cho 10.000 người dùng mỗi ngày. Nếu PoC không tính đến chi phí vận hành, doanh nghiệp sẽ phê duyệt một giải pháp mà mình không trả nổi để vận hành.
Vấn đề này đặc biệt nghiêm trọng với AI tạo sinh, bởi chi phí của mô hình ngôn ngữ lớn được tính theo số lượng token — mỗi lần gọi AI là một lần trả tiền. Một PoC chatbot có thể tốn rất ít khi chỉ có vài chục người dùng thử, nhưng khi triển khai cho hàng nghìn khách hàng mỗi ngày, chi phí API có thể lên đến hàng chục triệu đồng mỗi tháng. Nhiều doanh nghiệp chỉ phát hiện ra điều này sau khi đã đầu tư vào triển khai, và khi đó họ phải lựa chọn giữa việc trả một khoản chi phí vận hành cao hơn dự tính rất nhiều, hoặc dừng giải pháp và chấp nhận khoản đầu tư đã bỏ ra trở thành lãng phí. Một biến thể khác của sai lầm này là không tính chi phí con người: ai sẽ giám sát mô hình, ai sẽ xử lý khi mô hình sai, ai sẽ hỗ trợ người dùng, và những công việc đó tốn bao nhiêu giờ mỗi tuần. Nếu không tính những chi phí này, doanh nghiệp sẽ phê duyệt một giải pháp mà không có ai vận hành, và giải pháp sẽ dần suy giảm cho đến khi không còn ai dùng.
Dấu hiệu nhận biết: tài liệu PoC không có mục chi phí vận hành, hoặc chỉ có một dòng chung chung về chi phí; khi hỏi chi phí vận hành hàng tháng là bao nhiêu, đội dự án trả lời rằng sẽ tính sau; hoặc PoC được thử nghiệm với số lượng người dùng rất nhỏ, nên chi phí API trông rất thấp, nhưng không ai tính chi phí sẽ tăng như thế nào khi số lượng người dùng tăng lên gấp mười hoặc gấp một trăm lần.
Hậu quả: PoC có thể chứng minh được giá trị nhưng vẫn bị dừng lại vì không có ngân sách vận hành. Đây là một trong những kết cục đáng tiếc nhất của PoC AI: mọi người đều đồng ý rằng giải pháp có giá trị, nhưng không ai có ngân sách để vận hành nó, và giải pháp bị bỏ xó. Trong một số trường hợp, doanh nghiệp quyết định vận hành giải pháp mà không có ngân sách đầy đủ, và giải pháp dần suy giảm vì không được giám sát, không được tái huấn luyện, và không được hỗ trợ người dùng — cho đến khi không còn ai dùng nữa và mọi người kết luận rằng AI không hiệu quả.
Cách phòng tránh: Trước khi bắt đầu PoC, hãy lập một bảng chi phí vận hành dự kiến, bao gồm phí API hoặc phí bản quyền phần mềm, chi phí hạ tầng và lưu trữ, chi phí giám sát và bảo trì, chi phí hỗ trợ người dùng, và chi phí tái huấn luyện định kỳ. Hãy tính chi phí này ở ba mức quy mô: quy mô PoC, quy mô pilot, và quy mô triển khai đầy đủ, để lãnh đạo thấy chi phí sẽ tăng như thế nào khi mở rộng. Hãy so sánh chi phí vận hành với giá trị kinh tế mà giải pháp tạo ra: nếu chi phí vận hành lớn hơn giá trị tạo ra, PoC không nên được mở rộng, dù kết quả kỹ thuật có tốt đến đâu. Ngoài ra, hãy thỏa thuận ngân sách vận hành ngay từ khi phê duyệt PoC, chứ không phải đợi đến khi PoC kết thúc mới bắt đầu xin ngân sách — bởi khi PoC kết thúc, sự hào hứng đã giảm, và việc xin ngân sách trở nên khó khăn hơn nhiều.
Sai lầm 9: Không có người chịu trách nhiệm sau PoC — PoC thành công rồi bị bỏ rơi
Nhiều PoC thành công về mặt kỹ thuật nhưng vẫn chết sau khi kết thúc, vì không có ai chịu trách nhiệm đưa giải pháp vào vận hành và duy trì nó. Trong giai đoạn PoC, đội dự án chịu trách nhiệm: họ xây dựng mô hình, họ kiểm thử, họ báo cáo kết quả. Khi PoC kết thúc, đội dự án giải tán — các thành viên quay lại công việc thường ngày, hoặc chuyển sang dự án khác — và không ai nhận trách nhiệm tiếp theo. Giải pháp PoC trở thành một dự án mồ côi: không ai vận hành, không ai giám sát, không ai xử lý khi có sự cố, và không ai có ngân sách để duy trì. Sau vài tháng, giải pháp bị lãng quên, và khi ai đó hỏi về nó, mọi người nhìn nhau hoặc trả lời đội dự án — một đội đã không còn tồn tại.
Sai lầm này thường xuất phát từ việc nhầm lẫn vai trò trong PoC. Trong nhiều PoC, người chịu trách nhiệm chính là một người làm kỹ thuật, hoặc một người quản lý dự án tạm thời — những người không có thẩm quyền và không có động lực để đưa giải pháp vào vận hành lâu dài. Người cần chịu trách nhiệm sau PoC là một người khác: một giám đốc bộ phận sở hữu bài toán, người có ngân sách để vận hành giải pháp, có thẩm quyền thay đổi quy trình làm việc, và có động lực để giải pháp thành công vì nó ảnh hưởng trực tiếp đến kết quả của bộ phận mình. Nếu PoC không có người như vậy tham gia từ đầu, PoC sẽ không bao giờ đi vào vận hành, dù kết quả kỹ thuật có tốt đến đâu. Ngoài ra, sai lầm này còn xuất phát từ việc không có kế hoạch bàn giao: PoC kết thúc mà không có tài liệu về cách vận hành giải pháp, không có hướng dẫn cho người dùng, không có quy trình xử lý sự cố, và không có ai được đào tạo để tiếp quản. Khi đội dự án giải tán, mọi kiến thức về giải pháp cũng biến mất theo họ, và giải pháp trở thành một hệ thống không ai dám chạm vào — mọi người sợ rằng chỉ cần chạm vào là nó sẽ hỏng, và không ai biết cách sửa.
Dấu hiệu nhận biết: khi hỏi ai sẽ chịu trách nhiệm vận hành giải pháp sau PoC, mọi người nhìn nhau hoặc trả lời đội dự án; không có một chủ sở hữu sản phẩm nào được chỉ định cho giải pháp sau PoC; hoặc PoC không có tài liệu bàn giao nào: không có hướng dẫn vận hành, không có quy trình xử lý sự cố, và không có ai được đào tạo để tiếp quản.
Hậu quả: PoC thành công nhưng giải pháp bị bỏ rơi sau khi kết thúc, và khoản đầu tư vào PoC trở thành lãng phí. Tệ hơn, một giải pháp bị bỏ rơi có thể trở thành một rủi ro: nó vẫn chạy, vẫn được một vài người dùng, nhưng không ai giám sát, không ai cập nhật, và không ai chịu trách nhiệm khi nó sai. Doanh nghiệp có thể không nhận ra rủi ro này cho đến khi giải pháp gây ra một sự cố nghiêm trọng, và khi đó không còn ai biết cách xử lý.
Cách phòng tránh: Trước khi bắt đầu PoC, hãy chỉ định rõ ai sẽ là chủ sở hữu sản phẩm sau PoC: người đó là ai, họ có ngân sách để vận hành giải pháp hay không, họ có thẩm quyền thay đổi quy trình làm việc hay không, và họ sẽ dành bao nhiêu thời gian mỗi tuần cho giải pháp này. Hãy yêu cầu người đó tham gia vào PoC từ đầu, với vai trò người ra quyết định về việc mở rộng hay dừng lại. Ngoài ra, hãy yêu cầu đội dự án chuẩn bị tài liệu bàn giao ngay trong quá trình làm PoC, chứ không phải đợi đến khi PoC kết thúc: hướng dẫn vận hành, quy trình xử lý sự cố, danh sách những việc cần làm sau khi PoC kết thúc, và kế hoạch đào tạo cho người tiếp quản. Một PoC không có kế hoạch bàn giao là một PoC chưa hoàn thành, dù kết quả kỹ thuật có tốt đến đâu.
Sai lầm 10: Không có kế hoạch cho giai đoạn sau PoC — PoC thành công nhưng không biết đi đâu tiếp
Sai lầm cuối cùng, và cũng là sai lầm bao trùm lên tất cả những sai lầm khác, là PoC không có kế hoạch cho giai đoạn sau PoC. Nhiều PoC được thiết kế như một dự án độc lập, với ngày bắt đầu và ngày kết thúc, nhưng không có bất kỳ kế hoạch nào về điều gì sẽ xảy ra sau ngày kết thúc đó. Khi PoC thành công, không ai biết bước tiếp theo là gì: có mở rộng ngay không, có làm pilot trước không, ai sẽ chịu trách nhiệm mở rộng, ngân sách từ đâu, và thời gian biểu như thế nào. Khi PoC thất bại, cũng không ai biết bước tiếp theo là gì: có dừng hẳn không, có điều chỉnh rồi thử lại không, và bài học rút ra là gì. Một PoC không có kế hoạch cho giai đoạn sau là một PoC được thiết kế để kết thúc trong sự lúng túng, dù kết quả của nó có tốt hay xấu.
Không có kế hoạch cho giai đoạn sau PoC thường xuất phát từ việc coi PoC là đích đến thay vì là một bước đi. Đội dự án tập trung toàn bộ sự chú ý vào việc làm cho PoC thành công, mà không nghĩ đến việc PoC thành công rồi thì sao. Khi PoC thành công, sự hào hứng ban đầu nhanh chóng nhường chỗ cho những câu hỏi khó: ai sẽ vận hành giải pháp, ngân sách từ đâu, quy trình làm việc thay đổi như thế nào, và người dùng có sẵn sàng dùng giải pháp mỗi ngày hay không. Những câu hỏi này cần thời gian để trả lời, và trong thời gian đó, giải pháp PoC bị bỏ xó, đội dự án giải tán, và sự hào hứng tan biến. Khi doanh nghiệp cuối cùng cũng quyết định mở rộng, họ phát hiện ra rằng giải pháp PoC đã lỗi thời, dữ liệu đã thay đổi, và đội dự án đã không còn ai nhớ rõ cách giải pháp hoạt động. Một biến thể khác của sai lầm này là không có tiêu chí rõ ràng để quyết định mở rộng hay dừng lại: PoC kết thúc, mọi người nhìn vào kết quả, và không ai biết ngưỡng nào thì mở rộng, ngưỡng nào thì dừng. Kết quả là quyết định được đưa ra dựa trên cảm tính, hoặc dựa trên áp lực chính trị nội bộ, thay vì dựa trên bằng chứng. Một PoC không có tiêu chí quyết định rõ ràng sẽ bị kéo dài vô thời hạn, hoặc bị mở rộng dù kết quả chưa đủ tốt, hoặc bị dừng dù kết quả đã đủ tốt — và trong cả ba trường hợp, doanh nghiệp đều mất tiền.
Dấu hiệu nhận biết: tài liệu PoC không có mục nào về giai đoạn sau PoC; khi hỏi PoC thành công rồi thì làm gì tiếp, không ai trả lời được; hoặc khi hỏi tiêu chí nào thì mở rộng và tiêu chí nào thì dừng, đội dự án trả lời bằng những từ chung chung như nếu kết quả tốt thì mở rộng — mà không nói rõ tốt là bao nhiêu.
Hậu quả: PoC thành công nhưng giải pháp bị bỏ xó vì không có kế hoạch mở rộng; hoặc PoC bị kéo dài vô thời hạn vì không có tiêu chí dừng; hoặc PoC được mở rộng dù kết quả chưa đủ tốt, vì không ai dám nói dừng. Trong cả ba trường hợp, doanh nghiệp đều mất tiền và mất thời gian — và mất niềm tin vào AI, vì lãnh đạo kết luận rằng AI không mang lại kết quả, trong khi thực tế là PoC đã không được thiết kế để mang lại kết quả.
Cách phòng tránh: Trước khi bắt đầu PoC, hãy viết ra kế hoạch cho giai đoạn sau PoC, với ba kịch bản: nếu PoC thành công thì làm gì tiếp (pilot hay triển khai ngay, ai chịu trách nhiệm, ngân sách từ đâu, thời gian biểu như thế nào), nếu PoC thất bại thì làm gì tiếp (dừng hẳn hay điều chỉnh rồi thử lại, bài học rút ra là gì), và nếu PoC cho kết quả không rõ ràng thì làm gì tiếp (thu thập thêm dữ liệu gì, trong bao lâu, và ai là người quyết định). Hãy định nghĩa tiêu chí mở rộng và tiêu chí dừng bằng con số, cho tất cả các bên cùng ký xác nhận, và cam kết tuân thủ những tiêu chí đó khi PoC kết thúc. Một PoC có kế hoạch cho giai đoạn sau là một PoC được thiết kế để tạo ra quyết định — và đó chính là mục tiêu thật sự của PoC.
| Sai lầm | Dấu hiệu sớm | Cách phòng tránh cốt lõi |
|---|---|---|
| 1. Chọn sai bài toán | Không ai ký xác nhận bài toán đáng giải quyết | Yêu cầu chủ bài toán ký cam kết bằng văn bản |
| 2. Dữ liệu chưa sẵn sàng | PoC chạy trên dữ liệu mẫu, không phải dữ liệu thật | Chạy PoC trên dữ liệu thật từ hệ thống vận hành |
| 3. Không định nghĩa thành công | Không có tiêu chí thành công bằng con số | Định nghĩa đủ tốt bằng con số trước khi bắt đầu |
| 4. Không có người dùng cuối | Người dùng chỉ được mời vào cuối PoC | Mời người dùng tham gia từ tuần đầu tiên |
| 5. Đo sai cách | Không có đường cơ sở để so sánh | Đo đường cơ sở và đo cả ba lớp chỉ số |
| 6. Kiểm thử sai cách | Kết quả kiểm thử tốt một cách đáng ngờ | Tách dữ liệu kiểm thử, kiểm thử trên dữ liệu mới |
| 7. Không tính đến tích hợp | PoC chạy tách biệt với hệ thống hiện có | Chạy end-to-end một lần với dữ liệu thật |
| 8. Không tính chi phí vận hành | Tài liệu PoC không có mục chi phí vận hành | Lập bảng chi phí vận hành ở ba mức quy mô |
| 9. Không có người chịu trách nhiệm | Không có chủ sở hữu sản phẩm sau PoC | Chỉ định chủ sở hữu và chuẩn bị tài liệu bàn giao |
| 10. Không có kế hoạch sau PoC | Không ai biết PoC thành công rồi thì làm gì | Viết kế hoạch cho ba kịch bản trước khi bắt đầu |
Checklist đánh giá PoC trước khi quyết định mở rộng hay dừng lại
Khi PoC kết thúc, doanh nghiệp cần một quyết định rõ ràng: mở rộng, điều chỉnh rồi thử lại, hay dừng lại. Quyết định này không nên dựa trên cảm tính hay áp lực nội bộ, mà nên dựa trên một checklist có cấu trúc, bao quát ba nhóm câu hỏi: PoC có chứng minh được giá trị hay không, PoC có chứng minh được khả năng vận hành hay không, và doanh nghiệp có sẵn sàng để mở rộng hay không. Nếu PoC trả lời được cả ba nhóm câu hỏi một cách thuyết phục, doanh nghiệp nên mở rộng. Nếu PoC chỉ trả lời được một hoặc hai nhóm, doanh nghiệp nên điều chỉnh và thử lại, hoặc dừng lại và rút ra bài học.
Nhóm 1: PoC có chứng minh được giá trị không?
- PoC có giải quyết được bài toán kinh doanh đã định nghĩa từ đầu hay không, hay chỉ chứng minh được một khả năng kỹ thuật chung chung?
- Giá trị kinh tế của giải pháp có được đo lường bằng con số cụ thể hay không, và con số đó có vượt ngưỡng tối thiểu đã thỏa thuận từ đầu hay không?
- Kết quả PoC có được đo trên dữ liệu đại diện cho vận hành thật hay không, và có đường cơ sở để so sánh hay không?
- Người dùng cuối có xác nhận rằng giải pháp giúp họ làm việc tốt hơn hay không, hay chỉ có đội dự án nói như vậy?
Nhóm 2: PoC có chứng minh được khả năng vận hành không?
- Giải pháp có tích hợp được với hệ thống hiện có hay không, và đã có ít nhất một lần chạy end-to-end với dữ liệu thật hay chưa?
- Chi phí vận hành hàng tháng có được tính toán cụ thể hay không, và có nằm trong ngân sách của doanh nghiệp hay không?
- Quy trình làm việc mới có được người dùng chấp nhận hay không, và có kế hoạch đào tạo cho người dùng hay không?
- Mô hình có được kiểm thử trên những trường hợp khó và bất thường hay không, hay chỉ được kiểm thử trên những trường hợp dễ?
- Có kế hoạch giám sát và bảo trì mô hình sau khi triển khai hay không, và ai sẽ chịu trách nhiệm giám sát?
Nhóm 3: Doanh nghiệp có sẵn sàng để mở rộng không?
- Có ngân sách vận hành hàng tháng cho giải pháp hay không, và ngân sách đó đã được phê duyệt hay chưa?
- Có người chịu trách nhiệm vận hành giải pháp sau khi mở rộng hay không, và người đó đã được chỉ định hay chưa?
- Có kế hoạch đào tạo cho người dùng và kế hoạch quản lý thay đổi hay không?
- Có quy trình xử lý sự cố và kế hoạch giám sát mô hình hay không?
- Có kế hoạch cho giai đoạn sau mở rộng hay không, và tiêu chí nào thì tiếp tục đầu tư, tiêu chí nào thì dừng lại?
Cách dùng checklist: Hãy trả lời từng câu hỏi trong checklist bằng bằng chứng cụ thể, không phải bằng cảm tính. Với mỗi câu hỏi, hãy ghi lại bằng chứng: con số nào, tài liệu nào, ai là người xác nhận. Nếu một câu hỏi không trả lời được, hãy coi đó là một khoảng trống cần lấp đầy trước khi quyết định mở rộng. Một PoC trả lời được hầu hết các câu hỏi trong checklist là một PoC đã sẵn sàng để mở rộng; một PoC còn nhiều câu hỏi chưa trả lời được là một PoC cần thêm thời gian, hoặc cần được dừng lại và rút ra bài học.
Khi nào nên dừng PoC? Dừng PoC không phải là thất bại
Một trong những quyết định khó khăn nhất trong quản lý PoC AI là quyết định dừng PoC. Nhiều doanh nghiệp tiếp tục đầu tư vào một PoC đã rõ ràng là không hiệu quả, vì họ đã bỏ ra nhiều thời gian và tiền bạc, vì họ sợ bị coi là thất bại, hoặc vì họ hy vọng rằng chỉ cần thêm một chút thời gian nữa là PoC sẽ thành công. Đây là một sai lầm về mặt tâm lý — hiệu ứng chi phí chìm — và nó khiến doanh nghiệp lãng phí thêm nhiều nguồn lực vào một dự án không có tương lai. Dừng PoC đúng lúc không phải là thất bại; đó là một quyết định quản lý tốt, và nó tiết kiệm cho doanh nghiệp nhiều hơn là tiếp tục đầu tư vào một PoC không hiệu quả.
Doanh nghiệp nên dừng PoC khi một trong năm dấu hiệu sau xuất hiện. Thứ nhất, khi PoC đã chứng minh được rằng giải pháp không tạo ra giá trị kinh tế đủ lớn, dù kết quả kỹ thuật có tốt đến đâu. Thứ hai, khi dữ liệu của doanh nghiệp không đủ tốt để vận hành giải pháp, và việc cải thiện dữ liệu sẽ tốn nhiều chi phí hơn giá trị mà giải pháp mang lại. Thứ ba, khi người dùng cuối từ chối sử dụng giải pháp, dù đã được đào tạo và hỗ trợ đầy đủ. Thứ tư, khi chi phí vận hành vượt quá giá trị kinh tế mà giải pháp tạo ra, và không có cách nào để giảm chi phí xuống mức chấp nhận được. Thứ năm, khi bài toán kinh doanh đã thay đổi trong quá trình làm PoC, và giải pháp không còn giải quyết bài toán hiện tại của doanh nghiệp nữa. Trong cả năm trường hợp, việc dừng PoC là quyết định đúng đắn, và doanh nghiệp nên dừng càng sớm càng tốt, khi đã có đủ bằng chứng để kết luận.
Khi dừng PoC, doanh nghiệp nên làm ba việc. Thứ nhất, ghi lại bài học: PoC đã chứng minh được điều gì, bài toán nào không nên giải quyết bằng AI, dữ liệu nào chưa sẵn sàng, và những sai lầm nào đã mắc phải. Thứ hai, chia sẻ bài học với toàn bộ tổ chức, để những đội ngũ khác không lặp lại những sai lầm tương tự. Thứ ba, giữ lại những gì có giá trị: dữ liệu đã được làm sạch, quy trình đánh giá đã được xây dựng, những hiểu biết về bài toán và về người dùng — những thứ này vẫn có giá trị cho những dự án sau, dù PoC hiện tại đã dừng. Một tổ chức biết dừng PoC đúng lúc và rút ra bài học từ mỗi PoC sẽ làm PoC tốt hơn theo thời gian, so với một tổ chức cố gắng cứu mọi PoC bằng mọi giá và không bao giờ học được gì từ thất bại.
Kết luận: PoC AI thành công là PoC trả lời được câu hỏi có nên đầu tư tiếp hay không bằng bằng chứng
Mười sai lầm trong bài viết này có một điểm chung: tất cả đều khiến PoC đánh mất liên hệ với giá trị kinh doanh thật. PoC chọn sai bài toán, PoC chạy trên dữ liệu không đại diện, PoC không định nghĩa thành công, PoC không có người dùng tham gia, PoC đo sai cách, PoC kiểm thử sai cách, PoC không tính đến tích hợp, PoC không tính chi phí vận hành, PoC không có người chịu trách nhiệm, và PoC không có kế hoạch cho giai đoạn sau — mỗi sai lầm đều là một cách mà PoC trở thành một dự án kỹ thuật tách biệt với doanh nghiệp, thay vì là một thử nghiệm kinh doanh có mục đích rõ ràng. Cách phòng tránh chung cho cả mười sai lầm là giữ PoC gắn chặt với bài toán kinh doanh thật, với dữ liệu thật, với người dùng thật, và với quyết định đầu tư thật đang chờ kết quả PoC.
Doanh nghiệp không cần một PoC hoàn hảo; doanh nghiệp cần một PoC trung thực. Một PoC trung thực là một PoC đo lường bằng con số, kiểm thử trên dữ liệu thật, lắng nghe người dùng cuối, tính toán đầy đủ chi phí vận hành, và sẵn sàng kết luận không nên đầu tư nếu bằng chứng cho thấy như vậy. Một PoC như vậy, dù kết luận là mở rộng hay dừng lại, đều là một PoC thành công — vì nó đã trả lời được câu hỏi mà nó được tạo ra để trả lời, bằng bằng chứng chứ không phải bằng cảm tính. Và một doanh nghiệp làm PoC như vậy nhiều lần sẽ ngày càng giỏi hơn trong việc chọn bài toán, đánh giá dữ liệu, đo lường giá trị và đưa AI vào vận hành — đó mới là năng lực AI thật sự, chứ không phải số lượng PoC đã làm được.
Nếu doanh nghiệp của bạn đang chuẩn bị làm PoC AI, hoặc đang có một PoC AI gặp khó khăn và không biết có nên tiếp tục hay dừng lại, ADC sẵn sàng đồng hành cùng bạn. Liên hệ ADC qua hotline 0939 936 168 hoặc email info@adcvietnam.net để được tư vấn thiết kế PoC AI, đánh giá dữ liệu và tiêu chí thành công, hoặc đánh giá độc lập một PoC đang triển khai trước khi quyết định đầu tư tiếp.
Câu hỏi thường gặp (FAQs)
PoC AI thường kéo dài bao lâu?
Một PoC AI thường kéo dài từ 4 đến 12 tuần, tùy thuộc vào độ phức tạp của bài toán và mức độ sẵn sàng của dữ liệu. PoC ngắn hơn 4 tuần thường không đủ thời gian để thử nghiệm nghiêm túc trên dữ liệu thật với người dùng thật, trong khi PoC dài hơn 12 tuần thường đã biến thành một dự án nhỏ chứ không còn là một thử nghiệm có giới hạn nữa. Doanh nghiệp nên thỏa thuận thời gian PoC ngay từ đầu, với ngày kết thúc cụ thể và tiêu chí đánh giá rõ ràng, và không nên kéo dài PoC vô thời hạn khi kết quả chưa rõ ràng — nếu sau 12 tuần mà PoC vẫn chưa trả lời được câu hỏi có nên đầu tư tiếp hay không, doanh nghiệp nên dừng lại và xem xét lại thiết kế PoC.
PoC AI thất bại có phải là do mô hình AI không đủ tốt không?
Thường thì không. Phần lớn PoC AI thất bại không phải vì mô hình không đủ tốt, mà vì những lý do khác: chọn sai bài toán, dữ liệu chưa sẵn sàng, không định nghĩa rõ thành công, không có người dùng tham gia, đo sai cách, kiểm thử sai cách, không tính đến tích hợp, không tính chi phí vận hành, không có người chịu trách nhiệm, hoặc không có kế hoạch cho giai đoạn sau PoC. Mô hình AI hiện nay, đặc biệt là mô hình ngôn ngữ lớn, đã đủ tốt cho nhiều bài toán kinh doanh phổ biến. Điều khiến PoC thất bại thường không liên quan đến độ thông minh của mô hình, mà liên quan đến cách dự án được thiết kế, đo lường và vận hành.
Chi phí làm một PoC AI là bao nhiêu?
Chi phí PoC AI phụ thuộc vào nhiều yếu tố: độ phức tạp của bài toán, mức độ sẵn sàng của dữ liệu, số lượng người dùng tham gia, và thời gian PoC kéo dài. Chi phí PoC thường chỉ bao gồm thời gian của đội dự án và một khoản phí dùng thử công cụ AI, và thường thấp hơn nhiều so với chi phí triển khai đầy đủ. Tuy nhiên, doanh nghiệp không nên chỉ nhìn vào chi phí PoC mà nên nhìn vào tổng chi phí: chi phí PoC cộng với chi phí tích hợp, chi phí vận hành hàng tháng, chi phí đào tạo người dùng và chi phí bảo trì mô hình. Một PoC rẻ nhưng có chi phí vận hành cao có thể đắt hơn nhiều so với một PoC đắt hơn một chút nhưng có chi phí vận hành thấp.
Có nên làm nhiều PoC AI cùng lúc không?
Doanh nghiệp có thể làm nhiều PoC cùng lúc, nhưng chỉ nên làm vậy khi có đủ nguồn lực và khi các PoC không cạnh tranh nhau về dữ liệu, nhân sự và sự chú ý của lãnh đạo. Làm nhiều PoC cùng lúc có ưu điểm là doanh nghiệp có thể so sánh kết quả và chọn ra PoC có giá trị nhất để mở rộng, nhưng cũng có nhược điểm là mỗi PoC nhận được ít nguồn lực hơn, và đội ngũ có thể bị phân tán. Một cách tiếp cận thực tế là làm một PoC trước, rút ra bài học, rồi mới làm PoC tiếp theo — cách này giúp doanh nghiệp học hỏi từ mỗi PoC và làm PoC tốt hơn theo thời gian, thay vì làm nhiều PoC cùng lúc và mắc cùng một sai lầm ở tất cả các PoC.
Làm thế nào để chọn đúng bài toán cho PoC AI?
Để chọn đúng bài toán, doanh nghiệp nên bắt đầu từ những vấn đề kinh doanh thật: bài toán nào đang gây ra thiệt hại lớn nhất, bài toán nào có người chịu trách nhiệm rõ ràng, và bài toán nào có dữ liệu để thử nghiệm. Hãy viết ra một trang mô tả bài toán theo cấu trúc: bài toán là gì, ai đang gặp bài toán đó, bài toán gây ra thiệt hại bao nhiêu tiền hoặc bao nhiêu giờ mỗi tháng, và giá trị kinh tế nếu giải quyết được là bao nhiêu. Sau đó, yêu cầu giám đốc bộ phận sở hữu bài toán ký xác nhận vào trang mô tả đó. Nếu không tìm được một chủ bài toán sẵn sàng ký, doanh nghiệp nên coi đó là tín hiệu cảnh báo và dừng lại để tìm bài toán khác.
PoC AI có cần dữ liệu lớn không?
PoC AI không nhất thiết cần dữ liệu lớn, mà cần dữ liệu đủ tốt và đại diện cho vận hành thật. Một PoC với dữ liệu nhỏ nhưng chất lượng cao, đầy đủ và đại diện có thể cho kết quả đáng tin cậy hơn một PoC với dữ liệu lớn nhưng thiếu, sai và không đại diện. Điều quan trọng là dữ liệu PoC phải được lấy trực tiếp từ hệ thống vận hành, với cùng quy trình làm sạch mà doanh nghiệp sẽ dùng khi vận hành thật, và phải bao gồm cả những trường hợp khó và bất thường. Doanh nghiệp nên dành ít nhất hai tuần để đánh giá dữ liệu trước khi bắt đầu PoC, và nếu dữ liệu chưa đủ tốt, hãy coi đó là kết quả của PoC: doanh nghiệp cần đầu tư vào dữ liệu trước khi đầu tư vào AI.
Khi nào nên mở rộng PoC AI thành dự án triển khai đầy đủ?
Doanh nghiệp nên mở rộng PoC khi PoC trả lời được cả ba nhóm câu hỏi trong checklist: PoC chứng minh được giá trị kinh tế bằng con số cụ thể, PoC chứng minh được khả năng vận hành và tích hợp với hệ thống hiện có, và doanh nghiệp có sẵn sàng để mở rộng — có ngân sách vận hành, có người chịu trách nhiệm, có kế hoạch đào tạo và có quy trình xử lý sự cố. Nếu PoC chỉ trả lời được một hoặc hai nhóm câu hỏi, doanh nghiệp nên điều chỉnh và thử lại, hoặc dừng lại và rút ra bài học. Việc mở rộng một PoC chưa sẵn sàng sẽ tốn nhiều chi phí hơn và có nguy cơ thất bại cao hơn so với việc dành thêm thời gian để chuẩn bị kỹ.
Làm thế nào để PoC AI không bị chết sau khi kết thúc?
Để PoC AI không bị chết sau khi kết thúc, doanh nghiệp cần làm ba việc trước khi bắt đầu PoC. Thứ nhất, chỉ định rõ ai sẽ là chủ sở hữu sản phẩm sau PoC, và yêu cầu người đó tham gia vào PoC từ đầu. Thứ hai, viết ra kế hoạch cho giai đoạn sau PoC, với ba kịch bản: nếu PoC thành công thì làm gì tiếp, nếu PoC thất bại thì làm gì tiếp, và nếu PoC cho kết quả không rõ ràng thì làm gì tiếp. Thứ ba, yêu cầu đội dự án chuẩn bị tài liệu bàn giao ngay trong quá trình làm PoC: hướng dẫn vận hành, quy trình xử lý sự cố, và kế hoạch đào tạo cho người tiếp quản. Một PoC có chủ sở hữu rõ ràng, có kế hoạch cho giai đoạn sau, và có tài liệu bàn giao đầy đủ sẽ không bị chết sau khi kết thúc, dù kết quả của nó là mở rộng hay dừng lại.
