Cách chọn công ty phát triển phần mềm tại Đông Nam Á 2026: chi phí và hợp đồng

“Chúng tôi muốn xây dựng hệ thống cho nhà máy, nhưng không biết nên giao cho ai” — đây là câu hỏi chúng tôi nghe nhiều nhất từ các nhà quản lý sản xuất tại Đông Nam Á. Khi nói đến công ty phát triển phần mềm ở Thái Lan hay Việt Nam, thực tế có ít nhất bốn nhóm nhà cung cấp rất khác nhau: nhà cung cấp IT Nhật Bản, nhà cung cấp nội địa, chi nhánh của các tập đoàn SI toàn cầu, và các trung tâm phát triển offshore. Mỗi nhóm mạnh ở loại dự án khác nhau, có cấu trúc giá khác nhau và cách bảo trì cũng khác nhau. Bài viết này tổng hợp khung đánh giá thực dụng: bốn nhóm nhà cung cấp, bảy trục lựa chọn, cách bóc tách chi phí, các điểm nghẽn về hợp đồng — pháp lý, năm kiểu thất bại lặp đi lặp lại, và lộ trình đặt hàng theo bốn bước RFI → RFP → PoC → triển khai từng giai đoạn.

Bối cảnh thị trường: đọc số liệu Thái Lan để hiệu chỉnh kỳ vọng

Trước khi so sánh báo giá, nên nắm tình trạng cung — cầu của thị trường. Không biết thị trường đang căng hay chùng thì rất khó phán đoán một mức giá hay một tiến độ là hợp lý hay phi thực tế.

Lưu ý quan trọng: toàn bộ số liệu thị trường trong phần này là số liệu của Thái Lan, được trích từ các báo cáo nghiên cứu công khai. Chúng tôi dẫn lại vì Thái Lan là thị trường mà TOMAS TECH hoạt động trực tiếp và vì nhiều tập đoàn sản xuất vận hành song song nhà máy tại cả Thái Lan lẫn Việt Nam. Đây không phải số liệu của Việt Nam. Nếu bạn cần con số cho thị trường Việt Nam, hãy tra cứu nguồn thống kê riêng của Việt Nam.

Thị trường đang mở rộng, kéo theo cuộc giành giật nhân lực kỹ thuật

Theo ước tính của Mordor Intelligence, thị trường IT và an ninh mạng của Thái Lan đạt 10,03 tỷ USD vào năm 2026 và được dự báo tăng lên 16,72 tỷ USD vào năm 2031, tương ứng tốc độ tăng trưởng kép hằng năm (CAGR) 10,26%. Một thị trường tăng trưởng hai chữ số liên tục năm năm cũng đồng nghĩa với việc nguồn kỹ sư khả dụng sẽ tiếp tục bị tranh giành.

Ở phạm vi hẹp hơn là thị trường dịch vụ IT, Data Bridge Market Research ước tính quy mô của Thái Lan vào năm 2025 khoảng 2,5 tỷ USD, với CAGR giai đoạn 2025–2030 là 3,31%. Trong cơ cấu đó, IT outsourcing chiếm phần lớn nhất với 1,03 tỷ USD, dịch vụ phần mềm đạt 1,13 tỷ USD (CAGR 4,46%), còn dịch vụ số (digital services) có tốc độ tăng trưởng cao nhất, khoảng 34%.

Đặt hai nhóm số liệu cạnh nhau, tính chất của thị trường hiện lên khá rõ. Tổng thị trường (bao gồm phần cứng, sản phẩm bảo mật, hạ tầng cloud) tăng hai chữ số, trong khi dịch vụ IT truyền thống — tức mô hình “cử người ngồi tại chỗ để vận hành” — chỉ tăng chậm. Phần tăng mạnh nằm ở nhóm dịch vụ số: cloud-native, khai thác dữ liệu, AI.

Dịch sang ngôn ngữ của người đi đặt hàng: mô hình phát triển scratch kèm bảo trì thường trú đang không còn là vùng tăng trưởng ngay cả từ phía nhà cung cấp. Vì vậy khi chọn đối tác, đừng chỉ nhìn danh sách dự án đã làm, hãy hỏi xem năm năm qua họ đầu tư nhân lực vào đâu. Việc họ có đội ngũ cho cloud, tích hợp API và nền tảng dữ liệu hay không sẽ quyết định chất lượng bảo trì mà bạn nhận được năm năm tới.

Khu vực công chuyển lên cloud, kéo mặt bằng chung của nhà cung cấp lên theo

Yếu tố thể chế cũng đáng chú ý. Cơ quan Phát triển Chính phủ Số của Thái Lan (DGA) đặt mục tiêu chuyển 70% khối lượng công việc mới của khu vực công lên cloud trước năm 2027. Ngoài ra, 412 cơ quan nhà nước phải hoàn tất chuyển ít nhất một hệ thống lõi lên cloud trước tháng 12 năm 2026.

Khi hoạt động mua sắm công chuyển sang mặc định dùng cloud, kỹ năng thiết kế tiêu chuẩn của các nhà cung cấp phục vụ khu vực đó cũng dịch chuyển theo. Ngược lại, một nhà cung cấp năm 2026 vẫn chỉ đưa ra được phương án on-premise là dấu hiệu cho thấy bộ kỹ năng của họ có thể đã ngừng cập nhật vài năm nay.

Lựa chọn hạ tầng cũng đã rộng hơn. Google Cloud đã khai trương region tại Bangkok, tức là có thể vừa giữ dữ liệu trong lãnh thổ Thái Lan vừa tận dụng tiện ích của cloud. Như sẽ phân tích ở phần pháp lý, sự tồn tại của một region trong nước có tác động rất lớn đến phương án thiết kế.

Tốc độ phổ cập AI tạo sinh thuộc nhóm nhanh nhất thế giới

Có một con số thường gây bất ngờ. Theo BigGo Finance, tỷ lệ người sử dụng AI tạo sinh một cách tích cực tại Thái Lan đạt 12,4% trong quý I năm tài chính 2026, tăng 36,4% so với cùng kỳ năm trước, đưa Thái Lan lên vị trí thứ hai thế giới về tốc độ áp dụng AI.

Nhiều trụ sở chính vẫn mặc định rằng “khu vực Đông Nam Á tiếp nhận công nghệ chậm”. Ít nhất với AI tạo sinh thì điều ngược lại đang xảy ra: nhân viên tại hiện trường đã bắt đầu dùng công cụ AI trong công việc, trong khi quy định nội bộ của doanh nghiệp chưa theo kịp. Khi chọn nhà cung cấp, việc họ có thể thảo luận nghiêm túc về năng suất phát triển có tích hợp AI hay không cũng là một thước đo để đánh giá độ hợp lý của báo giá.

Bốn nhóm công ty phát triển phần mềm tại Đông Nam Á

Vào phần chính. Khi đặt hàng phát triển hệ thống ở Thái Lan hoặc Việt Nam, các lựa chọn thực tế có thể quy về bốn nhóm. Không nhóm nào “xấu” — vấn đề chỉ là độ tương thích với tính chất dự án.

Nhóm 1: Nhà cung cấp IT Nhật Bản (pháp nhân tại nước sở tại)

Đây là các công ty do người Nhật điều hành hoặc giữ các vị trí chủ chốt, xử lý được toàn bộ chuỗi từ định nghĩa yêu cầu đến bảo trì bằng tiếng Nhật. Phần lớn có kinh nghiệm trong quản lý sản xuất, kết nối kế toán, chấm công, tính giá thành cho các nhà máy Nhật Bản, và trao đổi trực tiếp được với phòng hệ thống thông tin ở trụ sở chính bằng tiếng Nhật.

