Hệ thống quản lý sản xuất đám mây 2026 | Thứ ngừng đầu tiên không phải máy chủ mà là xác thực

Một cuộc họp được mở ra để quyết định “đám mây hay on-premise”, rồi kết thúc mà không có kết luận và bị dời sang lần sau. Đó là cảnh tôi đã chứng kiến nhiều lần tại các nhà máy Nhật Bản ở Thái Lan. Lý do không nằm ở việc thiếu thông tin. Lý do là người ta cố chọn một câu trả lời duy nhất cho toàn bộ hệ thống khi cân nhắc có nên dùng hệ thống quản lý sản xuất đám mây hay không. Đơn vị của quyết định là từng chức năng, và tiêu chí không phải chi phí mà là chức năng đó được phép ngừng bao nhiêu phút. Và thứ ngừng đầu tiên sau khi chuyển lên đám mây không phải máy chủ, cũng không phải ứng dụng, mà là xác thực.

Việc đưa hệ thống quản lý sản xuất lên đám mây đã thay đổi tiền đề trong năm 2026

Từ trước tới nay, mỗi lần các cơ sở tại Thái Lan cân nhắc đám mây, câu chuyện luôn dừng lại ở đúng một chỗ: “dữ liệu sẽ được đặt ở đâu”. Singapore hay Tokyo, dù chọn nơi nào thì cũng là ngoài lãnh thổ Thái Lan. Bộ phận hệ thống thông tin của trụ sở chính chuyển câu hỏi về việc chuyển dữ liệu ra nước ngoài sang bộ phận pháp chế, pháp chế lại yêu cầu thêm căn cứ để phán đoán, và dự án đứng yên vài tháng tại đó. Đây là hình ảnh tiêu chuẩn của mấy năm gần đây.

Năm 2026, tiền đề này đã thay đổi. Bởi vì lần đầu tiên, việc đặt dữ liệu bên trong lãnh thổ Thái Lan trở thành một lựa chọn tiêu chuẩn.

Ý nghĩa của việc các region đã hội tụ tại Bangkok

Hãy sắp xếp lại các sự kiện. AWS (Amazon Web Services, Amazon.com) đã đưa region Asia Pacific (Thailand) (ap-southeast-7, cấu hình 3 availability zone) vào cung cấp rộng rãi từ ngày 8 tháng 1 năm 2025. Google Cloud (Google) đã khai trương region Bangkok (cấu hình 3 availability zone) vào ngày 21 tháng 1 năm 2026 và công bố khoản đầu tư quy mô 1 tỷ USD. Region Thái Lan (Thailand South) của Microsoft Azure (Microsoft) hiện mới ở giai đoạn tuyên bố kế hoạch khai trương, và tháng 10 năm 2025 đã công bố sẽ dùng True IDC (True Corporation) làm một trong các availability zone.

Khác biệt về tình trạng của ba nhà cung cấp này chuyển thẳng thành khác biệt trong cách tiến hành xem xét. Một nền tảng đã cung cấp rộng rãi và một nền tảng mới tuyên bố kế hoạch khai trương cho phép bạn viết những nội dung khác nhau trong tờ trình phê duyệt nội bộ. Nếu trụ sở chính đặt điều kiện “dữ liệu phải nằm trong lãnh thổ Thái Lan”, thì ở thời điểm hiện tại chỉ nhóm thứ nhất mới đáp ứng được điều kiện đó. Nếu bạn lập kế hoạch dựa trên nhóm thứ hai, bạn sẽ phải viết kế hoạch chuyển đổi trên một tiền đề chưa xác định thời điểm khai trương, và điểm đó cần được nêu rõ như một rủi ro của kế hoạch.

Một điểm nữa có ý nghĩa lớn về mặt thực tế là việc có ba availability zone. Với một trung tâm dữ liệu kiểu cơ sở đơn lẻ chỉ có một zone, sự cố nguồn điện hoặc điều hòa sẽ trực tiếp trở thành sự cố ngừng dịch vụ. Với cấu hình ba zone, bạn có thể bố trí cơ sở dữ liệu trải trên nhiều zone và chuyển đổi tự động khi một bên gặp sự cố. Đây là câu chuyện ở mức hoàn toàn khác với việc đặt hai máy chủ trong nhà máy của mình để làm dự phòng. Dự phòng trong nhà máy không thắng nổi mất điện toàn nhà xưởng và ngập lụt.

Tuy vậy, xin đừng vội kết luận ở đây. Không phải là “vì đã có region trong lãnh thổ Thái Lan nên có thể đưa tất cả lên đám mây”. Thứ thay đổi chỉ là ràng buộc về vị trí lưu dữ liệu đã được gỡ bỏ, còn các ràng buộc khác thì không thay đổi gì cả.

Vì sao “đưa tất cả lên đám mây” vẫn không phải là câu trả lời

Điều hay xảy ra khi một ràng buộc được gỡ bỏ là người ta tưởng rằng các ràng buộc còn lại cũng biến mất theo. Trên thực tế, vẫn còn ba vấn đề mà việc có region trong nước không giải quyết được.

Thứ nhất là đường truyền tính từ nhà máy trở đi. Dù trung tâm dữ liệu nằm ở Bangkok, đoạn từ nhà máy tới đó vẫn đi qua đường truyền của nhà cung cấp viễn thông. Thi công, mất điện, hỏng thiết bị, và các sự cố vật lý trong mùa mưa. Đoạn này thuộc phạm vi trách nhiệm của chính doanh nghiệp, bất kể region nằm ở đâu. Cho dù phía đám mây công bố tỷ lệ vận hành dịch vụ là 99,9%, nếu đường truyền dẫn tới đó bị đứt thì khả dụng nhìn từ nhà máy bằng không.

Thứ hai là cấu trúc chi phí trở nên khó đọc hơn. Theo khảo sát “Xu hướng IT doanh nghiệp 2026” của JUAS, lý do làm tăng ngân sách IT nhiều nhất là “cập nhật, sửa chữa, mở rộng hệ thống hiện có” với 66,3%, tiếp theo là “ảnh hưởng của đồng yên yếu, chi phí nhân công tăng và nhà cung cấp tăng giá” với 46,6%, “gia tăng dịch vụ đám mây” với 45,0% và “tăng chi phí đầu tư cùng chi phí sử dụng liên quan tới AI” với 43,7% (tăng 7,4 điểm phần trăm so với 36,3% của năm trước). Việc gia tăng đám mây nằm trong nhóm lý do hàng đầu làm tăng ngân sách cho thấy tiền đề “chuyển lên đám mây thì rẻ hơn” đang sụp đổ ngay tại hiện trường.

Thứ ba là hiện tượng quay ngược trở lại sau khi đã dồn lên đám mây đang thực sự diễn ra. Theo tổng hợp về việc rút khỏi đám mây (cloud repatriation), báo cáo 2025 State of the Cloud của Flexera cho biết đã có 21% khối lượng công việc hoặc dữ liệu được đưa ngược trở lại, và 84% nêu “kiểm soát chi tiêu cho đám mây” là thách thức lớn nhất. Khảo sát của IDC cho thấy năm 2024 có 59% tổ chức vượt ngân sách. Tuy nhiên, cũng theo khảo sát của IDC tại thời điểm tháng 10 năm 2024, số tổ chức rút toàn bộ khối lượng công việc chỉ dừng ở khoảng 8%, phần lớn là rút về một cách có chọn lọc.

Phần “phần lớn là có chọn lọc” này chính là luận điểm của bài viết. Các doanh nghiệp đang rút về cũng không rút toàn bộ. Họ chỉ đưa ngược lại những chức năng không phù hợp. Nếu vậy, ngay từ đầu hãy quyết định vị trí đặt theo từng chức năng. Chính cách đặt câu hỏi “đám mây hay on-premise” cho toàn bộ hệ thống là sai.

Hệ thống quản lý sản xuất không phải là một chức năng đơn lẻ. Phát hành tem nhãn, phân bổ tồn kho, nhập kết quả sản xuất, quản lý dữ liệu master, mua hàng, tổng hợp giá thành. Những chức năng này khác nhau cả về tốc độ phản hồi được yêu cầu, thiệt hại khi ngừng, lẫn tính chất dữ liệu mà chúng xử lý. Chính vì cố đưa ra một câu trả lời duy nhất cho những thứ khác nhau nên mới không quyết định được.

