Quy trình IoT PoC 2026 – quyết định điều kiện đánh giá đầu ra trước khi bắt đầu

Quy trình IoT PoC 2026 – quyết định điều kiện đánh giá đầu ra trước khi bắt đầu

Điều đầu tiên khiến người phụ trách tại nhà máy vấp phải khi bắt đầu tìm hiểu về “quy trình IoT PoC” không phải là việc chọn công nghệ. Mã cảm biến, phương thức truyền thông hay lựa chọn nền tảng đám mây đều có câu trả lời nếu chịu khó tra cứu. Điểm vấp nằm ở phía trước đó, ở đúng một chỗ duy nhất: không ai viết ra giấy câu trả lời cho câu hỏi “khi PoC này kết thúc, dựa vào cái gì để quyết định triển khai chính thức”.

Khi tư vấn IoT cho các nhà máy Nhật Bản tại Thái Lan, câu “trước mắt cứ thử ở quy mô nhỏ đã” gần như luôn xuất hiện. Về hướng đi thì đó là lựa chọn đúng. Nhưng vế câu lẽ ra phải nối tiếp sau chữ “thử ở quy mô nhỏ” lại bị thiếu. Thử cái gì, đo bằng con số nào, xác nhận xong trước thời hạn nào, và kết quả ra sao thì mới đi tiếp. Những PoC bắt đầu gắn cảm biến khi chỗ này còn để trống thì phần lớn kết thúc bằng câu “chúng tôi đã lấy được dữ liệu”. Việc lấy được dữ liệu là sự thật, nên không ai gọi đó là thất bại. Nhưng nó cũng không dẫn tới triển khai chính thức. Khi tình trạng này lặp lại nhiều lần, thứ còn đọng lại ở hiện trường chỉ là bầu không khí “lại chuyện IoT nữa à”.

Lập trường của bài viết này rất rõ ràng. Nguyên nhân chính khiến PoC không dẫn tới triển khai chính thức không phải là thiếu công nghệ, mà là việc chưa xác định bằng con số các tiêu chí đánh giá triển khai chính thức, tức KPI, thời hạn và hạn mức ngân sách, trước khi PoC bắt đầu. Dưới đây, sau khi sắp xếp lại các lý do khiến PoC bị đình trệ, bài viết sẽ giải thích cụ thể theo trình tự cách khoanh vùng thiết bị mục tiêu, thứ tự thiết kế dữ liệu, cách viết điều kiện đánh giá, cũng như phán quyết chuyển sang triển khai chính thức và thời điểm sử dụng ưu đãi BOI của Thái Lan. Tiêu chí lựa chọn công nghệ và cơ cấu chi phí không được đào sâu ở đây mà nhường lại cho các bài viết đã có.

IoT PoC là gì – ba điều cần kiểm chứng khi khởi động IoT quy mô nhỏ tại nhà máy

PoC là viết tắt của Proof of Concept, tiếng Việt thường dịch là kiểm chứng khái niệm. PoC trong lĩnh vực IoT nhà máy là công đoạn lắp đặt thiết bị thật trong một phạm vi giới hạn để thu dữ liệu, nhằm xác nhận cách làm đó có thành lập được tại hiện trường của chính công ty mình hay không, trước khi đầu tư quy mô lớn.

Điều quan trọng ở đây là PoC không phải nơi để kiểm tra “công nghệ có chạy được hay không”. Việc cảm biến xuất ra giá trị và giá trị đó tới được đám mây ngày nay đã đạt tới mức đương nhiên. Ở phòng demo của nhà sản xuất thì chắc chắn chạy. Nếu có lý do khiến nó không chạy, lý do đó nằm ở điều kiện riêng của nhà máy bạn, ví dụ bề mặt lắp đặt của thiết bị cũ, môi trường sóng vô tuyến đầy kim loại, độ ẩm mùa mưa, thời điểm giao ca. PoC chính là nơi để phơi bày những điều kiện riêng đó.

Những gì cần kiểm chứng trong PoC IoT nhà máy có thể quy về ba điểm sau.

Phần lớn PoC chỉ kiểm chứng điểm thứ nhất là khả năng thu thập rồi kết thúc. Báo cáo ghi “đã thu thập dữ liệu thành công”, đính kèm vài biểu đồ, và dừng lại ở đó. Vì điểm thứ hai và thứ ba ngay từ đầu đã không nằm trong danh mục kiểm chứng, nên đó là kết cục tất yếu. Thiết kế PoC không gì khác chính là quyết định sẽ kiểm chứng ba điểm này vào tuần thứ mấy và bằng cách nào.

Ngoài ra, cụm từ khởi động IoT quy mô nhỏ được dùng trong bối cảnh gần như trùng với PoC, nhưng nghiêm ngặt mà nói thì có khác biệt. Khởi động quy mô nhỏ chỉ cách thức đầu tư “bắt đầu nhỏ rồi mở rộng dần theo giai đoạn”, còn PoC chỉ hoạt động kiểm chứng “để phán quyết có nên đầu tư quy mô lớn hay không”. Cũng có trường hợp thiết bị đưa vào theo kiểu khởi động nhỏ lớn dần thành vận hành chính thức, khi đó ranh giới giữa PoC và triển khai chính thức trở nên mờ nhạt. Trên thực tế công việc, giữ cấu hình sao cho thiết bị của PoC vẫn dùng tiếp được trong vận hành chính thức sẽ giảm được việc phải làm lại sau khi có phán quyết.

Bốn lý do khiến PoC không tiến tới triển khai chính thức

Về cấu trúc khiến PoC rơi vào “vòng lặp vô tận”, Hitachi Solutions đã hệ thống hóa trong tài liệu về cách tiến hành dự án IoT. Các yếu tố được nêu ở đó không mang tính kỹ thuật, mà đều liên quan tới ra quyết định và tổ chức.

Lý do 1 – mức độ nghiêm túc của ban lãnh đạo chưa đủ. Đây là trường hợp PoC khởi động từ một chỉ đạo mơ hồ ở mức “cứ thử xem sao”, không đi kèm kế hoạch kinh doanh hay thời hạn. Phía chỉ đạo cho rằng “tôi chỉ nói là thử xem thôi”, còn hiện trường tiếp nhận rằng “đây là chỉ đạo của ban lãnh đạo”. Độ lệch nhận thức này sẽ lộ ra đúng lúc họp phán quyết.