Điểm mạnh là năng lực bắc cầu giữa yêu cầu viết bằng tiếng Nhật và đội lập trình bản địa đã được thiết chế hóa thành quy trình, đồng thời hiểu cả tập quán kinh doanh Nhật (nghiệm thu, quy trình phê duyệt nội bộ, độ chi tiết của báo cáo) lẫn thực tế vận hành tại nước sở tại. Điểm yếu là nhiều công ty có quy mô hạn chế nên khó nhận trọn gói các dự án rất lớn, và đơn giá thường cao hơn nhà cung cấp nội địa.

Với doanh nghiệp Việt Nam, nhóm này đáng cân nhắc khi bạn là nhà cung cấp cấp 1 cho khách hàng Nhật, khi công ty mẹ hoặc đối tác liên doanh là doanh nghiệp Nhật, hoặc khi cần hệ thống tương thích với chuẩn báo cáo của tập đoàn Nhật.

Nhóm 2: Nhà cung cấp nội địa

Là các công ty phát triển phần mềm do vốn và nhân sự trong nước điều hành. Đây là nhóm đông đảo nhất và có sức cạnh tranh về giá. Nhiều đơn vị nắm rất chắc phần triển khai liên quan tới thuế, hóa đơn điện tử, bảo hiểm xã hội và luật lao động của nước sở tại, nên rất mạnh ở các hệ thống nghiệp vụ dùng nội bộ trong nước.

Mặt khác, ngôn ngữ làm việc thường là tiếng bản địa hoặc tiếng Anh. Nhiều nơi quảng bá có hỗ trợ tiếng Nhật, nhưng trên thực tế chỉ bộ phận kinh doanh nói được tiếng Nhật còn đội phát triển thì không. Ngoài ra, các gói phần mềm kế toán và nghiệp vụ làm cho thị trường nội địa thường không hỗ trợ đa tiền tệ, đa ngôn ngữ, và giao diện chỉ có tiếng bản địa — khiến quản lý người nước ngoài không thể thực thi kiểm soát nội bộ. Nếu bạn phải báo cáo lên công ty mẹ ở nước ngoài hoặc phải phục vụ kiểm toán, đây là điểm bắt buộc phải kiểm chứng trước.

Nhóm 3: Chi nhánh của các tập đoàn SI toàn cầu

Là các văn phòng khu vực của những công ty SI và công ty tư vấn quốc tế lớn. Với các dự án quy mô lớn — thay mới ERP, triển khai template chuẩn toàn cầu, roll-out đồng thời nhiều quốc gia — họ vượt trội về phương pháp luận và khả năng huy động nhân sự. Tài liệu quản trị và hồ sơ phục vụ kiểm toán cũng rất đầy đủ.

Đổi lại, đơn giá cao nhất và các dự án nhỏ thường vướng ngưỡng giá trị hợp đồng tối thiểu. Nhân sự tư vấn cũng thay đổi nhanh, nên “người hiểu hiện trường nhà máy” chưa chắc còn ở lại đến cuối dự án. Với các dự án đụng đến thiết bị đầu cuối tại xưởng hoặc mạng OT, thường vẫn phải bổ sung thêm một đối tác địa phương.

Nhóm 4: Trung tâm phát triển offshore

Là hình thức dùng đội phát triển đặt tại quốc gia khác — Việt Nam, Ấn Độ, Philippines, Myanmar — để làm dự án từ xa. Cũng có trường hợp một công ty tại nước sở tại giữ vai trò tiếp nhận rồi đẩy phần thực thi sang trung tâm offshore của chính họ.

Đây cũng chính là mô hình outsourcing phần mềm Đông Nam Á mà nhiều tập đoàn Nhật, Mỹ và châu Âu đang sử dụng. Với các dự án web, ứng dụng cần khối lượng lập trình lớn, mô hình này hiệu quả về chi phí và mở rộng đội hình rất nhanh. Tuy nhiên, với các dự án buộc phải có mặt tại hiện trường — dây chuyền, thiết bị, máy trạm tại xưởng — khoảng cách vật lý chính là rủi ro. Hãy cân nhắc kỹ liệu một đội không thể “ngày mai có mặt tại nhà máy” có đủ sức đỡ một hệ thống chạy 24/7 hay không.

Bảng so sánh bốn nhóm

Trên thực tế, thay vì giao tất cả cho một công ty, ngày càng nhiều doanh nghiệp phân tầng: hệ thống lõi giao cho nhà cung cấp mạnh về hiện trường, phần web giao cho offshore, ERP toàn tập đoàn giao cho SI toàn cầu. Nếu chọn cách này, bắt buộc phải ghi rõ ranh giới trách nhiệm tại các điểm ghép nối trong hợp đồng.

Bảy trục đánh giá cần kiểm tra trước khi nhìn tới giá

Theo kinh nghiệm của chúng tôi, con số báo giá nên là thứ xem sau cùng. Phần lớn chênh lệch giá giữa các nhà cung cấp chỉ phản ánh việc họ đã cắt bỏ hoặc đã tính vào một trong các hạng mục dưới đây.

Trục 1: Yêu cầu được định nghĩa bằng ngôn ngữ nào

Đây là điểm rẽ nhánh lớn nhất. Nếu yêu cầu được viết bằng tiếng Nhật hoặc tiếng Anh còn phần lập trình diễn ra bằng tiếng bản địa, giữa hai đầu chắc chắn có bước dịch. Không xác định rõ ai dịch và ai rà soát bản dịch thì sẽ dẫn tới thất bại kinh điển: yêu cầu nghiệp vụ không xuống được đúng vào phần triển khai.

Câu hỏi cần đặt ra không phải “bên anh có ai biết tiếng Nhật không”, mà là “giữa người viết tài liệu yêu cầu và người viết code có bao nhiêu lần chuyển đổi ngôn ngữ?”. Không lần nào, một lần (Nhật → Anh), hay hai lần (Nhật → Anh → tiếng bản địa) — rủi ro suy giảm chất lượng đặc tả khác nhau hoàn toàn.

Trục 2: Thiết kế lôi kéo bộ phận nghiệp vụ vào cuộc như thế nào

Nguyên nhân thất bại lớn nhất của các dự án hệ thống trong ngành sản xuất không nằm ở kỹ thuật, mà ở chỗ bộ phận nghiệp vụ không cam kết, chỉ có bộ phận IT chạy một mình, cộng thêm việc phó mặc cho nhà cung cấp mà không tự nghiệm thu.

Nhà cung cấp nào ghi rõ ngay trong đề xuất rằng “nhân sự chủ chốt của bộ phận nghiệp vụ sẽ phải dành bao nhiêu giờ ở giai đoạn nào” thường là bên đã từng nếm thất bại này và rút được kinh nghiệm. Ngược lại, đề xuất kiểu “cứ giao hết cho chúng tôi, phía quý công ty gần như không phải làm gì” nghe rất dễ chịu nhưng là tín hiệu cảnh báo.

Trục 3: Thực chất của bộ máy bảo trì

Cần làm rõ dòng chữ “hỗ trợ 24/7” trên hợp đồng vận hành ra sao trên thực tế: ai là đầu mối tiếp nhận, có bao nhiêu kỹ sư ở tuyến hai, nửa đêm sự cố thì có thực sự đến được nhà máy không. Hệ thống quản lý sản xuất mà dừng thì sản xuất cũng dừng, nên phải làm rõ định nghĩa thời gian phản hồi: tính đến lúc tiếp nhận, hay tính đến lúc khôi phục.