Khác biệt giữa hệ thống quản lý sản xuất đám mây và on-premise nằm ở thời gian ngừng có thể chấp nhận, không phải chi phí

Vậy nếu quyết định theo từng chức năng thì lấy gì làm chuẩn để phân loại? Không phải chi phí. Đó là thời gian ngừng có thể chấp nhận, tức là RTO (Recovery Time Objective, mục tiêu thời gian khôi phục).

Lý do sẽ được chỉ ra ở phần tính toán phía sau, nhưng xin viết trước kết luận. Với quy mô nhà máy như thế này, nếu lấy chi phí làm tiêu chí thì đám mây hầu như luôn thắng. Hơn nữa, khoảng cách đó chỉ đảo chiều sau hơn 10 năm. Vì khoảng cách này không nằm trong kỳ đánh giá đầu tư thông thường là 5 – 7 năm, chi phí không hoạt động được như một tiêu chí. Chính vì đang tranh luận bằng một tiêu chí không hoạt động nên cuộc họp mới không kết thúc.

Thời gian ngừng có thể chấp nhận theo từng chức năng

Thời gian ngừng có thể chấp nhận, tức thời gian tối đa mà một chức năng được phép ngừng hoạt động, không phải thứ bộ phận hệ thống thông tin ngồi bàn giấy quyết định. Nó do chính hiện trường thực sự gặp khó khăn khi hệ thống ngừng quyết định. Dưới đây là các mức điển hình khi chúng tôi thực tế sắp xếp cùng các nhà máy Nhật Bản tại Thái Lan. Giá trị của công ty bạn nhất định phải được điền lại cùng với hiện trường.

Nhìn bảng này có thể thấy trong cùng một “hệ thống quản lý sản xuất” đang cùng tồn tại chức năng chỉ được phép ngừng 5 – 15 phút và chức năng có ngừng 3 ngày làm việc thì công việc vẫn chạy. Khoảng cách là vài trăm lần.

Vì sao phát hành tem nhãn lại ngắn tới vậy? Vì nếu không dán được tem lên thành phẩm thì món hàng đó về mặt vật lý không thể chuyển sang công đoạn tiếp theo. Chỉ còn cách chất vào khu vực để tạm, và khi khu vực để tạm đầy thì chính hoạt động sản xuất phải dừng. Hơn nữa, công việc dán lại về sau còn cộng thêm số giờ công để xác định món nào thuộc lô nào. Có trường hợp 15 phút ngừng biến thành vài giờ làm lại vào ngày hôm sau.

Ngược lại, tổng hợp giá thành dù không tổng hợp được trong ngày thì hôm sau vẫn xử lý gộp được. Trừ giai đoạn ngay trước khi chốt tháng, việc ngừng 3 ngày làm việc không làm dừng công việc. Đầu tư cho chức năng này mức khả dụng ngang với phát hành tem nhãn là quá mức cần thiết.

Cùng với RTO, hãy quyết định theo từng chức năng cả RPO (Recovery Point Objective, mục tiêu điểm khôi phục, tức mức mất dữ liệu có thể chấp nhận). Nhập kết quả sản xuất có RPO ngắn, vì nếu 30 phút nhập liệu ngay trước đó biến mất thì không ai tái hiện lại được. Ngược lại, với cập nhật dữ liệu master, dù bản cập nhật ngay trước đó biến mất thì người đăng ký vẫn nhớ nên nhập lại được. Cách tư duy về hai chỉ số này và cách đưa chúng vào thiết kế thực tế đã được xử lý trong bài viết sắp xếp cơ chế sao lưu hệ thống nghiệp vụ theo RTO và RPO, xin hãy đọc qua trước khi điền bảng trong nội bộ.

Đặt một RTO duy nhất cho toàn hệ thống sẽ đồng thời gây đầu tư thừa và thiếu hụt

Điều thường thấy tại hiện trường là tài liệu định nghĩa yêu cầu chỉ viết đúng một dòng “RTO của toàn hệ thống: 4 giờ”. Một dòng này gây ra hai thất bại cùng lúc.

Thứ nhất là đầu tư thừa. RTO 4 giờ là quá khắt khe đối với tổng hợp giá thành hay mua hàng. Nếu chuẩn bị cơ chế khôi phục trong 4 giờ cho những chức năng chỉ cần 3 ngày làm việc, thì toàn bộ chi phí dự phòng và số giờ công vận hành tương ứng đều lãng phí. Hơn nữa, sự lãng phí này không nhìn thấy được bằng số tiền, vì nó bị vùi trong một hạng mục mang tên “vì tính khả dụng của toàn hệ thống”.

Thứ hai là thiếu hụt. RTO 4 giờ lại quá lỏng đối với phát hành tem nhãn. Nếu thiết kế 4 giờ cho một chức năng chỉ được phép ngừng 5 – 15 phút, thì khi sự cố thực sự xảy ra, hiện trường sẽ không làm được gì trong 3 giờ 45 phút. Và chỉ khi sự cố xảy ra người ta mới hiểu ra rằng “cái này không thể chờ tới 4 giờ”. Lúc đó, chi phí thiết kế lại sẽ gấp nhiều lần so với khi xây dựng ban đầu.

Đặt một RTO duy nhất cho toàn hệ thống là một quyết định trượt về cả hai hướng: bỏ qua yêu cầu của chức năng khắt khe nhất và đầu tư quá mức cho chức năng lỏng nhất. Thứ cần viết không phải một dòng, mà là số dòng bằng đúng số chức năng.

Ngoài ra, công việc này không thể hoàn tất chỉ bởi bộ phận hệ thống thông tin. Người trả lời được câu hỏi “nếu phát hành tem nhãn ngừng 15 phút thì điều gì xảy ra” là bộ phận sản xuất, còn người trả lời được “trong trạng thái đó chúng ta cầm cự được bao nhiêu phút” là giám đốc nhà máy. Hãy để hai bên này cùng ngồi trong buổi định nghĩa yêu cầu đầu tiên. Những dự án tiến hành mà không cho hai bên cùng ngồi sẽ ra sao về sau đã được sắp xếp trong bài viết về các mẫu thất bại điển hình khi triển khai hệ thống quản lý sản xuất.

Thứ ngừng đầu tiên khi chuyển lên đám mây không phải máy chủ mà là xác thực

Từ đây mới vào phần chính. Giả sử bạn đã lập được bảng RTO theo từng chức năng, bảng đó vẫn có một chỗ thiếu mang tính quyết định. Xác thực không có trong bảng.

Xác thực không được nhận diện như một “chức năng”. Nó không xuất hiện trong danh sách chức năng nghiệp vụ, không được vẽ trong sơ đồ luồng nghiệp vụ, và do đó cũng không được gán RTO. Nhưng trên thực tế, nó nằm phía trước cả sáu chức năng trong bảng vừa rồi. Nếu không đăng nhập được thì tem nhãn cũng không ra, kết quả sản xuất cũng không nhập được.

Nói cách khác, RTO của xác thực phải khớp với giá trị ngắn nhất trong bảng. Nếu phát hành tem nhãn là 5 – 15 phút thì RTO của xác thực cũng là 5 – 15 phút. Vì điều này bị bỏ sót khỏi thiết kế, sự cố đầu tiên sau khi chuyển lên đám mây hầu như không có ngoại lệ đều xảy ra ở xác thực.

Ba cấu hình xác thực và hành vi khi mất đường truyền

Khi đưa hệ thống quản lý sản xuất lên đám mây, cấu hình xác thực trên thực tế chia thành ba dạng. Mỗi dạng có hành vi khác nhau khi đường truyền nối nhà máy với bên ngoài bị đứt.