Lý do 2 – thành quả và thời hạn không được định nghĩa. Tài liệu chỉ ra rằng có nhiều trường hợp khi bị hỏi “bao giờ đưa vào thực dụng” thì trả lời “chưa có kế hoạch cụ thể”. Dự án không có thời hạn sẽ bị đẩy lùi lại theo thứ tự mức độ ưu tiên thấp. Người phụ trách ở nhà máy vốn đã gánh công việc chính, nếu không có thời hạn thì PoC luôn rơi về phía bị hoãn.

Lý do 3 – trạng thái “không phải thất bại nhưng cũng không thể gọi là thành công” kéo dài. Dữ liệu vẫn thu được, màn hình vẫn chạy, nhưng chuyện triển khai chính thức thì không ai nhắc tới. Trạng thái lơ lửng này kéo dài sẽ làm động lực của thành viên dự án đi xuống. Lần sau khi có chuyện tương tự, trong nội bộ sẽ không còn ai đứng ra nhận.

Lý do 4 – PoC biến thành mục đích học hỏi và kết thúc ở việc bắt chước tiền lệ. PoC bắt đầu bằng lý do “công ty khác cũng làm” sẽ kết thúc ở việc đồ lại cấu hình của công ty khác. Bởi vì cấu hình thiết bị của mình, tổn thất khi dừng máy của mình, cách bố trí nhân sự tại hiện trường của mình đều khác với công ty khác, vậy mà những khác biệt đó lại không được đưa vào danh mục kiểm chứng.

Cũng tài liệu đó nêu ra các điều kiện để đi tới thành công, gồm việc ban lãnh đạo có mức độ nghiêm túc đủ để đòi hỏi kế hoạch kinh doanh với câu hỏi “kinh doanh IoT này kiếm được bao nhiêu tiền”, việc lồng ghép điểm khác biệt so với dịch vụ hiện có, và việc ý thức về góc nhìn của khách hàng. Nếu chuyển sang bối cảnh dự án cải tiến nội bộ nhà máy, ranh giới phân định nằm ở chỗ có tạo được trạng thái mà chính ban lãnh đạo đặt câu hỏi “khoản đầu tư này giảm được bao nhiêu tiền tổn thất mỗi năm” hay không. Nếu chỉ là người phụ trách một mình làm tài liệu rồi ban lãnh đạo lặng lẽ nhận, câu hỏi đó sẽ không bao giờ phát sinh.

Bảy điểm vấp xảy ra trước cả công nghệ – thực trạng bài toán IoT của ngành sản xuất

Bên cạnh câu chuyện ra quyết định, cũng cần nắm các mẫu thất bại lặp đi lặp lại ở mức thực thi. Những nguyên nhân sau đây thường được nêu ra khi nói về thất bại trong triển khai IoT.

Cột bên phải của bảng này toàn là những việc có thể quyết trước khi PoC bắt đầu, hoặc trong tuần đầu tiên. Nói cách khác, đây là danh sách các hạng mục sẽ trở nên quá muộn nếu để tới giữa hoặc sau khi PoC kết thúc. Ví dụ “phải làm lại khi mở rộng chính thức” đã được định đoạt ngay tại thời điểm chọn cấu hình PoC. Cấu hình chỉ cần chạy được một máy và cấu hình vẫn thành lập khi mở rộng lên vài chục máy sẽ khác nhau cả ở gateway được chọn lẫn cách lưu trữ dữ liệu.

Tại các nhà máy Nhật Bản ở Thái Lan, còn thêm một yếu tố nữa là “thay đổi người phụ trách”. Vị trí của nhân sự biệt phái thay đổi sau vài năm, kỹ sư tuyển tại chỗ cũng chuyển việc. Nếu nội dung cài đặt PoC chỉ nằm trong máy tính cá nhân và trí nhớ của một người mà PoC lại kéo dài một năm, thì người phụ trách sẽ thay đổi trước khi tới được phán quyết, và người kế nhiệm phải điều tra lại từ đầu. Việc chia PoC thành các khoảng thời gian ngắn tự nó đã là một biện pháp chống phụ thuộc cá nhân.

Bước 1 trong quy trình triển khai IoT PoC – thu hẹp xuống còn một dây chuyền hoặc một máy

Nguyên tắc khoanh hẹp đối tượng PoC được khuyến nghị rộng rãi. Trong triển khai IoT, việc thực hiện PoC giới hạn ở một dây chuyền sản xuất hoặc một thiết bị, và bắt đầu nhỏ bằng thiết bị IoT phổ thông cùng cảm biến gắn thêm để kìm chi phí đầu tư ban đầu, được xem là hữu hiệu. Trong lĩnh vực bảo trì dự đoán, cũng có quan điểm cho rằng IoT nhà máy nên bắt đầu từ “một chiếc bơm”.

Vấn đề là chọn máy nào. Nếu quyết định dựa trên tiêu chí “thiết bị dễ lắp đặt”, thì dù lấy được dữ liệu cũng không ra hiệu quả, và không thể kiểm chứng khả năng sinh lời. Hãy lựa chọn theo bốn trục sau, và nếu không có thiết bị nào thỏa mãn toàn bộ thì ưu tiên hai trục đầu.

Không nhiều tài liệu đưa trục thứ tư vào điều kiện lựa chọn, nhưng trên thực tế đây lại là trục có tác dụng lớn nhất. Cảm biến sẽ can thiệp vào luồng thao tác của hiện trường ngay từ khoảnh khắc được lắp đặt. Những va chạm nhỏ như dây điện vướng víu, vướng vào lúc vệ sinh, chắc chắn sẽ xảy ra. Khi đó, việc ở hiện trường có người nghĩ rằng “đây là kiểm chứng của chính chúng tôi” hay không sẽ quyết định PoC có chạy được tới cuối hay không.

Sau khi khoanh vùng đối tượng, việc ghi rõ phạm vi không nằm trong đối tượng cũng rất quan trọng. Nếu viết rõ “lần này chỉ một chiếc bơm của dây chuyền chiết rót số 1, các máy khác và công đoạn đóng gói nằm ngoài phạm vi”, thì khi có yêu cầu phát sinh kiểu “tiện thể đo luôn cái kia đi” trong thời gian PoC, bạn có cơ sở để từ chối. Yêu cầu phát sinh này gần như chắc chắn sẽ tới. Nếu không từ chối, cả thời hạn lẫn điều kiện đánh giá đều sụp đổ.