Trục 4: Khoảng cách vật lý tới hiện trường

Trục này hay bị xem nhẹ nhưng lại rất quan trọng. Nếu nhà máy nằm trong khu công nghiệp cách trung tâm thành phố hai đến ba giờ xe chạy — tại Thái Lan là Ayutthaya, Rayong, Chonburi, Prachinburi — thì tính khả thi của lời hứa “có việc gì chúng tôi sẽ tới ngay” tỷ lệ nghịch với khoảng cách.

Hãy kiểm tra báo giá đã tính bao nhiêu ngày công có mặt tại hiện trường cho các hạng mục bắt buộc (lắp đặt máy trạm tại xưởng, giám sát thi công mạng, thử nghiệm truyền thông với thiết bị) và chi phí đi lại, lưu trú đã nằm trong đó chưa.

Trục 5: Ngôn ngữ và độ chi tiết của tài liệu

Nếu tài liệu bàn giao chỉ có tiếng Anh, bộ phận hệ thống thông tin của công ty mẹ có thể không rà soát nổi. Ngược lại, nếu chỉ có tiếng bản địa, quản lý người nước ngoài không thể thực thi kiểm soát nội bộ.

Điểm cân bằng thực tế thường là: tài liệu thiết kế bằng tiếng Anh hoặc tiếng Nhật, còn tài liệu hướng dẫn sử dụng phải có bản tiếng bản địa cho công nhân. Hãy chốt trước khi ký hợp đồng: ai làm bản nào, và chi phí dịch thuật đã nằm trong báo giá chưa.

Trục 6: Hiểu tập quán kinh doanh của cả hai phía

Việc bê nguyên hệ thống chuẩn của công ty mẹ sang rồi phát hiện nó không khớp với chế độ thuế, mẫu chứng từ và cách vận hành hiện trường của nước sở tại là chuyện lặp đi lặp lại. Nhưng nếu chiều theo thực tế địa phương hoàn toàn thì lại vướng ở khâu hợp nhất báo cáo và kiểm toán.

Thuế giá trị gia tăng, thuế khấu trừ tại nguồn, mẫu hóa đơn hợp lệ, chứng từ liên quan xuất nhập khẩu và các chương trình ưu đãi đầu tư — hãy hỏi thẳng nhà cung cấp đã từng triển khai những phần này chưa và yêu cầu họ nêu ví dụ cụ thể. Lưu ý: quy định về thuế và chứng từ khác nhau giữa từng quốc gia, nên hãy xác nhận riêng cho nước mà hệ thống sẽ vận hành.

Trục 7: Mức độ dễ dàng khi rút lui hoặc chuyển giao

Đây là trục bị bỏ sót nhiều nhất. Khi quan hệ với nhà cung cấp đó kết thúc, bạn có chuyển giao được hệ thống cho bên khác không? Mã nguồn thuộc về ai, môi trường phát triển có tái lập được không, hệ thống có phụ thuộc vào framework hay thư viện riêng của nhà cung cấp không?

Hãy xác nhận trước khi ký rằng hệ thống không bị đóng vào cấu trúc “chỉ công ty này mới làm tiếp được”. Tính phổ biến của công nghệ được chọn (ngôn ngữ, framework, cơ sở dữ liệu có được dùng rộng rãi không) chính là năng lực đàm phán của bạn trong tương lai.

Chi phí phát triển phần mềm: bảng đơn giá không cho bạn biết tổng tiền

“Đơn giá một người-tháng ở Thái Lan là bao nhiêu?” là câu hỏi chúng tôi nhận rất thường xuyên. Nhưng để ước lượng tổng chi phí thì câu hỏi này thực ra không hữu ích lắm. Xin giải thích theo thứ tự.

Tham chiếu đơn giá người-tháng của các nước trong khu vực

Trước hết là bảng đơn giá người-tháng theo Sách trắng phát triển offshore bản 2025 (số liệu tại thời điểm ngày 13 tháng 2 năm 2026). Đây là mức giá mà doanh nghiệp Nhật Bản chi trả cho các trung tâm phát triển tại từng quốc gia, tính bằng yên Nhật.

Cũng theo tài liệu này, đơn giá trung bình của lập trình viên đã giảm xuống còn 340.000 yên.

Một lưu ý quan trọng: thống kê này không bao gồm số liệu của Thái Lan. Thái Lan có rất ít thống kê đơn giá được công bố, nên không có con số nào đủ tin cậy để trích dẫn. Cảm nhận từ thực tế công việc là mức giá thường nằm cùng khoảng với Việt Nam và Philippines hoặc nhỉnh hơn một chút, và sẽ cao hơn nữa nếu kèm chức năng bắc cầu tiếng Nhật — nhưng chúng tôi cho rằng chỉ nên dừng ở mức mô tả định tính như vậy. Với đơn giá cụ thể, hãy lấy báo giá thực tế từ nhiều công ty rồi so sánh.

Mẹo khi đọc bảng đơn giá: hãy chú ý vào dòng bridge SE và PM. Ngay trong bảng trên, khoảng cách giữa lập trình viên và PM đã gần gấp đôi. Ở các dự án có yếu tố xuyên ngôn ngữ, tỷ trọng công sức của tầng “dịch và điều phối” này thường rất lớn, và chính nó đẩy tổng chi phí lên. Nếu chỉ chọn nhà cung cấp dựa trên đơn giá lập trình viên rẻ, bạn sẽ bỏ qua cấu trúc chi phí thật.

Bóc chi phí thành ba lớp: đầu tư ban đầu, bảo trì và chi phí ẩn

Báo giá thường chỉ ghi phần đầu tư ban đầu, nhưng nếu tính tổng chi phí sở hữu (TCO) trong năm năm thì phần bảo trì nhiều khi còn lớn hơn. Chúng tôi khuyến nghị bóc tách và so sánh theo cấu trúc dưới đây.

Đặc biệt, chuyển đổi dữ liệu và nhân lực nội bộ là hai hạng mục hay vượt xa dự tính ban đầu. Các bảng tính Excel và dữ liệu master của hệ thống cũ hầu như luôn tồn tại tình trạng viết không thống nhất, trùng lặp, hoặc chứa mã đã ngừng dùng. Việc làm sạch dữ liệu này chỉ bên đặt hàng mới làm được, và đánh giá nhẹ khâu này sẽ kéo lùi toàn bộ tiến độ.

Cần đồng nhất những tiền đề nào khi so sánh báo giá

Khi lấy báo giá từ nhiều công ty, nếu không đồng nhất các tiền đề sau thì việc so sánh vô nghĩa.

• Phạm vi nghiệp vụ (bao gồm tới quy trình nghiệp vụ nào)
• Số người dùng dự kiến và số phiên truy cập đồng thời
• Khoảng thời gian và số lượng bản ghi cần chuyển đổi dữ liệu
• Phạm vi kiểm thử (nhà cung cấp đảm nhận tới kiểm thử đơn vị, tích hợp hay nghiệm thu)
• Khung giờ bảo trì và thời gian phản hồi
• Loại tài liệu và ngôn ngữ tài liệu
• Hạn mức chỉnh sửa sau khi vận hành (số giờ mỗi tháng)