Cấu hình 1: chỉ dùng IdP trên đám mây. Đây là cấu hình xác thực bằng nhà cung cấp danh tính trên đám mây như Microsoft Entra ID (Microsoft) hay Google Workspace (Google), và không đặt domain controller ở phía on-premise. Vận hành nhẹ nhất. Nhưng khi đường truyền đứt, không ai trong nhà máy đăng nhập được. Các phiên đã đăng nhập vẫn chạy cho tới khi access token hết hạn, nhưng sẽ dừng ngay khi hết hạn. Nếu thời hạn hiệu lực là 1 giờ thì trong vòng tối đa 1 giờ kể từ lúc mất đường truyền, toàn bộ thiết bị sẽ lần lượt rơi rụng. Điều phiền phức là không phải tất cả cùng rơi một lúc. Vì thời điểm rơi khác nhau, hiện trường sẽ nhận định là “hệ thống không ổn định” chứ không phải “đường truyền bị đứt”. Việc khoanh vùng nguyên nhân vì thế bị chậm.

Cấu hình 2: AD on-premise kết hợp liên kết lên đám mây. Đây là cấu hình đặt Active Directory (Microsoft) trong nhà máy và liên kết xác thực lên phía đám mây. Hành vi sẽ ngược hẳn nhau giữa trường hợp dùng đồng bộ password hash và trường hợp dùng federation (phương thức chuyển yêu cầu xác thực về phía on-premise). Với đồng bộ password hash, dù AD on-premise sập thì việc xác thực vẫn hoàn tất chỉ bằng phía đám mây. Với federation, ngay khi nền tảng xác thực phía on-premise sập thì việc đăng nhập vào dịch vụ đám mây cũng dừng. Khác biệt này hầu như không phân biệt được qua vẻ ngoài của sơ đồ cấu hình. Nếu đề xuất của nhà cung cấp chỉ ghi “liên kết với AD”, nhất định phải hỏi rõ là dạng nào.

Cấu hình 3: chỉ dùng AD on-premise. Đây là cấu hình mà ứng dụng phía đám mây cũng chỉ được dùng từ các thiết bị đã tham gia domain của AD on-premise. Dù đường truyền đứt thì việc đăng nhập trong nhà máy vẫn thông, nhưng đương nhiên không kết nối được tới ứng dụng trên đám mây. Đó là trạng thái xác thực còn sống nhưng ứng dụng đã chết, và nhìn từ hiện trường thì không phân biệt được với cấu hình 1.

Ngoài ba cấu hình này, còn cần kiểm tra cả nơi mà xác thực đa yếu tố (MFA) phụ thuộc vào. Với cách vận hành xác nhận yếu tố thứ hai bằng ứng dụng xác thực hoặc SMS, dù đường truyền của nhà máy còn sống mà sóng di động trục trặc thì xác thực vẫn không thông. Tính khả dụng của xác thực không chỉ được quyết định bởi mạng nội bộ.

Phát hành tem nhãn và nhập kết quả sản xuất dừng lại ngay ở bước đăng nhập

Xin viết cụ thể điều gì sẽ xảy ra.

7 giờ 30 sáng, hiện trường bắt đầu ca làm. Người ta bật nguồn máy quét cầm tay, công nhân quẹt thẻ ID. Và xác thực không thông. Nguyên nhân là thiết bị phía đường truyền đã hỏng từ đêm hôm trước. Máy chủ vẫn chạy. Ứng dụng vẫn chạy. Dữ liệu vẫn nguyên vẹn. Nhưng không ai đăng nhập được.

Hành động đầu tiên mà hiện trường thực hiện lúc này, trong phần lớn trường hợp, là “ghi ra giấy”. Bản thân cách xử lý đó là đúng. Vấn đề nằm ở số giờ công để nhập lại sau đó những kết quả đã ghi trên giấy, và ở những tem nhãn không phát hành được trong khoảng thời gian đó. Không có tem nhãn thì thành phẩm phải nằm ở khu vực để tạm. Buổi sáng khu vực để tạm đầy, tới buổi chiều phải ra quyết định có dừng sản xuất hay không.

Và sau khi khôi phục còn một cửa ải nữa. Khi nhập bù 3 giờ kết quả đã ghi trên giấy, thời điểm ghi nhận dễ trở thành thời điểm nhập liệu cho toàn bộ bản ghi. Dữ liệu thời gian của tiến độ công đoạn lệch 3 giờ, và phân tích thời gian sản xuất của ngày hôm đó trở nên không dùng được. Việc thiếu dữ liệu của một ngày còn đỡ phiền hơn việc có thêm dữ liệu sai của một ngày.

Điều muốn xác nhận ở đây là nguyên nhân của sự cố này không nằm ở hệ thống quản lý sản xuất. Không phải do chọn sai gói phần mềm, cũng không phải do cấu hình máy chủ thiếu năng lực. Chỉ đơn giản là xác thực đã không được gán RTO. Dù bạn dành bao nhiêu thời gian để so sánh tính năng của các gói phần mềm, thất bại này cũng không ngăn được. Về các trục so sánh của bản thân gói phần mềm, chúng tôi đã tổng hợp trong bài viết so sánh hệ thống quản lý sản xuất, nhưng hãy tiến hành thiết kế xác thực song song với việc lựa chọn.

Bốn thiết kế để xác thực không sập

Có bốn biện pháp. Không cần kỹ thuật đặc biệt. Chỉ cần quyết định những thứ cần quyết định.

1. Ghi rõ RTO cho xác thực và khớp với chức năng ngắn nhất. Hãy viết một dòng “RTO của xác thực: 15 phút” vào tài liệu định nghĩa yêu cầu. Chỉ vậy thôi cũng làm nội dung đề xuất của nhà cung cấp thay đổi. Nhà cung cấp bị yêu cầu thiết kế xác thực khôi phục trong 15 phút sẽ không thể đưa ra cấu hình dồn hết vào một IdP duy nhất. Ngược lại, nếu thiếu dòng này thì việc xây dựng sẽ kết thúc mà xác thực không thuộc phạm vi trách nhiệm của ai cả.

2. Nhân đôi đường xác thực. Hãy tạo trạng thái mà dù phía đám mây hay phía on-premise sập một bên thì bên còn lại vẫn cho xác thực thông. Đồng bộ password hash nói ở trên là một ví dụ. Điều quan trọng không phải “đã nhân đôi” mà là “đã thực tế cho sập một bên và xác nhận vẫn thông”. Mỗi năm một lần, hãy lấy một cửa sổ dừng theo kế hoạch và thực hiện diễn tập chuyển đổi dự phòng. Một cấu hình dự phòng chưa được kiểm chứng thì không phải là dự phòng.

3. Thiết kế thời hạn hiệu lực của token và cache theo từng chức năng. Không nhất thiết phải đặt cùng một cấu hình cho thiết bị hiện trường và thiết bị văn phòng. Máy quét cầm tay ở hiện trường là thiết bị chỉ được dùng bởi những công nhân cố định tại những vị trí cố định. Ở đây hãy đặt thời hạn hiệu lực của token dài hơn để thiết bị vẫn chạy được một khoảng thời gian nhất định khi mất đường truyền. Ngược lại, thiết bị văn phòng vốn có thể truy cập cả từ bên ngoài công ty thì đặt ngắn lại. Sự cân bằng giữa an ninh và khả dụng được thiết lập theo đơn vị thiết bị và chức năng, chứ không theo đơn vị hệ thống.

4. Chuẩn bị phương án dự phòng xác thực ngoại tuyến cho thiết bị hiện trường. Chỉ trong lúc đường truyền bị đứt, hãy cho phép xác thực bằng thông tin đăng nhập được lưu cache tại thiết bị hoặc bằng thẻ IC, để riêng phát hành tem nhãn và nhập kết quả sản xuất có thể tiếp tục. Đồng thời, hãy chuẩn bị tài khoản quản trị chỉ dùng trong tình huống khẩn cấp (tài khoản break glass) cùng phương án thay thế khi không dùng được MFA, và giữ trạng thái mà từ hai người trở lên gồm giám đốc nhà máy và phụ trách hệ thống thông tin đều nắm được sự tồn tại cũng như nơi lưu giữ chúng. Một tài khoản chỉ một người biết sẽ không hoạt động vào đúng ngày người đó nghỉ.