Về cấu hình giám sát vận hành và cách hiển thị dữ liệu thu thập được, nội dung đã được trình bày tại Triển khai IoT nhà máy và cách tiến hành giám sát vận hành. Hãy tham khảo ở giai đoạn thiết kế cụ thể việc xem cái gì và xem như thế nào, sau khi đã khoanh vùng đối tượng PoC.

Bước 2 trong quy trình triển khai IoT PoC – quyết định thông số bằng cách suy ngược từ mục đích của dữ liệu

Sprint đầu tiên của PoC nên dành cho thiết kế chứ không phải cho việc đặt mua thiết bị. Về phương pháp triển khai cụ thể trong IoT hóa nhà máy, thứ tự thiết kế được khuyến nghị là suy ngược theo trình tự “mục đích của dữ liệu, độ chi tiết cần thiết, rồi mới tới thông số cảm biến”.

Nếu không giữ trình tự này thì điều gì xảy ra. Khi bắt đầu từ cảm biến, “những gì cảm biến đó đo được” sẽ trở thành mục đích của dữ liệu. Mua cảm biến rung nên xem độ rung, lắp đồng hồ điện nên xem điện năng. Từ đó mới bắt đầu nghĩ “vậy dùng dạng sóng này để làm gì”, nên phần lớn là không tìm ra chỗ dùng.

Dưới đây là ví dụ cụ thể về việc suy ngược. Mục đích thay đổi thì độ chi tiết cần thiết thay đổi, độ chi tiết thay đổi thì thông số cảm biến và lưu lượng truyền thông cũng thay đổi.

Càng xuống dưới thì đầu tư và công sức cần thiết càng tăng. Ở đây nhiều nhà máy ngay từ đầu đã nhắm tới dòng thứ ba hoặc thứ tư, khiến việc thiết kế mất nhiều thời gian và chậm khởi động. PoC lần đầu chỉ cần dòng thứ nhất hoặc dòng thứ hai là đủ. Chỉ cần biết “có đang dừng hay không” và “vì sao dừng” thì thảo luận tại hiện trường đã chuyển sang dựa trên sự kiện. Phát hiện dấu hiệu nên được thiết kế như giai đoạn kế tiếp, khi đó điều kiện đánh giá cũng dễ viết hơn.

Cách tư duy khi đi tới mức phát hiện dấu hiệu đã được hệ thống hóa tại Triển khai và vận hành hệ thống bảo trì dự đoán. Hãy tham khảo khi cân nhắc chủ đề cho PoC lần thứ hai trở đi.

Còn một thứ nữa phải quyết trong thiết kế suy ngược. Đó là giá trị hiện trạng làm mốc so sánh, tức đường cơ sở. Để có thể nói “kết quả PoC cho thấy số lần dừng máy đã giảm”, cần có số liệu về số lần dừng và thời gian dừng trước khi PoC bắt đầu. Thế nhưng ở nhiều nhà máy, ghi chép đó chỉ tồn tại trong nhật ký viết tay. Hãy chắc chắn đưa vào giai đoạn thiết kế việc dành vài tuần trước khi PoC bắt đầu để đo đường cơ sở, hoặc tổng hợp và số hóa nhật ký trong quá khứ. Nếu bỏ qua chỗ này, sau khi PoC kết thúc bạn sẽ rơi vào trạng thái “có cảm giác là đã cải thiện nhưng không chứng minh được”.

Bước 3 trong quy trình triển khai IoT PoC – quyết định điều kiện đánh giá đầu ra bằng con số trước khi bắt đầu

Đây là trọng tâm của bài viết. Trước khi khởi động PoC, hãy viết ra bằng con số và thời hạn câu trả lời cho “đạt tới đâu thì triển khai chính thức”, rồi lấy phê duyệt của người ra quyết định. Có bốn yếu tố cần viết.

Yếu tố 1 – KPI và giá trị mục tiêu. Với từng hạng mục kiểm chứng, hãy viết con số được coi là đạt. Không viết “thu thập được dữ liệu” mà viết “tỷ lệ mất dữ liệu dưới 5%”. Không viết “phát hiện được bất thường” mà viết “trong số các lần dừng máy đột xuất phát sinh trong kỳ, có từ 2 trong 3 lần trở lên phát hiện được dấu hiệu trước 24 giờ”.

Yếu tố 2 – thời hạn. Hãy đưa ngày kết thúc PoC và ngày họp phán quyết vào lịch ngay từ đầu. Dù dữ liệu chưa đầy đủ thì vẫn phán quyết đúng ngày đó. Nếu cần gia hạn, thì chính việc có gia hạn hay không cũng phải quyết tại cuộc họp phán quyết. Mục đích là không tạo ra trạng thái “cứ thế mà tiếp tục một cách mơ hồ”.

Yếu tố 3 – hạn mức đầu tư khi triển khai chính thức. Hãy ước tính sơ bộ trước khi PoC bắt đầu câu trả lời cho “nếu kết luận là Go thì sẽ cân nhắc đầu tư tới mức nào”. Không có con số này thì dù PoC thành công cũng không có điểm khởi đầu cho hồ sơ trình duyệt, và lại mất thêm vài tháng nữa.

Yếu tố 4 – phân loại phán quyết và hành động tương ứng cho từng loại. Hãy viết trước sẽ làm gì tiếp theo trong ba phân loại Go, Go có điều kiện và No-Go. Việc đưa No-Go vào danh sách lựa chọn ngay từ đầu là rất quan trọng. Một cuộc kiểm chứng không có No-Go thì không phải là kiểm chứng.

Định dạng của điều kiện đánh giá có thể tổng hợp như sau.

Không nhiều nhà máy lưu lại No-Go dưới dạng hồ sơ. Nhưng nếu giữ lại, thì vài năm sau khi có đề xuất tương tự, bạn có thể bắt đầu thảo luận từ điểm xuất phát “lần trước với điều kiện này thì không thành lập được”. Công nghệ và giá cả đều đã thay đổi nên kết luận có thể khác đi, nhưng không cần phải điều tra lại từ con số không.