Chỉ cần lập một trang giấy ghi bảy mục này và gửi cùng một điều kiện cho tất cả các bên, độ chính xác khi so sánh báo giá đã tăng lên rất nhiều.

Những điểm dễ vấp về hợp đồng và pháp lý

Hợp đồng phát triển hệ thống ở nước ngoài, nếu triển khai theo đúng cảm giác quen thuộc trong nước, sẽ va phải những vấn đề không lường trước. Đặc biệt những năm gần đây quy định bảo vệ dữ liệu ngày càng chặt, không tính vào ngay từ khâu thiết kế thì sẽ phải làm lại.

Chế độ bảo vệ dữ liệu của Thái Lan và vị trí đặt dữ liệu

Phần này mô tả chế độ của Thái Lan, dùng làm ví dụ tham chiếu về cách một quốc gia ASEAN quy định vấn đề vị trí dữ liệu. Nếu hệ thống của bạn vận hành tại Việt Nam hoặc một quốc gia khác, bắt buộc phải xác nhận riêng các văn bản pháp luật, quy định ngành và chương trình ưu đãi tương ứng của nước đó với bộ phận pháp chế hoặc tư vấn pháp lý địa phương. Chúng tôi không suy diễn quy định của nước này sang nước khác.

Luật Bảo vệ Dữ liệu Cá nhân của Thái Lan (PDPA) có hiệu lực toàn diện từ tháng 6 năm 2022. Điểm đầu tiên cần nắm: Thái Lan không có nghĩa vụ nội địa hóa dữ liệu áp dụng chung. Nghĩa là không có quy tắc bắt buộc mọi ngành phải đặt dữ liệu của người Thái trong lãnh thổ Thái Lan.

Tuy nhiên có ngoại lệ. Tháng 9 năm 2024, NCSC (cơ quan thường trực Ủy ban An ninh mạng Quốc gia Thái Lan) đã thông qua quy định về sử dụng cloud dành cho các đơn vị vận hành hạ tầng thông tin trọng yếu (CIIO). Theo quy định này, với các hệ thống thông tin có mức độ tác động “cao”, trung tâm dữ liệu chính phải đặt trong lãnh thổ Thái Lan, còn bản sao lưu phải đặt tại Thái Lan hoặc trong khu vực ASEAN. Doanh nghiệp có thuộc diện CIIO hay không (điển hình là năng lượng, tài chính, y tế công cộng, vận tải, viễn thông) nên được bộ phận pháp chế xác nhận từ sớm.

Về chuyển dữ liệu ra nước ngoài, khuôn khổ cơ bản là chuyển sang quốc gia thuộc danh sách trắng, hoặc chuyển theo điều khoản hợp đồng tiêu chuẩn (SCC). Việc tập trung dữ liệu nhân sự của nhân viên tại nước sở tại về máy chủ của công ty mẹ không phải chuyện hiếm, và trong trường hợp đó cần chuẩn bị đầy đủ hợp đồng chuyển dữ liệu nội bộ tập đoàn.

Riêng với cloud của chính phủ Thái Lan, nguyên tắc là lưu trong lãnh thổ Thái Lan, các ngoại lệ cần DGA phê duyệt. Nếu dự án liên quan tới cơ quan nhà nước thì tiền đề sẽ khác.

Như đã đề cập, Google Cloud đã có region tại Bangkok, và số lượng lựa chọn region trong nước đang tăng lên. Định kiến “dùng cloud là dữ liệu ra khỏi biên giới” không còn nhất thiết đúng.

Bản quyền và quyền sở hữu mã nguồn

Trong thực tiễn Nhật Bản, hợp đồng thường ghi “bản quyền sản phẩm bàn giao được chuyển cho bên đặt hàng”. Nhưng khi ký với nhà cung cấp nước ngoài, bạn có thể gặp điều khoản theo hướng bản quyền mã nguồn vẫn thuộc nhà cung cấp, bên đặt hàng chỉ được cấp quyền sử dụng.

Đây là điểm bắt buộc phải đàm phán rõ ràng. Tối thiểu, hãy chốt các nội dung sau trong hợp đồng.

• Phạm vi bản quyền hoặc quyền sử dụng đối với sản phẩm bàn giao (mã nguồn, tài liệu thiết kế, quy trình build)
• Bên đặt hàng có quyền thuê bên thứ ba chỉnh sửa hệ thống hay không
• Cách xử lý các tài sản nền (thư viện, framework) mà nhà cung cấp đã sở hữu từ trước, và điều kiện tiếp tục sử dụng nếu hệ thống phụ thuộc vào chúng
• Nghĩa vụ nộp danh sách license của các thư viện mã nguồn mở

Việc bạn có chuyển được sang nhà cung cấp khác hay không được quyết định ngay tại điều khoản này.

Điều kiện nghiệm thu và trách nhiệm với lỗi

Hợp đồng chỉ ghi tiêu chí nghiệm thu là “khi bên đặt hàng phê duyệt” là bất lợi cho cả hai phía. Cần cụ thể hóa tới mức danh mục kiểm thử và tiêu chí đạt.

• Thời gian kiểm thử nghiệm thu (bao nhiêu ngày làm việc) và có hay không điều khoản “mặc nhiên nghiệm thu” khi hết thời hạn
• Phân loại mức độ nghiêm trọng của lỗi (dừng nghiệp vụ / có phương án thay thế / lỗi nhẹ) và thời hạn xử lý tương ứng từng mức
• Thời hạn trách nhiệm bảo hành đối với lỗi — mức đề xuất có thể ngắn hơn thông lệ mà bạn quen
• Có đưa yêu cầu hiệu năng sau vận hành (thời gian phản hồi, số phiên đồng thời) vào hạng mục nghiệm thu hay không

Ngôn ngữ hợp đồng và luật áp dụng

Ở Đông Nam Á, việc ký hợp đồng bằng tiếng Anh và coi bản tiếng bản địa là bản dịch tham khảo khá phổ biến. Điều quan trọng là ghi rõ bản ngôn ngữ nào có hiệu lực ưu tiên khi hai bản có mâu thuẫn. Ngoài ra, luật áp dụng và phương thức giải quyết tranh chấp (tòa án nước sở tại hay trọng tài tại Singapore chẳng hạn) sẽ ảnh hưởng rất lớn tới chi phí khi có sự cố. Với hợp đồng giá trị lớn, việc thuê một hãng luật địa phương rà soát ở giai đoạn ký kết là hoàn toàn xứng đáng.

Nếu hệ thống có kết nối vào mạng OT (mạng điều khiển) của nhà máy, yêu cầu bảo mật và ranh giới trách nhiệm cũng phải đưa vào hợp đồng. Chúng tôi đã trình bày chi tiết cách tiếp cận lĩnh vực này trong bài An ninh mạng OT nhà máy.

Ưu đãi BOI của Thái Lan: phát triển phần mềm cũng nằm trong diện được hưởng

Một yếu tố chi phí hay bị bỏ qua là ưu đãi của Ủy ban Đầu tư Thái Lan (BOI). Ưu đãi dành cho ngành sản xuất thì nhiều người biết, nhưng bản thân hoạt động phát triển phần mềm cũng là một hạng mục được hưởng ưu đãi.

Một lần nữa xin nhấn mạnh: đây là chế độ của Thái Lan. Các quốc gia khác trong khu vực đều có chương trình ưu đãi đầu tư riêng với điều kiện và phạm vi khác nhau, nên nếu bạn dự định đặt chức năng phát triển tại Việt Nam hay nước khác, hãy xác nhận trực tiếp với cơ quan xúc tiến đầu tư của nước đó. Đừng áp dụng nội dung dưới đây cho quốc gia khác.