Yếu tố quyết định không phải băng thông mà là số lần khứ hồi | Mức độ hợp nhau giữa máy quét cầm tay và đám mây

Sau xác thực, câu hỏi thường gặp thứ hai là “chuyển lên đám mây thì hiện trường có chậm đi không”. Ở đây cũng vậy, chỗ mà người ta đang nhìn thường bị lệch.

Vấn đề 5 lần khứ hồi cho một lần quét

Trước hết hãy sắp xếp các con số tham chiếu về độ trễ. Các con số dưới đây chỉ là con số tham khảo thường được quan sát thấy, không phải giá trị xác định. Nhất định phải tự đo trên đường truyền của nhà máy mình. Ngay trong cùng khu vực lân cận Bangkok, con số cũng thay đổi lớn tùy loại đường truyền đã ký hợp đồng và tùy tuyến đi.

Nhìn con số này rồi nghĩ rằng “70 ms thì con người không nhận ra được” chính là sai lầm đầu tiên. Vấn đề không nằm ở một lần trễ, mà ở chỗ một thao tác phát sinh bao nhiêu lần truyền thông.

Khi máy quét cầm tay quét một lần mã vạch trên phiếu hiện vật, bên trong hệ thống phát sinh nhiều lượt truyền thông. Điển hình là kiểm tra token xác thực, tra cứu master mã hàng, phân bổ tồn kho, đăng ký kết quả sản xuất và yêu cầu in tem nhãn. Tùy cách hiện thực, chừng đó là 5 lần khứ hồi.

Trường hợp đặt tại region Tokyo, nếu lấy con số tham khảo về RTT là 80 ms thì riêng phần khứ hồi đã cộng thêm 5 × 80 ms = 0,4 giây. Thời gian xử lý của máy chủ còn cộng thêm riêng. Với region trong lãnh thổ Thái Lan tại Bangkok, lấy con số tham khảo 10 ms thì là 5 × 10 ms = 0,05 giây. Cùng một cách hiện thực, chỉ riêng vị trí đặt đã tạo ra khoảng cách 0,35 giây.

Bạn có cảm thấy 0,4 giây là “không đáng kể” hay không phụ thuộc vào số lần. Giả sử một hiện trường quét 1.000 lần mỗi ngày, thì riêng phần khứ hồi đã là 0,4 giây × 1.000 lần = 400 giây, tức khoảng 6,7 phút. Hơn nữa đây là thời gian chờ, nên trong khoảng đó công nhân đứng yên với máy quét cầm tay trên tay.

Điểm quan trọng ở đây là tăng băng thông cũng không cải thiện được con số này. Độ trễ khứ hồi được quyết định bởi tốc độ ánh sáng và độ dài tuyến đi, nên nâng từ 100 Mbps lên 1 Gbps cũng không thay đổi. Chỉ có hai cách cải thiện: rút ngắn khoảng cách (dùng region trong nước) hoặc giảm số lần khứ hồi.

Do đó, điều cần hỏi nhà cung cấp không phải “cần đường truyền bao nhiêu Mbps”. Mà là “với mỗi lần thực hiện một thao tác chính tại hiện trường, phát sinh bao nhiêu lần khứ hồi tới máy chủ”. Không nhiều nhà cung cấp trả lời ngay được câu hỏi này. Nếu họ không trả lời được, hãy yêu cầu đo thực tế trong PoC (kiểm chứng). Chỉ cần xuất log ở phía máy quét cầm tay là đo được.

Ngoài ra, số lần khứ hồi được quyết định bởi triết lý thiết kế của gói phần mềm nên giảm về sau không dễ. Các cải tiến kiểu “đọc trước gộp dữ liệu master khi quét” hay “đăng ký kết quả sản xuất theo cơ chế bất đồng bộ” là khả thi, nhưng đều là phát triển bổ sung. Đây là hạng mục cần xác nhận ở giai đoạn lựa chọn.

Đặt bộ đệm ngoại tuyến ở đâu

Dù có giảm số lần khứ hồi thì khi đường truyền đứt, số lần khứ hồi cũng thành không. Cần thiết kế trước xem trong lúc đứt thì làm được những gì.

Có ba lựa chọn về nơi đặt.

Đặt tại thiết bị. Ứng dụng trên máy quét cầm tay giữ một cơ sở dữ liệu cục bộ, ghi vào đó trong lúc mất đường truyền và đồng bộ sau khi khôi phục. Không cần phần cứng bổ sung nên rẻ nhất. Điểm yếu là nếu làm mất hoặc làm hỏng thiết bị thì dữ liệu chưa đồng bộ của thiết bị đó biến mất, và không giữ được tính nhất quán tồn kho giữa nhiều thiết bị. Cách này không phù hợp với các xử lý cần kiểm soát loại trừ như phân bổ tồn kho.

Đặt tại máy chủ biên trong nhà máy. Đặt một máy chủ nhỏ trong nhà máy, giao cho nó việc nhân bản dữ liệu master, in tem nhãn và tiếp nhận tạm thời kết quả sản xuất. Thiết bị luôn giao tiếp với máy chủ biên này, còn máy chủ biên đồng bộ với đám mây. Vì trong lúc mất đường truyền vẫn giữ được tính nhất quán giữa nhiều thiết bị bên trong nhà máy, có thể duy trì cả phân bổ tồn kho. Đây chính là hạt nhân của cấu hình lai sẽ nói ở phần sau. Điểm yếu là một máy chủ này trở thành điểm lỗi đơn, và cần phát triển bổ sung phần logic đồng bộ.

Đặt tại máy in. Nếu chỉ giới hạn ở phát hành tem nhãn, có thể chọn cấu hình cho máy in tem giữ mẫu in và dữ liệu phát hành gần nhất, để trong lúc mất đường truyền thiết bị ra lệnh in thẳng tới máy in. Đây là cách rẻ nhất để bảo vệ đúng chức năng có RTO ngắn nhất. Tuy nhiên, nếu không quyết định trước quy trình đưa thông tin của các tem đã phát hành vào hệ thống sau đó, bạn sẽ không truy vết được việc phát hành trùng.

Chọn cách nào thì cuối cùng vẫn quay lại bảng RTO. Nếu phát hành tem nhãn là 5 – 15 phút thì cấu hình có thể mất từ 15 phút trở lên để khôi phục là không đủ. Nếu nhập kết quả sản xuất là 2 – 4 giờ thì bộ đệm phía thiết bị có thể đã đủ. Vì câu trả lời khác nhau theo từng chức năng, ở đây cũng quyết định theo “làm thế nào cho từng chức năng” chứ không phải “làm thế nào cho cả hệ thống”.

So sánh 5 năm chi phí hệ thống quản lý sản xuất đám mây và on-premise (tính toán riêng)

Chúng tôi đã viết ở trên rằng chi phí không hoạt động được như một tiêu chí. Để chỉ ra điều đó, hãy tính toán thực tế. Dưới đây là mô hình đơn giản hóa từ các tiền đề mà chúng tôi dùng trong các dự án tại nhà máy Nhật Bản ở Thái Lan, không phải con số của một công ty có thật. Hãy thay bằng báo giá của công ty bạn khi sử dụng.

Ngoài ra, trong phần tính toán này chúng tôi hoàn toàn không tính giá trị hiệu quả tiết kiệm, ROI hay số năm hoàn vốn. Chỉ thực hiện so sánh chi phí. Lý do là chênh lệch tiền đề giữa các nhà máy quá lớn, nên trình bày giá trị hiệu quả bằng một mô hình sẽ dễ gây hiểu nhầm.

Tiền đề của nhà máy mẫu

• Địa điểm: vùng lân cận Bangkok, một cơ sở duy nhất, có trụ sở chính tại Nhật Bản
• Nhân sự: 180 người
• Người dùng hệ thống quản lý sản xuất: 40 người (25 người văn phòng và 15 người tại hiện trường)
• Thiết bị hiện trường: 15 máy quét cầm tay và 10 máy tính bảng
• Tiền tệ: THB (baht Thái)
• Kỳ so sánh: 5 năm