Ví dụ điền điều kiện đánh giá – tính toán thử tại một nhà máy mẫu

Để cụ thể hóa cách tư duy, dưới đây là một phép tính thử tại nhà máy mẫu. Toàn bộ các con số dưới đây là giá trị giả định phục vụ giải thích, không phải số liệu thực tế của một nhà máy nào. Khi tự tính cho công ty mình, hãy thay từng giá trị bằng số liệu thực tế của mình.

Tiền đề là đối tượng gồm một chiếc bơm nước công nghiệp. Trong 12 tháng gần nhất có 18 lần dừng máy đột xuất, thời gian khôi phục trung bình mỗi lần là 90 phút. Lợi nhuận gộp bị mất trên mỗi giờ dừng dây chuyền được đặt là THB 20,000. Khi đó tổn thất hằng năm của một máy đối tượng là 18 lần × 1.5 giờ × THB 20,000 = THB 540,000.

Điều dự kiến trong triển khai chính thức là mở rộng ra 6 chiếc bơm cùng loại. Vì đối tượng PoC được chọn là chiếc có lịch sử dừng máy nhiều nhất, nên số lần dừng của 5 chiếc còn lại sẽ ít hơn con số này. Nếu 6 chiếc bơm này dừng đột xuất tổng cộng 40 lần mỗi năm với thời gian khôi phục trung bình cũng là 90 phút, thì tổn thất hằng năm của 6 máy là 40 lần × 1.5 giờ × THB 20,000 = THB 1,200,000. Giả định rằng nhờ phát hiện dấu hiệu thu được từ PoC mà 40% số lần dừng đột xuất được chuyển thành dừng theo kế hoạch, thì hiệu quả cắt giảm hằng năm là THB 1,200,000 × 40% = THB 480,000. Nếu đặt hạn mức đầu tư cho triển khai chính thức là THB 1,200,000 bao gồm cảm biến, gateway, thiết lập màn hình và chi phí vận hành năm đầu, thì số năm hoàn vốn là 1,200,000 ÷ 480,000 = 2.5 năm. Nếu chuẩn nội bộ là “trong vòng 3 năm” thì kết luận là Go, còn nếu là “trong vòng 2 năm” thì là No-Go.

Có một điểm cần lưu ý trong phép tính này. Vì ở đây hiệu quả chỉ được đặt ở phần cắt giảm tổn thất dừng máy, nên số tiền hiệu quả tỷ lệ thuận trực tiếp với đơn giá trên mỗi giờ dừng. Giả sử đơn giá là THB 10,000 thì hiệu quả sẽ là THB 240,000 mỗi năm, số năm hoàn vốn kéo dài thành 5 năm và kết luận là No-Go. Nói cách khác, kết luận của phép tính này bị đảo ngược chỉ bởi cách đặt đơn giá. Chính vì vậy, cần thống nhất với bộ phận kế toán về mức đơn giá trước khi PoC bắt đầu.

Ngoài ra, nếu bổ sung vào hiệu quả cả phần giảm giờ công bảo trì hay giảm chi phí làm thêm giờ và chi phí linh kiện gấp đi kèm ứng phó đột xuất, thì những khoản này không tỷ lệ thuận với lợi nhuận gộp bị mất trên mỗi giờ dừng. Nếu áp dụng đồng loạt hệ số đã dùng để nhân với tổn thất dừng máy lên cả những hiệu quả có tính chất khác biệt này, kết luận sẽ sai. Hãy tách hiệu quả theo từng loại, và khi xem độ nhạy cũng hãy thay đổi theo từng loại.

Lịch trình chuẩn của PoC – cách sắp xếp 12 tuần

Dù nói là quyết thời hạn trước, nhưng nếu không có mốc tham chiếu thì cũng khó vạch ra. Với PoC IoT nhà máy có đối tượng từ một thiết bị tới một dây chuyền, việc bố trí từ thiết kế tới họp phán quyết trong 12 tuần là đơn vị thực tế.

Điểm quan trọng trong lịch trình này là có đặt một điểm kiểm tra ở tuần thứ 4. Nếu tại đây tỷ lệ mất dữ liệu lệch xa mục tiêu, vẫn còn dư địa để sửa vị trí lắp đặt hoặc phương thức truyền thông. Nếu chạy hết 12 tuần rồi mới phát hiện “thực ra một nửa dữ liệu bị thiếu”, thì toàn bộ 12 tuần đó mất trắng.

Xin bổ sung thêm lý do đặt 6 tuần từ tuần 5 tới tuần 10 là giai đoạn “đo liên tục”. Khoảng thời gian này cần đủ dài để các biến động thông thường của nhà máy đi hết một vòng. Dữ liệu của một giai đoạn mà các sự kiện như tổ hợp ca làm việc, chuyển đổi mã hàng, tăng sản lượng cuối tháng, vệ sinh định kỳ chưa từng xảy ra lần nào thì không đủ để phán đoán điều gì sẽ xảy ra trong vận hành chính thức. Với nhà máy tại Thái Lan, nên kiểm tra thêm xem giai đoạn khởi động lại sau kỳ nghỉ dài có rơi vào khoảng thời gian này hay không.

Thiết kế vận hành để việc sử dụng dữ liệu bám rễ tại nhà máy

Thứ dễ bị bỏ sót trong thời gian PoC là kiểm chứng phần vận hành. Việc dữ liệu có thu được hay không thì hệ thống tự biết, nhưng việc hành vi tại hiện trường có thay đổi sau khi nhìn dữ liệu đó hay không sẽ không được ghi lại nếu không chủ động quan sát.

Ngay ở thời điểm thiết kế PoC, hãy viết ra giấy bốn điểm sau.

• Ai xem. Hãy quyết bằng tên người cụ thể chứ không phải chức danh. Cụ thể tới mức “tổ trưởng A”, “anh B bên kỹ thuật sản xuất”.
• Khi nào xem. Hãy lồng vào các khoảng thời gian đã có sẵn như trước buổi họp đầu ca, lúc giao ca, hoặc đầu cuộc họp tuần. Tạo thêm cuộc họp mới thì sẽ không duy trì được.
• Xem cái gì. Hãy thu hẹp còn một hoặc hai con số trên màn hình. Nếu bày 10 chỉ số lên dashboard thì sẽ không ai xem nữa.
• Đạt tới đâu thì làm gì. Hãy viết hành động khi vượt ngưỡng dưới dạng thao tác cụ thể. Không dừng ở “đi kiểm tra” mà viết tới mức “kiểm tra bôi trơn và điền vào phiếu ghi chép”.