Miễn thuế thu nhập doanh nghiệp tối đa 8 năm

BOI có hạng mục “phát triển phần mềm, nền tảng dịch vụ số và nội dung số”, cho phép miễn thuế thu nhập doanh nghiệp tối đa 8 năm. Phát triển hệ thống ứng dụng AI, dịch vụ cloud và vận hành trung tâm dữ liệu cũng nằm trong phạm vi.

Khi tính hạn mức ưu đãi hằng năm, các yếu tố được cân nhắc gồm chi phí tuyển dụng thêm nhân lực IT người Thái, chi phí đào tạo họ, và chi phí đạt các chứng nhận tiêu chuẩn quốc tế như ISO 29110 hoặc CMMI cấp 2 trở lên. Nói cách khác, triết lý thiết kế của chính sách là: doanh nghiệp nào tuyển và đào tạo kỹ sư bản địa, đồng thời chuẩn hóa quy trình phát triển, thì được hưởng ưu đãi lớn hơn.

Ý nghĩa thực tiễn đối với bên đặt hàng

Trừ khi bạn tự thành lập công ty con chuyên phát triển phần mềm, ưu đãi BOI trực tiếp là chuyện của phía nhà cung cấp. Nhưng với bên đặt hàng, nó vẫn có hai ý nghĩa.

Thứ nhất, có thể dùng làm tín hiệu chất lượng của nhà cung cấp. Chứng nhận ISO 29110 hoặc CMMI cấp 2 trở lên là bằng chứng ở mức độ nhất định rằng quy trình phát triển đã được văn bản hóa, hoạt động rà soát và quản lý cấu hình đang thực sự vận hành. Đưa câu hỏi về tình trạng chứng nhận vào hồ sơ mời thầu là một cách đo độ trưởng thành của tổ chức đó.

Thứ hai, nếu tập đoàn của bạn có ý định pháp nhân hóa chức năng IT tại nước sở tại, việc tính cả ưu đãi đầu tư vào phương án sẽ làm thay đổi tổng chi phí. Với ý tưởng đặt trung tâm phát triển tại một nước rồi mở rộng sang các cơ sở khác trong ASEAN, đây là hướng đáng nghiên cứu nghiêm túc.

Dù thế nào, điều kiện áp dụng ưu đãi luôn được xét theo từng hồ sơ, nên đừng kết luận bằng lý thuyết chung mà hãy mang kế hoạch kinh doanh cụ thể đi tư vấn riêng.

Năm kiểu thất bại thường gặp và cách phòng tránh

Phần này tổng hợp các kiểu thất bại lặp đi lặp lại trong thực tế. Trường hợp thất bại vì đề bài quá khó về mặt kỹ thuật thực ra là thiểu số.

Kiểu 1: Chỉ bộ phận IT chạy, bộ phận nghiệp vụ không cam kết

Đây là kiểu điển hình nhất. Nhân sự IT khởi động dự án theo chỉ đạo từ trên, nhưng các bộ phận thực sự vận hành công việc — sản xuất, mua hàng, kế toán — lại nghĩ “việc này không phải của mình”. Họ có mặt ở buổi phỏng vấn lấy yêu cầu nhưng không tham gia kiểm thử, rồi sau khi hệ thống chạy thật mới nói “thế này thì không làm việc được”.

Cách phòng tránh là chỉ định rõ chủ sở hữu (owner) phía bộ phận nghiệp vụ ngay khi khởi động dự án, và đưa dự án vào chỉ tiêu đánh giá của người đó. Kèm theo đó, quy định rằng tài liệu định nghĩa yêu cầu phải có chữ ký của trưởng bộ phận nghiệp vụ.

Kiểu 2: Bắt tay làm khi yêu cầu chưa chốt, thay đổi đặc tả chồng chất

Cách tiếp cận “cứ làm thử, vừa nhìn sản phẩm chạy vừa quyết” tự nó không xấu, nhưng nếu bắt đầu mà không có quy tắc quản lý thay đổi thì yêu cầu bổ sung sẽ tích tụ vô hạn. Kết quả là vượt ngân sách và trễ tiến độ xảy ra cùng lúc.

Cách phòng tránh là chốt quy trình quản lý thay đổi ngay khi ký hợp đồng: ai duyệt thay đổi, đơn giá thay đổi là bao nhiêu, nhận thay đổi đến thời điểm nào. Đồng thời chia dự án thành các giai đoạn và làm rõ “phạm vi bị đóng băng ở giai đoạn này”.

Kiểu 3: Phần mềm nội địa không hỗ trợ đa tiền tệ, đa ngôn ngữ

Các gói kế toán và nghiệp vụ làm riêng cho thị trường nội địa thường mặc định một loại tiền tệ và giao diện chỉ một ngôn ngữ. Sau khi triển khai mới phát sinh cảnh “cuối cùng vẫn phải làm lại bằng Excel để báo cáo lên công ty mẹ” hoặc “quản lý người nước ngoài không đọc được màn hình nên quy trình phê duyệt chỉ còn hình thức”.

Cách phòng tránh là ở giai đoạn tuyển chọn, hãy chỉ định cụ thể màn hình mà cấp quản lý sẽ dùng và biểu mẫu xuất ra để báo cáo lên công ty mẹ, rồi yêu cầu nhà cung cấp demo trực tiếp. Đừng chỉ tin dòng chữ “hỗ trợ đa ngôn ngữ” trong catalogue.

Kiểu 4: Bê nguyên hệ thống chuẩn của công ty mẹ sang

Định hướng chuẩn hóa toàn cầu bản thân nó đúng, nhưng nếu triển khai mà không điều chỉnh theo chế độ thuế, mẫu chứng từ và cách vận hành hiện trường của nước sở tại (công nhân đa kỹ năng, chế độ ca kíp, quản lý chấm công gồm cả lao động nước ngoài), hiện trường sẽ phải nhập liệu hai lần.

Cách phòng tránh là kể cả khi mang template chuẩn sang, hãy vạch trước ranh giới giữa phần tuyệt đối không nhượng bộ và phần phải điều chỉnh theo địa phương. Cách chia thực tế thường là: chuẩn hóa hệ thống mã kế toán và độ chi tiết của báo cáo hợp nhất, còn màn hình vận hành tại hiện trường thì bản địa hóa.

Kiểu 5: Thiếu nhân sự bắc cầu nên đặc tả không truyền đạt đúng

Trên đường đi từ yêu cầu viết bằng tiếng Nhật, qua tiếng Anh, xuống phần lập trình bằng tiếng bản địa, các sắc thái sẽ rơi rụng. Đặc biệt những “tiền đề ngầm hiểu” — chẳng hạn “đương nhiên là chốt sổ cuối tháng chứ” — nếu không viết ra thì sẽ không được triển khai.

Cách phòng tránh là đặt hẳn một mục “viết ra các tri thức ngầm” trong tài liệu định nghĩa yêu cầu, và yêu cầu bridge SE phải hiểu nghiệp vụ. Ranh giới thành bại nằm ở chỗ có hay không một người không chỉ phiên dịch mà còn hiểu nghiệp vụ để tái cấu trúc đặc tả.

Lộ trình đặt hàng: RFI → RFP → PoC → triển khai từng giai đoạn

Điều chúng tôi muốn nhắn nhất tới những ai đang ở giai đoạn so sánh nhà cung cấp là: đừng đặt hàng lớn ngay từ đầu. Đi theo bốn bước dưới đây sẽ giúp giảm rủi ro theo từng nấc.

