Sự sẵn sàng cho AI bắt đầu từ dữ liệu sản phẩm đáng tin cậy

Các nhà sản xuất đang đầu tư mạnh vào AI, các sáng kiến về chuỗi dữ liệu số, tự động hóa và hiện đại hóa doanh nghiệp nhằm nâng cao năng suất và chất lượng ra quyết định. Phần lớn các cuộc thảo luận tập trung vào mô hình AI, hạ tầng và tích hợp. Tuy nhiên, nhiều tổ chức đang bỏ qua một điều kiện tiên quyết cơ bản cho những nỗ lực này: sự tin cậy vào dữ liệu sản phẩm nền tảng và các quy tắc kinh doanh chi phối những quyết định trong hoạt động vận hành.

Thách thức không chỉ nằm ở việc kết nối các hệ thống mà còn ở việc bảo đảm các định nghĩa sản phẩm, logic cấu hình và quy tắc kinh doanh được truyền giữa các hệ thống luôn chính xác. Sự sẵn sàng cho AI bắt đầu từ niềm tin vào dữ liệu sản phẩm cấp doanh nghiệp. Chuyển đổi số không chỉ là kết nối các hệ thống; đó còn là bảo toàn ý nghĩa và độ chính xác của thông tin lưu chuyển giữa chúng.

Khi các công ty hiện đại hóa hệ thống doanh nghiệp và kết nối các nền tảng quản lý vòng đời sản phẩm (PLM), hoạch định nguồn lực doanh nghiệp (ERP), cấu hình, định giá và báo giá (CPQ) cùng nền tảng dịch vụ, những điểm thiếu nhất quán trong logic cấu hình có thể âm thầm làm suy giảm độ chính xác của các quy trình ở khâu tiếp theo và hiệu quả của các đề xuất do AI đưa ra. Nếu không có logic cấu hình đáng tin cậy, AI sẽ khiến sai sót lan nhanh hơn thay vì giúp cải thiện quyết định.

Vì sao cấu hình sản phẩm là nền tảng cốt lõi thường bị khuất lấp

Các nhà sản xuất ngày nay ngày càng phụ thuộc vào một hệ sinh thái kết nối gồm PLM, ERP, CPQ, sản xuất và dịch vụ. Cấu hình sản phẩm đóng vai trò như mô liên kết, chuyển hóa ý đồ kỹ thuật thành các yêu cầu về sản xuất, bán hàng, định giá và dịch vụ.

Mỗi hệ thống nhìn nhận sản phẩm theo một cách khác nhau: PLM cần thông tin kỹ thuật và thiết kế, bộ phận sản xuất cần biết những gì có thể chế tạo, còn CPQ cần các quy tắc bán hàng và thị trường. Cấu hình là yếu tố kết nối những góc nhìn đó. Khi logic nền tảng thay đổi hoặc trở nên thiếu nhất quán, chuỗi dữ liệu số sẽ đứt gãy, bất kể các hệ thống được tích hợp tốt đến đâu.

Quy tắc cũ tạo ra rủi ro khó nhận thấy

Các mô hình cấu hình sản phẩm thường tích lũy kiến thức qua nhiều thập kỷ, được bổ sung từng lớp theo thời gian: yêu cầu pháp lý, giới hạn trong sản xuất, ngoại lệ theo từng thị trường và logic định giá. Những người xây dựng các mô hình này ban đầu thường đã rời công ty, khiến các tổ chức phải tiếp tục sử dụng những quy tắc mà giờ đây không ai còn hiểu đầy đủ.

Các dự án hiện đại hóa doanh nghiệp, chẳng hạn như quá trình chuyển đổi sang SAP S/4HANA, thường ưu tiên ứng dụng, hạ tầng và mã tùy chỉnh, trong khi xem logic cấu hình là thứ yếu. Điều này tạo ra một rủi ro bị bỏ sót: hệ thống có thể được chuyển đổi thành công nhưng cách thức cấu hình lại thay đổi một cách tinh vi, khó phát hiện bằng các phương pháp kiểm thử truyền thống.

Quá trình chuyển đổi sang S/4HANA cho thấy rõ vấn đề này: một công cụ cấu hình mới có thể diễn giải các quy tắc đã tồn tại lâu năm theo cách khác, dù cú pháp không thay đổi. Cách áp dụng giá trị mặc định, thứ tự đánh giá các ràng buộc và cách xử lý xung đột giữa các quy tắc đều có thể làm thay đổi những tổ hợp mà mô hình chấp nhận, ngay cả khi không viết lại một dòng nào trong chính các quy tắc đó.

Đây không chỉ là chuyện gây nhầm lẫn; logic cấu hình sai sẽ trở thành vấn đề kinh doanh. Có hai kiểu thất bại, và cả hai đều gây tốn kém:

• Cấu hình cho phép công ty bán một sản phẩm mà trên thực tế họ không thể sản xuất, dẫn đến phải làm lại, không thực hiện được cam kết và tổn hại các mối quan hệ với khách hàng.
• Cấu hình nhầm lẫn khiến công ty không thể bán một sản phẩm mà họ hoàn toàn có khả năng sản xuất, dẫn đến mất doanh thu và có thể cả lợi thế cạnh tranh.