PoC không viết được bốn điểm này sẽ rơi vào trạng thái mà cụm từ “cải tiến hiện trường dựa trên dữ liệu” chỉ tồn tại trong tài liệu. Dựa trên dữ liệu nghĩa là căn cứ để phán đoán được thay thế từ kinh nghiệm sang con số. Nếu chưa quyết được ai xem con số, xem vào lúc nào, và sau khi xem thì làm gì, thì không có cách nào để việc thay thế đó xảy ra.

Trong thời gian PoC, mỗi tuần một lần hãy phỏng vấn ngắn người phụ trách tại hiện trường. Ba câu hỏi là đủ, gồm “tuần này anh chị có xem màn hình này không”, “xem rồi thì có làm gì không”, “nếu không xem thì vì sao”. Ghi chép này chính là bằng chứng cho hạng mục kiểm chứng thứ hai tại cuộc họp phán quyết, tức khả năng ra quyết định. Câu trả lời “không xem” cũng là dữ liệu quý giá. Nếu lý do là “mở màn hình lên phiền quá” thì bạn biết rằng khi triển khai chính thức cần thay đổi vị trí đặt thiết bị hiển thị.

Về giai đoạn chỉnh đốn bản thân việc ghi chép công tác bảo trì và luồng ra chỉ thị, bài viết Triển khai và vận hành hệ thống bảo trì thiết bị cũng là tài liệu tham khảo hữu ích. Đây là nơi cần tham chiếu khi bạn cần cơ chế kết nối dấu hiệu thu được từ PoC với công việc bảo trì thực tế.

Phán quyết chuyển sang triển khai chính thức và cách tận dụng ưu đãi BOI Thái Lan

Sau khi phán quyết là Go, có một chế độ mà các nhà máy đặt cơ sở tại Thái Lan nên cân nhắc. Đó là khuôn khổ mang tên “Smart and Sustainable Industry” trong các biện pháp năm 2026 của Ủy ban Đầu tư Thái Lan (BOI).

Biện pháp này áp dụng cho các khoản đầu tư vào tích hợp Industry 4.0 bằng tự động hóa, robot và công nghệ số, cũng như đầu tư vào tiết kiệm năng lượng, năng lượng tái tạo và giảm tác động môi trường, và cho phép miễn thuế thu nhập doanh nghiệp (CIT) trong 3 năm. Trần miễn thuế về nguyên tắc là 50% giá trị đầu tư thuộc đối tượng. Tuy nhiên, chỉ trong trường hợp từ 30% trở lên giá trị của máy móc tự động hóa và robot sản xuất trong nước có liên kết hoặc hỗ trợ với máy móc sản xuất trong nước, thì mới áp dụng trần 100%. Mức đầu tư tối thiểu là THB 1,000,000, không tính tiền đất và vốn lưu động. Ngoài ra, cần hoàn tất đầu tư trong vòng 3 năm kể từ khi giấy chứng nhận ưu đãi được cấp.

Chế độ này ảnh hưởng tới thiết kế PoC ở hai điểm.

Thứ nhất, khả năng cao là riêng PoC sẽ không đạt mức đầu tư tối thiểu. Một cuộc kiểm chứng ở quy mô gắn thêm cảm biến cho một thiết bị thường là không đạt tới THB 1,000,000. Do đó, thứ nên xem xét như đối tượng của ưu đãi không phải là bản thân PoC mà là giai đoạn triển khai chính thức sau khi có phán quyết Go. Khi viết hạn mức đầu tư vào điều kiện đánh giá của PoC, nếu nắm được vị trí tương quan giữa mức đầu tư dự kiến cho triển khai chính thức và mức đầu tư tối thiểu, cách dựng hồ sơ trình duyệt sẽ khác đi.

Thứ hai, thời hạn hoàn tất trong vòng 3 năm kể từ khi cấp giấy chứng nhận ưu đãi có liên hệ với việc thiết kế thời hạn của PoC. Nếu PoC kéo dài một năm rồi hai năm, thì việc bắt tay vào triển khai chính thức bị chậm đúng bằng chừng đó. Nếu lập kế hoạch đầu tư trong khuôn khổ của chế độ, thì thời gian có thể dành cho kiểm chứng tự nhiên bị giới hạn. Nghĩa là lý do để quyết thời hạn trước lại có thêm một điều nữa, bên cạnh các lý do nội bộ.

Việc có áp dụng được chế độ hay không và thủ tục nộp hồ sơ trên thực tế sẽ thay đổi tùy theo ngành nghề, nội dung đầu tư và thời điểm nộp. Nội dung viết ở đây chỉ dừng ở mức hiểu khuôn khổ của chế độ, còn khả năng áp dụng thực tế xin vui lòng xác nhận với BOI hoặc đơn vị hỗ trợ nộp hồ sơ chuyên trách. Bài viết này không nhằm mục đích tư vấn thuế hay tư vấn đầu tư.

Về động thái xoay quanh ngành sản xuất thông minh tại Thái Lan, tại triển lãm Intelligent Manufacturing Expo Southeast Asia (IME 2026) được tổ chức từ ngày 22 đến ngày 24 tháng 7 năm 2026 tại IMPACT ở Bangkok, các nền tảng về AI, IoT, 5G, bản sao số và an ninh mạng đã được trưng bày. BOI cũng cung cấp các biện pháp ưu đãi dành cho khu công nghiệp thông minh. Có thể đọc rằng bản thân môi trường thúc đẩy ngành sản xuất Thái Lan đầu tư theo hướng thông minh hóa đang dần được hoàn thiện.

Những điểm cần lưu ý khi vận hành PoC tại nhà máy Nhật Bản ở Thái Lan

Cần bổ sung các điều kiện đặc thù của Thái Lan vào quy trình PoC vẫn được bàn tại Nhật Bản. Năm điểm sau có tác dụng trong thực tế.