Chi phí thiết bị hiện trường (750.000 THB) được tính cùng một mức cho cả ba kịch bản. Bởi dù chọn đám mây hay on-premise thì hiện trường vẫn cần thiết bị để dùng. Chúng tôi vẫn gặp những bản báo giá chỉ tính khoản này cho một bên, nhưng như vậy thì không thành so sánh.

Tổng chi phí 5 năm của ba kịch bản

Kịch bản A: đám mây toàn phần (SaaS)

Chi phí vận hành 5 năm: 4.320.000 + 720.000 + 1.500.000 = 6.540.000 THB

Tổng 5 năm: 9.210.000 THB

Kịch bản B: on-premise toàn phần

Chi phí vận hành 5 năm: 3.000.000 + 1.500.000 = 4.500.000 THB

Tổng 5 năm: 11.280.000 THB

Kịch bản C: lai (nhóm chức năng hiện trường đặt on-premise, nhóm chức năng quản lý đặt trên đám mây)

Chi phí vận hành 5 năm: 2.700.000 + 720.000 + 1.400.000 + 2.000.000 = 6.820.000 THB

Tổng 5 năm: 11.650.000 THB

Xếp ba kịch bản cạnh nhau.

Chênh lệch như sau.

• B trừ A = 2.070.000 THB (on-premise đắt hơn đám mây 2.070.000 THB trong 5 năm)
• C trừ A = 2.440.000 THB
• C trừ B = 370.000 THB

Có ba điểm cần đọc ra.

Thứ nhất, xét trong 5 năm thì đám mây rẻ nhất. Khoảng cách là 2.070.000 THB, không lớn bằng chênh lệch chi phí ban đầu (6.780.000 trừ 2.670.000 = 4.110.000), nhưng cũng không phải khoản có thể bỏ qua.

Thứ hai, kịch bản C lai lại là đắt nhất. Đây chính là chỗ bị lật ngược trong nhiều cuộc họp. Người ta hay nghĩ cấu hình lai “nằm giữa đám mây và on-premise nên chi phí cũng ở giữa”, nhưng thực tế nó gánh cả chi phí ban đầu của cả hai lẫn chi phí vận hành của cả hai. Máy chủ biên, bản quyền SaaS, dự phòng đường truyền đều cần cả. Phần thiết kế liên kết làm tăng thêm cả hỗ trợ triển khai lẫn phát triển bổ sung. Kết quả là đắt hơn đám mây toàn phần 2.440.000 THB và đắt hơn on-premise toàn phần 370.000 THB.

Thứ ba, chênh lệch giữa ba phương án này, xét trên tổng chi phí 5 năm, vẫn nằm trong cùng một bậc độ lớn. Khoảng cách giữa 9.210.000 và 11.650.000 không phải chênh lệch tới mức lật ngược quyết định ngay lập tức. Chính vì vậy mới cần một tiêu chí khác ngoài chi phí.

Điểm đảo chiều chi phí là 10,1 năm, tính thêm thay mới phần cứng là 13,4 năm

Phương án on-premise vốn có chi phí ban đầu cao và chi phí hàng năm thấp, nên nếu kéo dài kỳ tính toán thì chắc chắn sẽ xuống dưới đám mây. Vậy là vào năm thứ mấy?

Công thức chi phí lũy kế như sau (n là số năm).

• Lũy kế A = 2.670.000 + 1.308.000n
• Lũy kế B = 6.780.000 + 900.000n

Chênh lệch chi phí hàng năm là 1.308.000 trừ 900.000 = 408.000. Chênh lệch chi phí ban đầu là 4.110.000. Đẳng thức thành lập khi 408.000n = 4.110.000, tức là n = 10,1 năm.

Kiểm tra lại. Khi n = 5 thì A = 9.210.000 và B = 11.280.000. Khi n = 10 thì A = 15.750.000 và B = 15.780.000. Có thể xác nhận rằng tới năm thứ 10 B vẫn cao hơn, và ngay sau đó thì đảo chiều.

Vào đây hãy cộng thêm một khoản chi phí chắc chắn phát sinh trên thực tế. Đó là thay mới phần cứng và OS. Máy chủ hết bảo trì sau 5 năm, và OS cũng có hạn hỗ trợ. Nếu vào năm thứ 6 cộng một lần khoản 900.000 cho máy chủ và 450.000 cho bản quyền OS và cơ sở dữ liệu, tổng cộng 1.350.000 THB, thì

• Lũy kế B = 8.130.000 + 900.000n
• 408.000n = 5.460.000 nên n = 13,4 năm

Là 13,4 năm. Ý nghĩa của con số này rất rõ ràng. Thông thường, đầu tư hệ thống của nhà máy được đánh giá trong 5 năm, dài nhất là 7 năm. Một chênh lệch chi phí đảo chiều vào năm thứ 13,4 không nằm trong kỳ ra quyết định đầu tư. Nói cách khác, so sánh đám mây và on-premise bằng chi phí thì với quy mô này sẽ không ra được câu trả lời. Không ra được mà vẫn tranh luận, nên cuộc họp mới không kết thúc.

Xin nói thêm cho chắc, đây không phải luận điểm “đám mây rẻ nên hãy chọn đám mây”. Ngược lại. Đây là luận điểm rằng nếu dù 5 năm hay 10 năm chênh lệch cũng không mang tính quyết định, thì nên loại chi phí ra khỏi các căn cứ phán đoán. Sau khi loại ra rồi thì quyết định bằng thời gian ngừng có thể chấp nhận.

Nếu xét theo mốc 5 năm thì thứ đảo chiều không phải số năm mà là số người dùng (khoảng 59 người)

Còn một trục nữa liên quan tới chi phí thường bị bỏ sót. Đó là số người dùng.

Bản quyền của kịch bản A tính theo lượng sử dụng với mức 1.800 THB một người một tháng. Người dùng tăng thì chi phí tăng theo tỷ lệ. Bản quyền mua đứt của on-premise thì tới một mức nhất định, dù số người tăng, tổng tiền vẫn không đổi. Do đó, nếu nhìn theo kỳ cố định 5 năm thì việc đảo chiều xảy ra theo số người chứ không theo số năm.

Khi số người dùng là u, tổng chi phí 5 năm của kịch bản A như sau.

Tổng 5 năm của A = 4.890.000 + 108.000u

Chi tiết là ban đầu 2.670.000 cộng với 5 năm nhân (bản quyền hàng năm 21.600u cộng đường truyền 144.000 cộng phát triển bổ sung 300.000), tức 2.670.000 + 108.000u + 2.220.000.

Con số này ngang bằng 11.280.000 của kịch bản B khi 108.000u = 6.390.000, tức là khi u xấp xỉ 59 người.

Kiểm tra lại. Khi u = 40 thì bằng 9.210.000 (khớp với kịch bản A). Khi u = 70 thì bằng 12.450.000, vượt qua 11.280.000 của kịch bản B.

Ý nghĩa thực tiễn rất lớn. Nhà máy mẫu này có 40 người dùng, nhưng số người dùng hệ thống quản lý sản xuất sẽ tăng sau khi đưa vào vận hành. Thêm bộ phận chất lượng, thêm mua hàng, thêm người từ trụ sở chính Nhật Bản truy cập để tham chiếu, mở một phần cho nhà thầu phụ. Chuyện một hệ thống ký hợp đồng cho 40 người trở thành 70 người sau ba năm là bình thường.

Vì vậy, nếu lấy chi phí làm tiêu chí thì thứ cần nhìn không phải “bao nhiêu năm thì đảo chiều” mà là “bao nhiêu người thì đảo chiều, và sau 5 năm công ty mình sẽ có bao nhiêu người dùng“. Sau khi đưa ra con số 59 người, hãy xác nhận với ban lãnh đạo con số người dùng dự kiến sau 5 năm. Nếu có triển vọng vượt rõ rệt mức 59 người, hãy dùng việc đàm phán về cơ cấu bản quyền (gói cố định theo bậc số người, phân loại giá rẻ cho người dùng chỉ xem) làm quân bài đàm phán ở giai đoạn lựa chọn. Cuộc đàm phán này không thực hiện được sau khi đã ký hợp đồng.