Bước 1: RFI (yêu cầu cung cấp thông tin) để hiểu thị trường

Khi yêu cầu còn chưa định hình, hãy bắt đầu bằng RFI. Bạn đặt vấn đề với nhiều công ty theo kiểu “chúng tôi đang gặp bài toán thế này, có những hướng giải nào?” và quan sát sự khác nhau trong cách tiếp cận.

Ở giai đoạn này điều cần hỏi không phải giá, mà là họ đã từng giải bài toán tương tự như thế nào. Ví dụ cùng ngành, cùng quy mô, đội hình khi đó, thời gian thực hiện, và cả những điểm không suôn sẻ. Nhà cung cấp trung thực sẽ kể cả chuyện thất bại.

RFI nên gửi cho khoảng ba đến năm công ty, kéo dài hai đến bốn tuần. Thành quả lớn nhất của bước này, thật ra, là chính bạn nhìn rõ hơn bài toán của mình.

Bước 2: RFP (yêu cầu đề xuất) để đồng nhất điều kiện

Dựa trên thông tin thu được từ RFI, bạn soạn RFP. Nhớ đưa đủ bảy mục tiền đề đã nêu ở phần “cần đồng nhất những tiền đề nào khi so sánh báo giá”. Ngoài ra, ghi thêm các nội dung sau sẽ nâng chất lượng đề xuất.

• Quy trình nghiệp vụ hiện tại và các vấn đề (tốt nhất là có sơ đồ As-Is)
• Trạng thái muốn đạt tới sau khi hệ thống hóa (mục tiêu định tính To-Be, và nếu được thì cả chỉ số định lượng)
• Danh sách hệ thống hiện có và yêu cầu tích hợp
• Ràng buộc (khoảng ngân sách, thời điểm mong muốn vận hành, tiêu chuẩn nội bộ, chính sách về vị trí lưu dữ liệu)
• Tiêu chí đánh giá và thang điểm (không chỉ giá, mà cả đội hình, kinh nghiệm, bảo trì, khả năng chuyển giao)

Công khai tiêu chí đánh giá từ trước mang lại hai lợi ích: nhà cung cấp đưa ra đề xuất trúng đích hơn, và quy trình tuyển chọn nội bộ của bạn có cơ sở giải trình.

Bước 3: PoC (chứng minh khái niệm) để thử ở quy mô nhỏ

Thay vì lao thẳng vào phát triển chính thức, hãy làm chạy thật trong một phạm vi giới hạn. Mục đích của PoC không chỉ là xác nhận “về mặt kỹ thuật có làm được không”. Quan trọng hơn là kiểm chứng liệu bạn có làm việc được với nhà cung cấp này không.

• Tốc độ và độ chính xác khi trả lời câu hỏi
• Cách họ báo cáo khi xảy ra tình huống ngoài dự kiến
• Cách giao tiếp với nhân viên vận hành tại hiện trường
• Chất lượng tài liệu

Chúng tôi khuyến nghị đặt hàng PoC có trả phí. PoC miễn phí thường khiến nhà cung cấp không thể dành nguồn lực, và cuối cùng cả hai bên đều không nhìn thấy thực chất của nhau.

Bước 4: Thiết kế triển khai từng giai đoạn và khởi động nhỏ

Ngay cả khi đã vào phát triển chính thức, đừng làm trọn gói tất cả tính năng — hãy chia theo đơn vị tạo ra giá trị và triển khai dần. Điểm mấu chốt khi thiết kế lộ trình khởi động nhỏ là định nghĩa được “trong ba tháng đầu, ai sẽ cảm nhận được điều gì”.

Với các dự án nhà máy, những cửa vào sau đây thường phát huy hiệu quả.

• Bắt đầu từ thu thập dữ liệu thực tế tại hiện trường: chuyển sản lượng, tình trạng vận hành thiết bị, số lượng lỗi từ giấy và Excel sang dạng số. Vì không thay đổi nghiệp vụ hiện tại mà chỉ bắt đầu lấy dữ liệu nên hiện trường ít phản ứng
• Bắt đầu từ trực quan hóa: đưa dữ liệu đã thu thập lên dashboard. Trải nghiệm “con số trước đây cuối tháng mới biết thì nay hôm sau đã biết” chính là thứ kéo được sự hợp tác cho giai đoạn tiếp theo
• Bắt đầu từ giảm giấy tờ: số hóa các biểu mẫu như phiếu đặt hàng, phiếu kiểm tra, báo cáo hằng ngày. Dùng AI-OCR thì có thể chuyển đổi mà không phải thay đổi lớn cách vận hành giấy hiện tại (AI-OCR tự động hóa văn phòng)
• Bắt đầu từ một dây chuyền: trước khi mở rộng ra toàn nhà máy, hãy vận hành thật trên một dây chuyền để lộ ra các vấn đề

Đi theo thứ tự này thì quyết định đầu tư cũng có thể chia nhỏ. Cách làm “có kết quả ở giai đoạn 1 rồi mới duyệt ngân sách giai đoạn 2” cũng dễ được chấp thuận hơn khi giải trình với ban lãnh đạo hoặc công ty mẹ.

Về tiêu chí lựa chọn bản thân hệ thống quản lý sản xuất MES, chúng tôi đã tổng hợp theo góc nhìn yêu cầu chức năng trong bài Chuyển đổi số sản xuất 2026 (MES).

Đặc thù của hệ thống nhà máy: tiền đề khác hẳn hệ thống văn phòng

Cuối cùng, xin tổng hợp những điểm chỉ riêng dự án hệ thống nhà máy mới có. Giao dự án nhà máy cho một nhà cung cấp không hiểu những điểm này thì sau khi vận hành bạn sẽ rất vất vả.

Hệ thống quản lý sản xuất phải được thiết kế với tiền đề “không được dừng”

Hệ thống kế toán có dừng vài giờ để bảo trì ban đêm cũng không ảnh hưởng nghiệp vụ. Nhưng ở nhà máy chạy 24/7, hệ thống quản lý sản xuất MES dừng đồng nghĩa với sản xuất dừng. Đây là điểm khác biệt căn bản khi bạn chọn một công ty phát triển hệ thống cho nhà máy thay vì một đơn vị chỉ quen làm hệ thống văn phòng.

Vì vậy, các nội dung sau trở thành yêu cầu thiết kế.

• Quy trình vận hành offline khi mất mạng hoặc hỏng máy chủ (bao gồm phương án chạy bằng giấy rồi nhập bù sau)
• Đặt cửa sổ bảo trì vào lúc nào (cần điều phối với kế hoạch sản xuất)
• Mức độ dự phòng của kiến trúc và chi phí đi kèm
• Thống nhất mục tiêu thời gian khôi phục (RTO) và mục tiêu điểm khôi phục (RPO)

Chỉ nói “chúng tôi có sao lưu” là chưa đủ. Hãy kiểm tra xem có hồ sơ ghi lại việc đã thực sự phục hồi thử và mất bao nhiêu giờ để khôi phục hay không.

Với giám sát thiết bị IoT, phần lớn thành bại nằm ở khâu khảo sát trước “có kết nối được không”

Ở các dự án lấy dữ liệu từ thiết bị, yếu tố bất định lớn nhất là liệu thiết bị đó có thực sự xuất được dữ liệu ra hay không. Thiết bị đời cũ không có cổng truyền thông, PLC dùng giao thức độc quyền, nhà sản xuất không công bố thông tin — những rào cản này rất phổ biến.