Điều kiện tại chỗ về truyền thông và nguồn điện. Cách sóng vô tuyến lan truyền thay đổi rất lớn tùy theo kết cấu nhà xưởng và tình trạng đi dây hiện có. Vách ngăn kim loại, trần cao, các giá kệ kim loại đặt dày đều là yếu tố làm suy hao sóng. Khi kiểm tra truyền thông ở tuần thứ 3 của PoC, hãy đo vào khung giờ thiết bị đang chạy. Cường độ sóng đo lúc máy dừng có thể khác với giá trị đo thực tế khi máy đang vận hành.

Điều kiện môi trường. Độ ẩm mùa mưa, bụi bẩn, nước bắn từ công đoạn vệ sinh đều liên quan trực tiếp tới việc chọn vỏ hộp cho cảm biến gắn thêm. Chênh lệch cấp bảo vệ chống bụi chống nước mà một máy thì không đáng bận tâm, khi lên vài chục máy sẽ hiện ra thành chênh lệch chi phí bảo trì. Việc thời gian PoC có bao gồm mùa mưa hay không cũng đáng để xác nhận khi vạch lịch trình.

Ngôn ngữ và màn hình. Nếu người xem màn hình là nhân viên người Thái tại hiện trường, thì hiển thị nhất thiết phải bằng tiếng Thái. Một PoC đặt dashboard tiếng Nhật rồi kết luận “hiện trường không xem” là vô hiệu xét về mặt kiểm chứng khả năng ra quyết định. Ngược lại, tài liệu báo cáo về trụ sở chính lại cần tiếng Nhật. Hãy quyết ngay ở giai đoạn thiết kế PoC rằng màn hình nào chuẩn bị bằng ngôn ngữ nào.

Cấu trúc ra quyết định hai tầng. Hãy làm rõ trước khi PoC bắt đầu rằng ai là người quyết tại cuộc họp phán quyết. Hãy xác nhận mức trần số tiền mà pháp nhân tại Thái Lan được tự quyết và mức số tiền cần phê duyệt của trụ sở chính tại Nhật Bản, rồi nắm xem mức đầu tư dự kiến thuộc bên nào. Nếu chỗ này mơ hồ, sau phán quyết Go sẽ phát sinh vài tháng cho việc “bây giờ mới bắt đầu làm tài liệu trình lên trụ sở chính”.

Ghi chép trên tiền đề người phụ trách sẽ thay đổi. Hãy đặt nội dung cài đặt, mã thiết bị, sơ đồ đi dây, mật khẩu và đầu mối liên hệ của nhà cung cấp ở nơi lưu trữ dùng chung thay vì máy tính cá nhân, và tiếp tục cập nhật. Nhiệm kỳ của nhân sự biệt phái là vài năm, thời gian làm việc của kỹ sư tuyển tại chỗ đôi khi còn ngắn hơn. Để thành quả của PoC còn lại trong tổ chức, cần quyết định nơi lưu trữ ghi chép như một phần của việc thiết kế.

Về hình hài của các trường hợp IoT đã thực sự được triển khai tại nhà máy ở Thái Lan, nội dung được giới thiệu tại Các trường hợp triển khai IoT trong ngành sản xuất Thái Lan. Bài viết này hữu ích khi bạn muốn xem có những ví dụ nào bắt tay từ công đoạn nào, lúc chọn đối tượng cho PoC của mình.

Mức chi phí PoC và cách dựng hồ sơ trình duyệt

Chi phí PoC thay đổi rất lớn tùy theo số lượng thiết bị đối tượng, mức độ dễ trích xuất tín hiệu từ thiết bị hiện có, và độ chi tiết dữ liệu cần thiết. Bài viết này không đi vào chi tiết, nhưng xin sắp xếp lại cách tư duy khi dựng hồ sơ trình duyệt.

Khi lấy báo giá, hãy yêu cầu tách riêng chi phí PoC và chi phí triển khai chính thức, rồi trình bày cạnh nhau trong cùng một tài liệu. Nếu chỉ đưa ra số tiền của PoC, việc thẩm định sẽ dừng lại ở câu hỏi “sau đó còn tốn bao nhiêu nữa”. Nếu có ghi kèm ước tính cho triển khai chính thức, người ra quyết định có thể phán đoán việc có làm PoC hay không trên nền tảng cảm nhận được quy mô của toàn bộ khoản đầu tư. Việc ghi song song này có cùng mục đích với việc đặt trước hạn mức đầu tư ở yếu tố 3 của điều kiện đánh giá.

Ngoài ra, hãy xác nhận ngay ở giai đoạn báo giá rằng thiết bị mua cho PoC có tiếp tục dùng được trong triển khai chính thức hay không. Cấu hình thuê chỉ dành riêng cho PoC có ưu điểm là kìm được chi phí ban đầu, nhưng đổi lại sau phán quyết Go sẽ phải mua sắm lại từ đầu. Bên nào có lợi hơn thì tùy từng dự án, nhưng đây là hạng mục cần được nêu rõ như một căn cứ để phán đoán.

Về cơ cấu chi phí và mặt bằng giá tham khảo, nội dung đã được hệ thống hóa tại Chi phí IoT nhà máy và cơ cấu chi phí. Hãy tham khảo ở giai đoạn dựng số tiền cho hồ sơ trình duyệt.

Câu hỏi thường gặp (FAQ)

IoT PoC là gì

PoC là viết tắt của Proof of Concept, được dịch là kiểm chứng khái niệm. Trong IoT nhà máy, PoC là công đoạn giới hạn đối tượng, lắp cảm biến thật và thu dữ liệu, để trước khi đầu tư quy mô lớn xác nhận rằng có lấy được dữ liệu mong muốn hay không, dữ liệu đó có làm thay đổi phán đoán tại hiện trường hay không, và khi nhân rộng thì có sinh lời hay không. Điểm mấu chốt là đây không phải việc kiểm tra công nghệ có chạy hay không, mà là kiểm tra nó có thành lập được trong điều kiện riêng của công ty mình hay không.

Trong quy trình IoT PoC, việc đầu tiên cần làm là gì

Không phải chọn cảm biến, mà là thống nhất điều kiện đánh giá. Hãy viết ra bằng bốn yếu tố gồm giá trị mục tiêu của KPI, thời hạn, hạn mức đầu tư khi triển khai chính thức và hành động theo từng phân loại phán quyết, cho câu hỏi khi PoC kết thúc thì dựa vào cái gì để quyết định triển khai chính thức, rồi lấy phê duyệt của người ra quyết định trước khi bàn tới thiết bị. PoC bỏ qua bước này thì dù lấy được dữ liệu cũng không đi tiếp được.