Vị trí lưu dữ liệu tại cơ sở Thái Lan và PDPA | Khi nào chuyển ra nước ngoài thành vấn đề và khi nào không

Quay lại câu chuyện vị trí lưu dữ liệu. Việc các region hội tụ tại Bangkok làm tăng lựa chọn, nhưng trước hết cần sắp xếp xem trong dữ liệu của hệ thống quản lý sản xuất, phần nào mới thuộc đối tượng điều chỉnh.

Về PDPA của Thái Lan (luật bảo vệ dữ liệu cá nhân), các quy định liên quan tới chuyển dữ liệu ra nước ngoài (thông báo về danh sách trắng và thông báo về BCR cùng các biện pháp bảo vệ phù hợp) đã có hiệu lực từ ngày 24 tháng 3 năm 2024. Có ba căn cứ chuyển dữ liệu: một là chuyển tới quốc gia được công nhận mức bảo vệ đầy đủ, hai là BCR (quy tắc doanh nghiệp ràng buộc), ba là các biện pháp bảo vệ phù hợp như điều khoản hợp đồng tiêu chuẩn.

Và điều quan trọng trên thực tế là tính tới năm 2025, PDPC (ủy ban bảo vệ dữ liệu cá nhân) vẫn chưa công bố danh sách các quốc gia được công nhận mức bảo vệ đầy đủ. Do đó, trước mắt mọi hoạt động chuyển dữ liệu ra nước ngoài đều phải được xử lý như chuyển tới nơi chưa được công nhận, và cần biện pháp bảo vệ theo căn cứ hai hoặc ba. Cách lập luận “Nhật Bản có luật bảo vệ thông tin cá nhân nên không sao” ít nhất là không đứng vững theo căn cứ thứ nhất.

Nhìn một cách bình tĩnh, phần lớn dữ liệu mà hệ thống quản lý sản xuất xử lý không phải dữ liệu cá nhân. Mã hàng, BOM, công đoạn, thiết bị, số lượng tồn kho, số lô, giá thành. Những dữ liệu này nằm ngoài phạm vi của PDPA. Đặt chúng ở region nước ngoài cũng không tạo ra vấn đề về chuyển dữ liệu ra nước ngoài theo PDPA.

Những mục sau đây mới trở thành vấn đề.

• ID và họ tên của công nhân gắn với nhập kết quả sản xuất (bản ghi ai làm gì vào lúc nào)
• Dữ liệu chấm công khi có liên kết với ghi nhận ra vào cổng hoặc hệ thống chấm công
• Dữ liệu sinh trắc học khi dùng xác thực vân tay hoặc khuôn mặt (thường được coi là dữ liệu cá nhân nhạy cảm và đòi hỏi cách xử lý thận trọng hơn)
• Tên và thông tin liên hệ của người phụ trách phía đối tác giao dịch (nằm trong module mua hàng)

Trong số này, dữ liệu sinh trắc học đặc biệt cần chú ý. Cuộc thảo luận về xác thực ở phần trên và cuộc thảo luận về vị trí lưu dữ liệu giao nhau tại đây. Mong muốn “cho hiện trường đăng nhập bằng vân tay” là hợp lý về mặt vận hành, nhưng ngay khoảnh khắc đó bạn sẽ nắm giữ loại dữ liệu cần cách xử lý thận trọng hơn. Hãy xác nhận với bộ phận pháp chế ngay từ giai đoạn thiết kế về việc lưu mẫu sinh trắc ở đâu, có ra nước ngoài không, và lấy sự đồng ý như thế nào.

Còn một luận điểm nữa hay bị bỏ sót. Đó là ngay cả khi dữ liệu được đặt tại region trong lãnh thổ Thái Lan, nếu nhân viên vận hành từ trung tâm hỗ trợ ở nước ngoài truy cập vào thì việc đó vẫn có thể bị coi là chuyển dữ liệu ra nước ngoài. Cấu hình mà bộ phận hỗ trợ của nhà cung cấp SaaS đặt tại Singapore hoặc Ấn Độ không hiếm. Cần kiểm tra cả điều khoản xử lý dữ liệu trong hợp đồng lẫn đường truy cập thực tế. Lời giải thích của bộ phận kinh doanh rằng “dữ liệu nằm trong lãnh thổ Thái Lan” là câu chuyện về nơi lưu trữ, không phải câu chuyện về nơi truy cập.

Phán đoán cuối cùng về giải thích pháp luật nhất định phải được xác nhận với bộ phận pháp chế hoặc luật sư tại địa phương. Điều bài viết này có thể đưa ra chỉ dừng ở danh sách các mục cần kiểm tra.

Nếu chọn on-premise thì hãy quyết định trước bốn mốc thời hạn

Tới đây nội dung có thể đọc ra như đang nghiêng về đám mây, nhưng việc chọn on-premise đương nhiên có tính hợp lý của nó. Vẫn chạy được khi mất đường truyền, phản hồi nhanh, dữ liệu nằm trong tầm tay về mặt vật lý. Với những nhà máy có nhiều chức năng mang thời gian ngừng có thể chấp nhận ngắn, đây là lựa chọn đúng.

Tuy nhiên, nếu chọn on-premise thì hãy quyết định trước bốn mốc thời hạn. Nếu triển khai mà không quyết định, sau 5 năm bạn sẽ có một “máy chủ vẫn chạy nhưng không ai dám đụng vào”.

1. Hạn hỗ trợ của OS. Hỗ trợ mở rộng của Windows Server 2016 (Microsoft) sẽ kết thúc vào ngày 12 tháng 1 năm 2027. Nếu trong nhà máy hiện có máy chủ đang chạy trên bản 2016, bạn có thể tính ngược ra khoảng thời gian còn lại. Ngay cả khi xây dựng mới, hãy ghi ngày kết thúc hỗ trợ mở rộng của OS đã chọn vào tờ trình phê duyệt nội bộ. Có một dòng này thì thời điểm lập ngân sách thay mới lần kế tiếp sẽ tự động được xác định.

2. Hạn hỗ trợ của cơ sở dữ liệu. Hỗ trợ chính của SQL Server 2019 (Microsoft) đã kết thúc vào ngày 28 tháng 2 năm 2025, và hỗ trợ mở rộng sẽ kết thúc vào ngày 8 tháng 1 năm 2030. Hỗ trợ chính đã kết thúc nghĩa là về nguyên tắc không còn được cung cấp cả tính năng bổ sung lẫn các bản sửa lỗi kèm thay đổi đặc tả. Hệ thống vẫn vận hành được, nhưng không đáp ứng được các yêu cầu mới.

3. Hạn bảo trì phần cứng. Hợp đồng bảo trì máy chủ thông thường là 5 năm. Quá 5 năm thì nguồn cung linh kiện bảo trì dừng lại, và phương án khôi phục khi hỏng hóc trở thành “đi tìm máy cùng đời trên thị trường cũ”. Duy trì “RTO 15 phút” trong trạng thái này là bất khả thi. Hãy xếp ngày kết thúc hợp đồng bảo trì và RTO của từng chức năng trong cùng một bảng để kiểm tra.

4. Thời hạn của con người. Đây là mốc bị bỏ sót nhiều nhất. Người đã thiết lập máy chủ đó liệu 5 năm sau còn ở cơ sở này không? Người phụ trách hệ thống thông tin tại nhà máy Nhật Bản, nếu là nhân sự biệt phái thì có nhiệm kỳ, nếu là nhân viên bản địa thì có khả năng chuyển việc. Môi trường on-premise được xây dựng phụ thuộc vào cá nhân sẽ trở thành hộp đen ngay khi người phụ trách rời đi. Hãy gắn nơi quản lý thông tin cấu hình và mật khẩu với tổ chức chứ không phải với cá nhân. Cụ thể là gom sơ đồ cấu hình, sổ địa chỉ IP, danh sách tài khoản quản trị và đầu mối liên hệ nhà cung cấp vào một tài liệu duy nhất, lưu tại hai nơi là trụ sở chính Nhật Bản và cơ sở tại địa phương, và cập nhật mỗi năm một lần. Có hay không có cách vận hành này sẽ làm thay đổi các lựa chọn của bạn sau 5 năm.