Do đó, với dự án IoT chúng tôi luôn khuyến nghị thực hiện khảo sát hiện trường (assessment) có trả phí trước. Không lập được danh sách thiết bị, model, hãng và thế hệ của bộ điều khiển, hiện trạng đi dây thì không thể ra được báo giá tử tế. Báo giá đưa ra mà bỏ qua bước khảo sát này thì chắc chắn sẽ phát sinh chi phí bổ sung về sau. Cách tư duy về tự động hóa và thu thập dữ liệu ở phía thiết bị được trình bày trong bài Tự động hóa nhà máy Việt Nam 2026.

Máy trạm tại hiện trường phải chọn theo điều kiện môi trường

Chọn thiết bị đầu cuối với cùng cảm giác như chọn PC văn phòng là sẽ thất bại. Hiện trường nhà máy là môi trường nhiệt độ và độ ẩm cao, nhiều bụi, dầu, rung động, công nhân đeo găng tay và tiếng ồn lớn.

• Có thao tác được khi vẫn đeo găng tay không (màn hình cảm ứng điện dung nhiều khi không nhận găng tay)
• Cấp bảo vệ chống bụi, chống nước (chuẩn IP) đã đủ chưa
• Khả năng nhìn rõ dưới nắng trực tiếp hoặc nơi thiếu sáng
• Thiết kế giao diện dựa trên tiền đề người dùng là công nhân nói tiếng bản địa
• Máy dự phòng và quy trình thay thế khi thiết bị hỏng

Và một yếu tố có tác dụng lớn hơn nhiều người nghĩ: giảm số ô cần nhập. Nếu máy trạm ngoài xưởng bắt nhập mười trường dữ liệu thì vận hành sẽ không duy trì được. Thiết kế thực tế là dùng mã vạch, mã QR và giữ phần nhập tay ở mức tối thiểu.

Điểm tiếp giáp giữa mạng OT và mạng IT

Cách kết nối giữa mạng OT nơi thiết bị sản xuất đấu vào và mạng IT nơi hệ thống nghiệp vụ chạy là vấn đề quan trọng nhất về bảo mật.

Nguyên tắc là không nối phẳng hai mạng với nhau mà đặt một vùng biên rõ ràng (DMZ). Ngay cả khi hệ thống quản lý sản xuất cần lấy dữ liệu từ thiết bị, hãy ưu tiên xem xét cấu hình chỉ cho dữ liệu đi một chiều từ phía thiết bị ra. Nếu ransomware đi qua mạng IT chạm tới được thiết bị sản xuất, hậu quả tệ nhất là dừng sản xuất.

Ở đây, rất nhiều dự án tiến hành trong tình trạng mơ hồ về việc bộ phận IT hay bộ phận OT (bảo trì, kỹ thuật sản xuất) chịu trách nhiệm. Hãy chốt điểm phân định trách nhiệm ngay từ giai đoạn đầu của dự án.

Ngoài ra, nếu thiết kế bao trùm cả phần hàng hóa từ nhà máy chảy sang kho và logistics thì bức tranh tối ưu tổng thể mới hiện ra. Xu hướng của lĩnh vực này được tổng hợp trong bài Chuyển đổi số logistics Đông Nam Á 2026.

Kết luận: hãy dựng thước đo trước khi đi so sánh

Khi đặt hàng phát triển hệ thống tại Đông Nam Á, thứ quyết định thành bại cuối cùng, theo chúng tôi, không phải là “đã chọn nhà cung cấp nào” mà là “đã chọn bằng thước đo nào“.

Xin tóm tắt lại các ý chính. Số liệu thị trường Thái Lan cho thấy quy mô thị trường IT và an ninh mạng đạt 10,03 tỷ USD năm 2026, khu vực công đang chuyển lên cloud và AI tạo sinh phổ cập rất nhanh, trong khi dịch vụ IT truyền thống chỉ tăng chậm. Trong bối cảnh đó, các lựa chọn nhà cung cấp quy về bốn nhóm — nhà cung cấp IT Nhật Bản, nhà cung cấp nội địa, chi nhánh SI toàn cầu và trung tâm offshore — mỗi nhóm phù hợp với một loại dự án khác nhau.

Khi tuyển chọn, hãy nhìn theo bảy trục: ngôn ngữ định nghĩa yêu cầu, cách lôi kéo bộ phận nghiệp vụ, thực chất bộ máy bảo trì, khoảng cách vật lý tới hiện trường, ngôn ngữ tài liệu, mức độ am hiểu tập quán kinh doanh của cả hai phía, và khả năng chuyển giao khi rút lui. Chi phí thì đừng so bằng đơn giá người-tháng mà hãy bóc thành ba lớp: ban đầu, bảo trì và chi phí ẩn. Về hợp đồng, cần làm rõ vị trí lưu dữ liệu theo quy định của chính quốc gia vận hành hệ thống, quyền sở hữu mã nguồn, điều kiện nghiệm thu, ngôn ngữ hợp đồng và luật áp dụng. Và hãy bắt đầu từ RFI, chèn một bước PoC, rồi mở rộng dần theo mô hình khởi động nhỏ.

Với dự án nhà máy, còn thêm các điểm đặc thù: thiết kế trên tiền đề không được dừng, khảo sát thiết bị trước khi báo giá, điều kiện môi trường của máy trạm hiện trường, và ranh giới với mạng OT. Đây đều là những thứ không nhìn ra được trên bàn giấy, phải đi bộ trong xưởng mới phát hiện.

Không vội, nhưng cũng không đứng yên. Bắt đầu từ việc diễn đạt rõ ràng bài toán của chính mình — nghe có vẻ đường vòng, nhưng thực tế lại là con đường chắc chắn nhất.

TOMAS TECH đặt trụ sở tại Bangkok và đồng hành cùng các nhà máy tại Thái Lan và ASEAN trong phát triển hệ thống và chuyển đổi số sản xuất. Không ít doanh nghiệp tìm đến chúng tôi ở giai đoạn yêu cầu còn chưa định hình, với những câu như “chúng tôi vẫn chưa sắp xếp được nên hệ thống hóa cái gì trước” hoặc “muốn so sánh báo giá của vài công ty nhưng không biết nên so bằng tiêu chí nào”. Nếu bạn cần thêm góc nhìn thực tế từ hiện trường để làm tư liệu đối chiếu, hãy liên hệ qua trang liên hệ. Chúng tôi trao đổi được bằng tiếng Nhật, tiếng Anh và tiếng Thái.

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

Chi phí phát triển phần mềm ở Thái Lan khoảng bao nhiêu?

Thái Lan có rất ít thống kê công khai đáng tin cậy, nên chúng tôi cho rằng không nên khẳng định một mức đơn giá người-tháng cụ thể. Làm tham chiếu, Sách trắng phát triển offshore bản 2025 (số liệu ngày 13 tháng 2 năm 2026) ghi nhận đơn giá lập trình viên tại Việt Nam là 401.000 yên, Philippines 372.000 yên và Ấn Độ 375.000 yên mỗi người-tháng. Theo cảm nhận thực tế, mức của Thái Lan thường nằm cùng khoảng đó hoặc nhỉnh hơn, và sẽ cao hơn nữa nếu kèm chức năng bắc cầu tiếng Nhật. Tổng chi phí thực tế phụ thuộc vào độ chính xác khi ước lượng khối lượng công việc và các chi phí ẩn nhiều hơn là vào đơn giá, nên hãy lấy báo giá từ nhiều công ty với cùng một bộ điều kiện rồi so sánh.