Thời gian của một IoT PoC bao lâu là phù hợp

Với quy mô đối tượng từ một thiết bị tới một dây chuyền, việc bố trí khoảng 12 tuần từ thiết kế tới họp phán quyết là thực tế. Nếu đảm bảo khoảng 6 tuần đo đạc đủ để các biến động thông thường của nhà máy đi hết một vòng, cụ thể là bao gồm tổ hợp ca làm việc, chuyển đổi mã hàng và tăng sản lượng cuối tháng, đồng thời đặt một điểm kiểm tra tỷ lệ mất dữ liệu ở tuần thứ 4, thì việc phải làm lại sẽ được giữ ở mức nhỏ.

Chi phí cho một IoT PoC là bao nhiêu

Vì thay đổi rất lớn tùy theo số lượng thiết bị đối tượng, việc có trích xuất được tín hiệu từ thiết bị hiện có hay không, và độ chi tiết dữ liệu cần thiết, nên không thể đưa ra một mặt bằng giá đồng nhất. Khi lấy báo giá, hãy yêu cầu trình bày chi phí PoC và chi phí triển khai chính thức cạnh nhau trong cùng một tài liệu, và xác nhận thiết bị mua cho PoC có tiếp tục dùng được trong triển khai chính thức hay không. Về cơ cấu chi phí, xin tham khảo bài viết giải thích về chi phí.

Nên bắt đầu khởi động IoT quy mô nhỏ từ thiết bị nào

Phù hợp nhất là thiết bị có tổn thất khi dừng máy quy đổi được ra tiền, gắn được cảm biến bổ sung mà không cần cải tạo thiết bị, cách xử lý hiện nay đang là ứng phó sau sự cố, và có người cộng tác tại hiện trường hằng ngày vận hành thiết bị đó. Nếu chỉ chọn theo mức độ dễ lắp đặt, thì dù lấy được dữ liệu cũng không đo được hiệu quả, và không thể kiểm chứng khả năng sinh lời.

Nếu PoC không lấy được dữ liệu như mong muốn thì có phải là thất bại không

Nếu điều kiện đánh giá đã được viết trước, thì đó là kết quả No-Go chứ không phải thất bại. Điều quan trọng là lưu lại thành hồ sơ vì sao không lấy được và nếu thử lại thì sẽ thay đổi cái gì. Có hồ sơ này thì vài năm sau khi có đề xuất tương tự, bạn không cần điều tra lại từ con số không. Một cuộc kiểm chứng không đặt No-Go làm lựa chọn thì ngay từ đầu đã không thành lập được với tư cách là kiểm chứng.

Những bài toán IoT nào thường được nêu ra trong ngành sản xuất

Các hạng mục thường được nêu gồm không thu thập được dữ liệu cần thiết, chạy được trong môi trường kiểm chứng nhưng không chạy khi vận hành thực tế, phải làm lại hệ thống khi mở rộng chính thức, đánh giá thấp hiệu quả so với chi phí, chỉ thu thập dữ liệu mà không sử dụng được, biện pháp an ninh bị đẩy về sau, chương trình phụ thuộc cá nhân dừng lại khi người phụ trách thuyên chuyển. Đây không phải thứ tự theo tần suất phát sinh mà là liệt kê các mẫu thất bại tiêu biểu. Tuy nhiên, lập trường của bài viết này là phần lớn các hạng mục đó có thể phòng ngừa bằng thiết kế trước khi PoC bắt đầu, và bài toán căn bản hơn nằm ở phía ra quyết định, tức việc khởi động PoC khi chưa xác định bằng con số tiêu chí đánh giá triển khai chính thức.

Nhà máy tại Thái Lan có sử dụng được ưu đãi của BOI không

Trong biện pháp “Smart and Sustainable Industry” năm 2026 của Ủy ban Đầu tư Thái Lan (BOI), các khoản đầu tư vào tích hợp Industry 4.0 bằng tự động hóa, robot và công nghệ số được miễn thuế thu nhập doanh nghiệp trong 3 năm. Trần về nguyên tắc là 50% giá trị đầu tư thuộc đối tượng, và chỉ khi từ 30% trở lên giá trị của máy móc tự động hóa và robot sản xuất trong nước có liên kết hoặc hỗ trợ với máy móc sản xuất trong nước thì trần mới là 100%. Mức đầu tư tối thiểu là THB 1,000,000 không tính tiền đất và vốn lưu động, và cần hoàn tất đầu tư trong vòng 3 năm kể từ khi giấy chứng nhận ưu đãi được cấp. Vì khả năng áp dụng thay đổi theo ngành nghề và nội dung đầu tư, xin vui lòng xác nhận với BOI hoặc đơn vị chuyên hỗ trợ nộp hồ sơ.

Tổng kết – thành bại của PoC được định đoạt trong tuần lễ trước khi bắt đầu

Điều khó nhất trong PoC IoT nhà máy không phải là gắn cảm biến, cũng không phải là tích lũy dữ liệu. Đó là quyết định cách kết thúc, trước khi PoC bắt đầu.

Xin sắp xếp lại quy trình đã trình bày trong bài viết. Trước hết, những gì cần kiểm chứng trong PoC gồm ba điểm là khả năng thu thập, khả năng ra quyết định và khả năng sinh lời, và những bản báo cáo chỉ kiểm chứng điểm thứ nhất rồi kết thúc chính là nguyên nhân của tình trạng “mệt mỏi vì PoC”. Tiếp theo, các lý do khiến PoC không tiến tới triển khai chính thức gồm mức độ nghiêm túc của ban lãnh đạo, sự vắng mặt của thành quả và thời hạn, sự sụt giảm động lực do trạng thái lơ lửng, và việc biến PoC thành mục đích học hỏi, tất cả đều là yếu tố thuộc phía ra quyết định.