Ngoài ra, trong bốn mốc thời hạn này thì mốc 1, 2 và 3 sẽ chuyển sang phạm vi trách nhiệm của nhà cung cấp khi bạn chọn đám mây. Thứ nằm trong chi phí đám mây không chỉ là tài nguyên tính toán, mà còn là việc đưa việc quản lý các mốc thời hạn này ra bên ngoài. Bạn thấy khoảng chênh lệch hàng năm 408.000 THB trong phần tính toán là đắt hay hợp lý sẽ tùy thuộc vào việc công ty bạn có bộ máy để tiếp tục việc quản lý này hay không.

Ba mẫu cấu hình lai

Như đã thấy ở kịch bản C, cấu hình lai không rẻ. Đắt hơn đám mây toàn phần 2.440.000 THB và đắt hơn on-premise toàn phần 370.000 THB. Lý do vẫn chọn cấu hình lai không phải chi phí mà là thời gian ngừng có thể chấp nhận. Nếu không chia sẻ điểm này ngay từ đầu, giữa chừng quá trình phê duyệt chắc chắn sẽ nổ ra tranh luận kiểu “đã chọn lai rồi mà sao vẫn đắt”.

Thứ chúng ta đang mua không phải số tiền mà là thời gian ngừng có thể chấp nhận. Hãy viết câu này vào dòng đầu tiên của bản đề xuất.

Trên cơ sở đó, cấu hình lai trên thực tế có ba mẫu.

Mẫu 1: nhóm chức năng hiện trường đặt on-premise, nhóm chức năng quản lý đặt trên đám mây. Kịch bản C chính là mẫu này. Đặt các chức năng có thời gian ngừng có thể chấp nhận ngắn như phát hành tem nhãn, nhập kết quả sản xuất và phân bổ tồn kho lên máy chủ biên trong nhà máy, còn mua hàng, giá thành, phân tích và quản lý dữ liệu master thì đặt trên đám mây. Vì ranh giới rõ ràng về mặt nghiệp vụ nên phân định trách nhiệm cũng rõ. Điểm yếu là phải giữ song song bản quyền cho nhóm chức năng hiện trường và bản quyền phía đám mây, và phần liên kết trở thành phát triển bổ sung. Đó chính là lý do trong phần tính toán, phát triển bổ sung là 400.000 THB, cao hơn mức 300.000 THB của đám mây toàn phần.

Mẫu 2: phần thân đặt trên đám mây, trong nhà máy chỉ đặt cache chỉ đọc và chức năng in. Đây là cấu hình đặt toàn bộ phần thân của hệ thống trên đám mây, còn trong nhà máy chỉ đặt bản sao của master mã hàng và tồn kho cùng chức năng in tem nhãn. Vì việc ghi luôn đi lên đám mây nên dễ giữ tính nhất quán của dữ liệu. Trong lúc mất đường truyền chỉ có thể “xem” và “in”, còn “đăng ký” thì không. Cấu hình này xây dựng rẻ hơn mẫu 1, nhưng vì không duy trì được việc nhập kết quả sản xuất nên không đủ cho các nhà máy có RTO của nhập kết quả sản xuất ngắn.

Mẫu 3: chạy chính thức trên đám mây, on-premise chỉ dùng cho vận hành thu hẹp. Đây là cấu hình mà lúc bình thường mọi thứ chạy trên đám mây, còn máy chủ trong nhà máy chỉ khởi động khi có thảm họa hoặc khi mất đường truyền kéo dài, dùng cho vận hành thu hẹp. Nó mang nguyên tư duy DR (khôi phục sau thảm họa) vào. Cái bẫy lớn nhất là vì phía thu hẹp không được dùng lúc bình thường nên tới lúc cần thì lại không chạy. Hệ thống chờ mà không được dùng thì chắc chắn sẽ mục. Hãy đưa vào thiết kế vận hành bài diễn tập mỗi quý một lần chạy nửa ngày chỉ bằng phía thu hẹp. Nếu không đưa được bài diễn tập vào, thì tốt hơn là đừng chọn mẫu này.

Cả ba mẫu đều có chung cách quyết định. Đặt bảng RTO theo từng chức năng bên cạnh, rồi phán định từng dòng một xem “chức năng này đặt bên nào thì đáp ứng được giá trị trong bảng”. Chỉ vậy thôi. Không có chỗ nào quyết định bằng sở thích kỹ thuật.

Bảy mục cần quyết định trước khi đặt hàng (danh sách kiểm tra)

Sau đây là các mục cần quyết định trong nội bộ trước khi lấy báo giá. Nếu bảy mục này đã được điền, bạn có thể so sánh đề xuất của các nhà cung cấp trên cùng một mặt bằng. Nếu chưa điền, mỗi bên sẽ báo giá trên tiền đề khác nhau và việc so sánh không thành lập.

Xin bổ sung về mục số 7. Nếu chọn SaaS, hãy kiểm tra trong hợp đồng xem khi kết thúc hợp đồng bạn nhận lại dữ liệu ở định dạng nào. Chỉ ghi “có thể xuất ra CSV” là chưa đủ. Hãy kiểm tra riêng từng điểm xem cấu trúc phân cấp của dữ liệu master, quan hệ cha con của BOM, tệp đính kèm và lịch sử thay đổi có nằm trong phạm vi xuất dữ liệu hay không. Nếu vận hành 5 năm mà chỗ này còn mơ hồ, tới kỳ thay mới tiếp theo bạn sẽ rơi vào trạng thái “chi phí chuyển đổi quá cao nên không nhúc nhích được”. Điều khoản tăng giá cũng vậy, nếu hợp đồng không ghi tỷ lệ điều chỉnh tối đa hàng năm thì bản thân việc tính tổng chi phí 5 năm cũng không thành lập.

Mục số 6 cũng quan trọng trên thực tế. Nếu không bắt nộp theo cùng một mẫu, các đề xuất chỉ rẻ ở chi phí ban đầu và đắt ở chi phí hàng năm sẽ trông có lợi hơn. Như đã chỉ ra trong phần tính toán, ở quy mô này chênh lệch chi phí hàng năm sẽ thành chênh lệch vài triệu THB trong 5 năm. Mẫu nộp phải do bên đặt hàng chỉ định.

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

Giữa hệ thống quản lý sản xuất đám mây và on-premise, cái nào rẻ hơn?

Tùy vào kỳ so sánh. Với nhà máy mẫu trong bài viết này (180 nhân sự, 40 người dùng), tổng chi phí 5 năm của đám mây toàn phần là 9.210.000 THB, của on-premise toàn phần là 11.280.000 THB, tức đám mây rẻ hơn 2.070.000 THB. Chi phí lũy kế đảo chiều vào năm thứ 10,1, và nếu năm thứ 6 cộng một lần khoản thay mới phần cứng và OS 1.350.000 THB thì là năm thứ 13,4. Vì không nằm trong kỳ ra quyết định đầu tư thông thường là 5 – 7 năm, ở quy mô này lấy chi phí làm tiêu chí cũng không ra được câu trả lời. Hãy quyết định bằng thời gian ngừng có thể chấp nhận.

Mặt bằng chi phí của hệ thống quản lý sản xuất dạng đám mây là bao nhiêu?

Vì thay đổi lớn theo quy mô và yêu cầu của cơ sở tại Thái Lan, chỉ nhìn đơn giá thì không phán đoán được. Để tham khảo, khoảng giá của hệ thống quản lý sản xuất dạng đám mây tại Nhật Bản được cho là từ khoảng 30.000 tới 50.000 JPY một tháng, nếu tính phí theo người dùng thì khoảng 10.000 JPY một người một tháng, và chi phí ban đầu ở mức vài trăm nghìn JPY. Loại on-premise có chi phí ban đầu khoảng 1.000.000 tới 3.000.000 JPY và khoảng 30.000 JPY một tháng làm con số tham khảo. Tuy nhiên đây là mặt bằng tại Nhật Bản, còn khi triển khai tại Thái Lan sẽ cộng thêm số giờ công cho định nghĩa yêu cầu, chuyển dữ liệu master, hỗ trợ tiếng Thái và đào tạo hiện trường. Phần hỗ trợ triển khai của đám mây toàn phần được đặt là 1.800.000 THB trong phần tính toán của bài viết này chính là phần đó. Hãy so sánh bằng tổng chi phí gồm ban đầu cộng hàng năm nhân 5, chứ không phải bằng đơn giá bản quyền.