Nên chọn nhà cung cấp IT Nhật Bản hay nhà cung cấp nội địa?

Tùy tính chất dự án. Với các hệ thống kế toán, giá thành cần báo cáo lên công ty mẹ Nhật và cần kiểm soát nội bộ, hoặc các dự án bắt buộc định nghĩa yêu cầu bằng tiếng Nhật, nhà cung cấp Nhật Bản phù hợp hơn. Ngược lại, với dự án khép kín trong nước, người dùng chủ yếu là nhân viên bản địa và cần kinh nghiệm triển khai tuân thủ pháp luật sở tại, nhà cung cấp nội địa có lợi thế. Điểm mấu chốt để quyết định là “giữa người viết yêu cầu và người viết code có bao nhiêu lần chuyển đổi ngôn ngữ”. Càng nhiều lần chuyển đổi thì rủi ro suy giảm đặc tả càng cao, hãy chọn dựa trên việc bạn có chấp nhận được rủi ro đó không.

Thuê ngoài phát triển phần mềm theo mô hình offshore khác gì với phát triển tại chỗ?

Khác biệt lớn nhất là khoảng cách vật lý. Offshore dùng trung tâm phát triển ở quốc gia khác nên hiệu quả chi phí cao, phù hợp với các dự án web và ứng dụng cần khối lượng lập trình lớn. Nhưng với dự án có kết nối máy trạm tại xưởng hoặc thiết bị sản xuất, có hạng mục bắt buộc phải có người tại hiện trường, thì việc đội ngũ không thể “ngày mai có mặt” chính là rủi ro. Cách phân chia thực dụng là: hệ thống văn phòng giao cho offshore, hệ thống dính tới hiện trường nhà máy giao cho đơn vị có cơ sở tại chỗ.

Ưu đãi BOI có áp dụng được cho phát triển hệ thống theo hợp đồng không?

BOI của Thái Lan có hạng mục “phát triển phần mềm, nền tảng dịch vụ số và nội dung số”, cho phép miễn thuế thu nhập doanh nghiệp tối đa 8 năm. Phát triển hệ thống ứng dụng AI, dịch vụ cloud và vận hành trung tâm dữ liệu cũng thuộc phạm vi. Hạn mức ưu đãi hằng năm được xác định có tính đến chi phí tuyển dụng và đào tạo thêm nhân lực IT người Thái cũng như chi phí đạt chứng nhận quốc tế như ISO 29110 hoặc CMMI cấp 2 trở lên. Tuy nhiên khả năng áp dụng được xét theo từng kế hoạch kinh doanh, nên đừng kết luận bằng lý thuyết chung mà hãy tư vấn riêng. Đây là chế độ của Thái Lan; nếu bạn đặt chức năng phát triển ở quốc gia khác, hãy xác nhận chương trình ưu đãi tương ứng của nước đó.

Theo PDPA của Thái Lan, có bắt buộc đặt dữ liệu trong lãnh thổ Thái Lan không?

Thái Lan không có nghĩa vụ nội địa hóa dữ liệu áp dụng chung cho mọi ngành. Tuy nhiên, quy định về sử dụng cloud dành cho đơn vị vận hành hạ tầng thông tin trọng yếu (CIIO) mà NCSC thông qua vào tháng 9 năm 2024 yêu cầu các hệ thống thông tin có mức tác động “cao” phải đặt trung tâm dữ liệu chính trong lãnh thổ Thái Lan và bản sao lưu tại Thái Lan hoặc trong khu vực ASEAN. Chuyển dữ liệu ra nước ngoài về nguyên tắc dựa trên danh sách quốc gia được công nhận hoặc điều khoản hợp đồng tiêu chuẩn (SCC). Cloud của chính phủ về nguyên tắc lưu trong nước, ngoại lệ cần DGA phê duyệt. Hãy xác nhận sớm doanh nghiệp bạn có thuộc diện CIIO không. Xin nhắc lại rằng đây là quy định của Thái Lan — nếu hệ thống vận hành tại quốc gia khác, hãy tra cứu và xác nhận riêng quy định của nước đó.

Muốn triển khai hệ thống nhà máy theo hướng khởi động nhỏ thì nên bắt đầu từ đâu?

Những phạm vi chỉ bắt đầu thu thập dữ liệu mà không thay đổi quy trình nghiệp vụ hiện tại thường là cửa vào hiệu quả nhất. Cụ thể là thu thập sản lượng và tình trạng vận hành thiết bị, trực quan hóa bằng dashboard, số hóa biểu mẫu giấy, hoặc chạy thử trên đúng một dây chuyền. Điều quan trọng là định nghĩa được “trong ba tháng đầu, ai sẽ cảm nhận được điều gì”. Cách làm có kết quả ở giai đoạn 1 rồi mới xin duyệt ngân sách giai đoạn tiếp theo cũng dễ thuyết phục ban lãnh đạo hơn.

Nên gom về một nhà cung cấp hay chia cho nhiều bên?

Tùy quy mô và lĩnh vực. Gần đây ngày càng nhiều doanh nghiệp phân tầng: hệ thống quản lý sản xuất lõi giao cho nhà cung cấp mạnh về hiện trường, giao diện web giao cho offshore, ERP toàn tập đoàn giao cho SI toàn cầu. Nhược điểm của mô hình nhiều nhà cung cấp là ở các điểm ghép nối giữa hệ thống rất dễ rơi vào tình trạng không rõ bên nào chịu trách nhiệm. Nếu chia việc, hãy đặt người chịu trách nhiệm quản lý đặc tả giao diện ở phía bên đặt hàng và ghi rõ điểm phân định trách nhiệm trong hợp đồng.

Nguồn tham khảo

• Mordor Intelligence — Thailand IT and Security Market: https://www.mordorintelligence.com/industry-reports/thailand-it-and-security-market
• Data Bridge Market Research — Thailand IT Services Market: https://www.databridgemarketresearch.com/reports/thailand-it-services-market
• Hiệp hội Phần mềm Nhật Bản (SAJ) — Thông tin từ Ủy ban Đầu tư Thái Lan (BOI): https://www.saj.or.jp/NEWS/activity/government/210706_boi.html
• Cookie Information — What is the Thailand PDPA? 2026 guide: https://cookieinformation.com/blog/what-is-the-thailand-pdpa/
• Hogan Lovells — Thailand releases draft guidelines on government cloud adoption and data classification: https://www.hoganlovells.com/en/publications/thailand-releases-draft-guidelines-on-government-cloud-adoption-and-data-classification
• Offshore-kaihatsu.com — So sánh đơn giá 6 quốc gia (bản 2026): https://www.offshore-kaihatsu.com/faq/tanka.php
• BigGo Finance — Thái Lan vươn lên vị trí thứ hai thế giới về tốc độ áp dụng AI: https://finance.biggo.jp/news/ENXbs54B-PfaobXfgh3Q
• Google Cloud — Bangkok region launch: https://cloud.google.com/blog/products/infrastructure/google-cloud-launches-new-region-in-bangkok-thailand
• Yamada Consulting Group — Những thách thức doanh nghiệp Nhật gặp phải sau khi đầu tư vào Thái Lan: https://www.ycg-advisory.jp/learning/oversea_28/
• Toyo Keizai Online — Vì sao các dự án IT tất yếu thất bại: https://toyokeizai.net/articles/-/894218