Về quy trình, hãy thu hẹp đối tượng xuống còn một dây chuyền hoặc một thiết bị, và lựa chọn theo bốn trục gồm tổn thất khi dừng máy, mức độ dễ lấy dữ liệu, dư địa cải tiến và người cộng tác tại hiện trường. Thiết kế thì suy ngược từ mục đích của dữ liệu tới độ chi tiết rồi tới thông số cảm biến, và số hóa đường cơ sở làm mốc so sánh trước khi bắt đầu. Và quan trọng nhất là viết thành văn bản bốn yếu tố gồm giá trị mục tiêu của KPI, thời hạn, hạn mức đầu tư cho triển khai chính thức và hành động theo từng phân loại phán quyết, rồi lấy phê duyệt của người ra quyết định trước khi PoC bắt đầu.

Sau khi phán quyết là Go, có những chế độ tận dụng được ở giai đoạn triển khai chính thức, chẳng hạn biện pháp “Smart and Sustainable Industry” của BOI Thái Lan. Tuy nhiên chế độ này có thời hạn hoàn tất trong vòng 3 năm kể từ khi giấy chứng nhận ưu đãi được cấp, nên ở đây lại nảy sinh thêm một lý do để không thể kéo dài PoC mãi. Việc quyết thời hạn trước vừa xuất phát từ nhu cầu nội bộ, vừa là tiền đề để sử dụng được chế độ.

Chúng tôi cũng nhận tư vấn ngay từ giai đoạn thiết kế PoC, tức giai đoạn còn chưa chọn thiết bị. Những điểm như viết điều kiện đánh giá thế nào, chọn thiết bị đối tượng ra sao, hay cấu hình nào là hợp lý khi nhìn xa tới tận triển khai chính thức, nếu được sắp xếp trước cả khi lấy báo giá thì việc phải làm lại về sau sẽ nhỏ đi. Nếu bạn sắp bắt đầu kiểm chứng IoT nhà máy tại Thái Lan, xin đừng ngần ngại liên hệ qua biểu mẫu liên hệ.

Thông tin tham khảo

1. Hiệu quả của việc triển khai IoT và lợi ích của khởi động quy mô nhỏ

Đây là nguồn tham chiếu cho việc thực hiện PoC giới hạn ở một dây chuyền sản xuất hoặc một thiết bị, và việc bắt đầu nhỏ bằng thiết bị IoT phổ thông cùng cảm biến gắn thêm nhằm kìm chi phí đầu tư ban đầu.

Hiệu quả của việc triển khai IoT và lợi ích của khởi động quy mô nhỏ – Factory Advance

2. Phương pháp triển khai cụ thể khi IoT hóa nhà máy và trình tự khởi động quy mô nhỏ

Đây là nguồn tham chiếu cho quan điểm rằng sprint đầu tiên của PoC nên dành cho thiết kế suy ngược theo trình tự “mục đích của dữ liệu, độ chi tiết cần thiết, thông số cảm biến”.

Phương pháp triển khai cụ thể khi IoT hóa nhà máy và trình tự khởi động quy mô nhỏ

3. Khởi động IoT nhà máy từ “một chiếc bơm”

Đây là nguồn tham chiếu cho quan điểm khởi động quy mô nhỏ từ một thiết bị và các điểm lưu ý trong thực tế tại hiện trường. Toàn bộ các con số dùng trong phép tính mẫu của bài viết này là giá trị giả định phục vụ giải thích, không phải số liệu thực tế được ghi trong nguồn này.

IoT nhà máy hãy bắt đầu từ “một chiếc bơm” – khởi động quy mô nhỏ không thất bại và thực tế tại hiện trường

4. Cách tiến hành dự án IoT thành công, thoát khỏi vòng lặp vô tận của PoC

Đây là nguồn cho bốn lý do khiến PoC không tiến tới triển khai chính thức, gồm thiếu mức độ nghiêm túc của ban lãnh đạo, sự vắng mặt của thành quả và thời hạn, sự sụt giảm động lực trong trạng thái “không phải thất bại nhưng cũng không thể gọi là thành công”, và việc biến PoC thành mục đích học hỏi cùng bắt chước tiền lệ. Các điều kiện hướng tới thành công được nêu trong bài, gồm mức độ nghiêm túc đủ để đòi hỏi kế hoạch kinh doanh, việc lồng ghép điểm khác biệt và việc ý thức về góc nhìn khách hàng, cũng thuộc cùng nguồn này.

Cách tiến hành dự án IoT thành công, thoát khỏi vòng lặp vô tận của PoC – Hitachi Solutions

5. Nguyên nhân khiến việc triển khai IoT thất bại

Đây là nguồn cho bảy mẫu thất bại gồm không thu thập được dữ liệu cần thiết, chạy được trong môi trường kiểm chứng nhưng không chạy khi vận hành thực tế, phải làm lại hệ thống khi mở rộng chính thức, đánh giá thấp hiệu quả so với chi phí, chỉ thu thập dữ liệu mà không sử dụng được, biện pháp an ninh bị đẩy về sau, và chương trình phụ thuộc cá nhân dừng lại khi người phụ trách thuyên chuyển.

Nguyên nhân khiến việc triển khai IoT thất bại là gì

6. Các biện pháp ưu đãi đầu tư năm 2026 của BOI Thái Lan

Đây là nguồn cho các điều kiện trong biện pháp “Smart and Sustainable Industry”, gồm miễn thuế thu nhập doanh nghiệp 3 năm, trần về nguyên tắc là 50% giá trị đầu tư thuộc đối tượng, trần 100% chỉ khi từ 30% trở lên giá trị của máy móc tự động hóa và robot sản xuất trong nước có liên kết hoặc hỗ trợ với máy móc sản xuất trong nước, mức đầu tư tối thiểu THB 1,000,000 không tính tiền đất và vốn lưu động, và việc hoàn tất đầu tư trong vòng 3 năm kể từ khi giấy chứng nhận ưu đãi được cấp. Phán đoán về khả năng áp dụng khác nhau tùy từng dự án cụ thể.

Thailand’s BOI in 2026 – From Investment Incentives to Accelerated Project Delivery – MPG

7. IME 2026 (Intelligent Manufacturing Expo Southeast Asia)

Đây là nguồn cho việc triển lãm được tổ chức từ ngày 22 đến ngày 24 tháng 7 năm 2026 tại IMPACT ở Bangkok với các nền tảng về AI, IoT, 5G, bản sao số và an ninh mạng, cùng việc BOI cung cấp các biện pháp ưu đãi dành cho khu công nghiệp thông minh.

Powering ASEAN’s Manufacturing Transformation – IME 2026 – PR Newswire