Nhà máy tại Thái Lan có dùng được hệ thống quản lý sản xuất dạng đám mây xét về đường truyền không?

Điều quyết định không phải băng thông mà là tích của số lần khứ hồi cho mỗi thao tác với RTT. Con số tham khảo về RTT là 5 – 15 ms với region trong lãnh thổ Thái Lan tại Bangkok, 25 – 40 ms giữa Bangkok và Singapore, 70 – 90 ms giữa Bangkok và Tokyo. Đây chỉ là con số tham khảo thường được quan sát thấy, không phải giá trị xác định. Nhất định phải tự đo trên đường truyền của mình. Với cách hiện thực cần 5 lần khứ hồi cho một lần quét, tại region Tokyo riêng phần khứ hồi đã cộng thêm 5 × 80 ms = 0,4 giây. Với region trong lãnh thổ Thái Lan tại Bangkok thì là 5 × 10 ms = 0,05 giây. Tăng băng thông cũng không thu hẹp được khoảng cách này. Chỉ có hai cách là giảm số lần khứ hồi hoặc rút ngắn khoảng cách.

Trường hợp nào thì cứ giữ on-premise là được?

Là trường hợp các chức năng có thời gian ngừng có thể chấp nhận 5 – 15 phút nằm ở trung tâm của công việc, đồng thời địa điểm không cho phép dự phòng đường truyền một cách thực tế. Ngoài ra còn có điều kiện là trong cơ sở phải có bộ máy tiếp tục quản lý các mốc hạn của OS, cơ sở dữ liệu và bảo trì phần cứng. Nếu duy trì on-premise mà không có bộ máy này, thì mỗi lần một mốc hạn tới, chẳng hạn như hỗ trợ mở rộng của Windows Server 2016 (Microsoft) kết thúc vào ngày 12 tháng 1 năm 2027, bạn sẽ bị buộc phải thay mới trong tình thế xử lý khẩn cấp. Ngược lại, không có lý do hợp lý nào để đặt lên on-premise cả những chức năng như tổng hợp giá thành hay mua hàng vốn có ngừng 3 ngày làm việc thì công việc vẫn chạy. Hãy suy nghĩ theo hướng “giữ chức năng nào lại on-premise” chứ không phải “có nên giữ nguyên on-premise hay không”.

Chuyển hệ thống lõi lên đám mây mất khoảng bao lâu?

Nếu trong phạm vi hệ thống quản lý sản xuất, nhiều dự án dự trù khoảng một năm tính từ định nghĩa yêu cầu tới vận hành chính thức. Tuy nhiên con số này dao động lớn theo quy mô nhà máy và tình trạng dữ liệu hiện có, nên không phải con số có thể khái quát hóa. Hãy lấy báo giá theo điều kiện của công ty bạn. Yếu tố kéo dài thời gian không phải số lượng chức năng mà là tình trạng dữ liệu master. Master mã hàng có trùng lặp, BOM không khớp với hiện vật, đơn vị và mã đối tác khác nhau theo từng bộ phận. Loại dự án tốn gấp đôi dự kiến cho việc sắp xếp này là nhiều nhất. Thứ quyết định việc chuyển đổi thành hay bại không phải tính năng của hệ thống mới mà là chất lượng dữ liệu hiện có. Hãy quyết định trước cả cách bố trí thời gian chạy song song. Nếu bắt đầu mà chưa định ngày dừng hệ thống cũ, giai đoạn chạy song song sẽ không kết thúc.

Tổng kết

Năm 2026, các region đám mây đã hội tụ tại Bangkok, và lần đầu tiên “đặt dữ liệu trong lãnh thổ Thái Lan” trở thành một lựa chọn tiêu chuẩn. Nhưng thứ thay đổi chỉ là ràng buộc về vị trí lưu dữ liệu, còn khung phán đoán thì không thay đổi.

Thứ cần dừng lại là việc cố chọn một câu trả lời duy nhất cho toàn bộ hệ thống giữa “đám mây hay on-premise”. Bên trong hệ thống quản lý sản xuất, chức năng phát hành tem nhãn chỉ được phép ngừng 5 – 15 phút và chức năng tổng hợp giá thành được phép ngừng 3 ngày làm việc đang cùng tồn tại. Chính vì cố đưa ra cùng một câu trả lời cho hai thứ này nên cuộc họp mới không kết thúc. Đơn vị của quyết định là từng chức năng.

Tiêu chí không phải chi phí. Trong phần tính toán cho nhà máy mẫu, tổng chi phí 5 năm là 9.210.000 THB với đám mây toàn phần, 11.280.000 THB với on-premise toàn phần và 11.650.000 THB với cấu hình lai, còn chi phí lũy kế đảo chiều vào năm thứ 10,1, và vào năm thứ 13,4 nếu cộng một lần khoản thay mới. Một chênh lệch không nằm trong kỳ ra quyết định đầu tư 5 – 7 năm thì không hoạt động được như một tiêu chí. Tuy nhiên nếu nhìn theo kỳ cố định 5 năm, thứ quyết định việc đảo chiều không phải số năm mà là số người. Khi người dùng vượt khoảng 59 người thì tổng chi phí của đám mây toàn phần sẽ vượt qua on-premise toàn phần. Hãy xác nhận trước số người dùng sau 5 năm.

Và thứ dễ bị bỏ sót nhất là xác thực. Xác thực không có trong danh sách chức năng nghiệp vụ nhưng lại nằm phía trước mọi chức năng, và không ai gán RTO cho nó. Vì vậy sự cố đầu tiên sau khi chuyển đổi xảy ra ở xác thực. Hãy đặt RTO của xác thực khớp với giá trị ngắn nhất trong bảng chức năng.

Nếu chọn cấu hình lai, hãy chia sẻ ngay từ đầu rằng lý do không phải vì nó rẻ. Trong phần tính toán, nó đắt hơn đám mây toàn phần 2.440.000 THB và đắt hơn on-premise toàn phần 370.000 THB. Thứ bạn mua không phải số tiền mà là thời gian ngừng có thể chấp nhận. Nếu tiến hành mà không chia sẻ tiền đề này, sau khi vận hành chắc chắn sẽ xảy ra xích mích.

Việc cần làm tiếp theo không phải lấy báo giá từ ba nhà cung cấp. Mà là để bộ phận sản xuất và giám đốc nhà máy điền thời gian ngừng có thể chấp nhận cho từng chức năng. Chỉ cần có bảng đó, việc đặt chức năng nào ở bên nào sẽ được quyết định một cách máy móc. Không có bảng thì dù chọn gói phần mềm nào cũng không phán đoán được.

Việc phân chia chức năng nào đặt ở bên nào thì không thể phán đoán nếu không nhìn vào cách vận hành thực tế của hiện trường và tình trạng thực tế của đường truyền. Cùng là “phát hành tem nhãn 15 phút”, thời gian thực sự cầm cự được vẫn thay đổi theo diện tích khu vực để tạm và giờ của chuyến xe xuất hàng. TOMAS TECH đặt trụ sở tại Bangkok và đã tham gia vào việc lựa chọn, chuyển đổi hệ thống quản lý sản xuất cùng thiết kế vận hành phía hiện trường trong lĩnh vực IT nhà máy và FA cho các doanh nghiệp sản xuất Nhật Bản. Ngay cả khi chưa chọn được gói phần mềm, hay chưa quyết định có nên lên đám mây hay không, bạn vẫn có thể trao đổi với chúng tôi từ giai đoạn phân chia đó. Nếu bạn có sẵn danh sách chức năng hiện tại và cấu hình đường truyền, chúng tôi sẽ cùng bạn bắt đầu từ việc điền bảng thời gian ngừng có thể chấp nhận. Xin liên hệ qua trang liên hệ.