Kiểu thất bại thứ nhất sớm muộn cũng bộc lộ ngay tại nhà máy. Kiểu thứ hai diễn ra âm thầm; sổ đơn hàng không ghi nhận giao dịch nào mà công cụ cấu hình chưa từng cho phép.

Kiểm chứng đang trở thành năng lực chiến lược

Việc xác thực chuyển đổi theo cách truyền thống phụ thuộc nhiều vào kiểm thử thủ công và kiểm tra ngẫu nhiên, vốn không thể đánh giá một cách thực tế số lượng khổng lồ các tổ hợp sản phẩm có thể có. Kiểm chứng cấu hình chuyển trọng tâm từ câu hỏi liệu dữ liệu có được chuyển thành công hay không sang việc liệu mục đích kinh doanh có còn nguyên vẹn hay không.

Tôi từng chứng kiến các nhà sản xuất bố trí cả nhóm nhân sự chỉ để xác nhận rằng mô hình sau khi chuyển đổi vẫn tạo ra đúng những cấu hình hợp lệ như trước và vẫn từ chối đúng những cấu hình không hợp lệ như trước, đơn giản vì họ không có cách nào khác để biết. Đây là công việc tỉ mỉ, tốn kém và mất thời gian; ngay cả như vậy, họ cũng chỉ kiểm tra được một phần vấn đề.

Cần nhìn chính xác quy mô của vấn đề. Một mô hình có 30 biến, mỗi biến có năm lựa chọn, cho phép khoảng 10²¹ tổ hợp—nhiều hơn rất nhiều so với số hạt cát ước tính trên Trái Đất; các mô hình công nghiệp thực tế còn lớn hơn đáng kể. Dù có bao nhiêu người lần lượt nhấp qua giao diện người dùng thì cũng không thể bao quát hết không gian đó; phép tính không cho phép điều ấy.

Đó là lý do các phương pháp hình thức đóng vai trò quan trọng. Thay vì lấy mẫu các tổ hợp, có thể biên dịch mô hình cấu hình thành một dạng logic chuẩn tắc: biểu diễn toán học cô đọng của mọi tổ hợp hợp lệ được các quy tắc cho phép. Có thể so sánh trực tiếp hai mô hình được biên dịch theo cách này. Hoặc chúng mô tả chính xác cùng một tập hợp sản phẩm hợp lệ, hoặc phép so sánh chỉ rõ chính xác những điểm khác biệt, kèm các ví dụ cụ thể về những tổ hợp được mô hình này chấp nhận nhưng bị mô hình kia từ chối. Cùng một biểu diễn đó biến hành vi khi chạy thành thao tác tra cứu thay vì tìm kiếm, nhờ vậy công cụ cấu hình chỉ hiển thị các tùy chọn hợp lệ và không bao giờ đẩy người dùng vào ngõ cụt. Hóa ra, xác minh và bảo đảm tính đúng đắn khi chạy là cùng một năng lực, được tiếp cận từ hai hướng khác nhau.

Các tổ chức ngày càng cần kiểu so sánh hình thức này trước khi áp dụng AI hoặc tự động hóa cho các quy tắc sản phẩm. Mục tiêu không chỉ là giảm rủi ro khi chuyển đổi, mà còn duy trì hoạt động liên tục trong các khâu kỹ thuật, sản xuất, bán hàng và dịch vụ, đồng thời có thể kiểm thử, gỡ lỗi và xác minh mô hình cấu hình trước khi phát hành thay vì sau đó.

AI nên hoạt động trên nền tảng của một công cụ xử lý xác định, chứ không thay thế công cụ đó

Không điều gì trong số này đòi hỏi AI phải thay thế công cụ cấu hình. Mô hình bền vững hơn là điều ngược lại: AI đóng vai trò trung gian giữa người dùng và một công cụ cấu hình chặt chẽ, mang đến trải nghiệm bán hàng có hướng dẫn hoặc đề xuất tự nhiên hơn, trong khi các quy tắc nền tảng vẫn mang tính xác định. Mô hình ngôn ngữ diễn giải yêu cầu của khách hàng; công cụ cấu hình quyết định những gì thực sự có thể chế tạo. Sự phân công này giúp phần quy trình cần được chứng minh là đúng nằm ngoài tầm kiểm soát của một hệ thống vốn được thiết kế để hoạt động theo xác suất.

Dữ liệu đáng tin cậy là yếu tố quyết định thành công của các chương trình AI

AI chỉ có thể đưa ra đề xuất đáng tin cậy ở mức độ tương ứng với độ tin cậy của tri thức sản phẩm được cung cấp. Dữ liệu cấu hình chưa được xác minh khiến AI lan truyền sai sót trên quy mô toàn doanh nghiệp, làm suy giảm chất lượng hướng dẫn bán hàng, các quyết định sản xuất và những cam kết với khách hàng.

Các nhà sản xuất nên xem việc xác minh dữ liệu là điều kiện tiên quyết để triển khai AI, cũng như kiểm thử phần mềm đã trở thành điều kiện tiên quyết cho phát triển ứng dụng. Khi quá trình chuyển đổi số tiếp diễn, lợi thế cạnh tranh sẽ ngày càng đến từ việc triển khai AI trên nền tảng tri thức sản phẩm đáng tin cậy, chứ không phải từ việc triển khai AI trước tiên.