Sự lão hóa của hệ thống quản lý sản xuất hiếm khi biểu hiện ra dưới dạng dễ nhận biết như màn hình bị treo hay xử lý chậm chạp. Trong phần lớn trường hợp, hôm nay hệ thống vẫn chạy bình thường. Chính vì vậy mà quyết định cứ bị lùi lại, và đến lúc nhận ra thì hạn hỗ trợ của phần mềm nền tảng đã ở ngay trước mắt. Bài viết này không bàn về việc thay mới phần cứng như PLC hay tủ điều khiển, mà bàn về chính hệ thống quản lý sản xuất, tức phần mềm nghiệp vụ và nền tảng vận hành của nó. Chúng tôi sẽ trình bày một mô hình chấm điểm giúp nhà máy không phải phán đoán bằng cảm tính, cùng những lựa chọn khác ngoài phương án thay thế toàn diện.
Vì sao “vẫn chạy được” và “vẫn an toàn” là hai chuyện khác nhau
Mỗi khi đề cập đến việc đổi mới hệ thống của nhà máy, chúng tôi gần như luôn nhận được cùng một phản ứng. “Hiện tại chưa thấy vướng mắc gì”, “Khi nào dừng thì tính”. Với thiết bị sản xuất, cách nghĩ này có một mức độ hợp lý nhất định. Thực tế có những thiết bị hỏng rồi sửa vẫn được, và chỉ cần trữ sẵn phụ tùng là cầm cự được trước mắt.
Nhưng hệ thống quản lý sản xuất hỏng theo một cách khác với thiết bị. Nó không mòn dần rồi giảm hiệu năng từ từ, mà mất khả năng sử dụng theo kiểu “từ một ngày nào đó trở đi, trên đời không còn ai sửa được nữa”. Ngày đó đã được nhà sản xuất công bố từ vài năm trước và sẽ đến bất chấp hoàn cảnh của doanh nghiệp.
Ngày kết thúc hỗ trợ được ấn định không phụ thuộc vào hoàn cảnh của bạn
Nhìn vào mốc thời gian cụ thể sẽ nhanh hơn, nên chúng tôi nêu hai nền tảng vẫn còn được dùng rộng rãi trong hệ thống lõi của các nhà máy vốn Nhật.
Trước hết là IBM i, dòng kế thừa của AS/400 ngày trước. Hỗ trợ mở rộng cho IBM i 7.3 sẽ kết thúc vào ngày 30 tháng 9 năm 2026. Cùng ngày đó cũng là ngày kết thúc hỗ trợ tiêu chuẩn của IBM i 7.4, tức hai thời hạn có tính chất khác nhau lại rơi vào cùng một mốc. Nhà máy đang dùng 7.3 và nhà máy vốn yên tâm vì đã nâng lên 7.4 đều bị đặt trước cùng một quyết định vào cùng một ngày.
Phía phần cứng cũng có thời hạn riêng. Một số mẫu IBM Power9 đã được công bố kết thúc bảo trì tiêu chuẩn phần cứng vào ngày 31 tháng 1 năm 2026. Thời hạn hỗ trợ phần mềm và thời hạn bảo trì phần cứng được thiết lập riêng biệt, nên nếu chỉ nhìn một bên thì kế hoạch sẽ lệch.
Trường hợp chạy trên máy chủ Windows cũng tương tự. Windows Server 2016 đã kết thúc hỗ trợ chính thức từ tháng 1 năm 2022, và hỗ trợ mở rộng cũng sẽ kết thúc vào ngày 12 tháng 1 năm 2027. Sau đó vẫn còn cơ chế cập nhật bảo mật mở rộng (ESU) có thu phí, nhưng cơ chế này được thiết kế để tăng giá theo từng bậc qua mỗi năm. Nói cách khác, ESU không phải là “phương tiện để dùng tiếp”, mà là “cách dùng tiền mua thêm thời gian cho đến khi hoàn tất việc chuyển đổi”.
Đặt các mốc này cạnh nhau, có thể thấy giai đoạn từ năm 2026 đến năm 2027 là lúc thời hạn của những nền tảng đang đỡ hệ thống lõi trong các nhà máy vốn Nhật dồn lại một chỗ. Vì vào cùng thời điểm sẽ có nhiều doanh nghiệp phải ra cùng một quyết định, nên cũng nên tính trước khả năng khó tìm được kỹ sư nhận việc chuyển đổi.
“Ngừng sản xuất” và “hết hạn bảo trì” gây đau ở những chỗ khác nhau
Trong thế giới thiết bị điều khiển có hai mốc là “ngừng sản xuất” và “kết thúc nhận sửa chữa”, và rủi ro thực tế phát sinh ở mốc thứ hai. Đó là chuyện của thiết bị, nhưng ở phần mềm thì cấu trúc cũng rất giống.
Điểm khác nhau nằm ở việc có hay không phương án thay thế. Với PLC, ngay cả mã hàng đã ngừng sản xuất thì thị trường đồ cũ hay các đơn vị chuyên sửa chữa vẫn là lối thoát còn lại trong một khoảng thời gian. Vì vật thể vẫn còn tồn tại nên chịu khó tìm thì vẫn có khả năng tìm ra. Nhưng với phần mềm hết hạn bảo trì thì không có chuyện “cứ tìm là thấy” đó. Bản cập nhật bảo mật không lưu thông trên thị trường, và tự vá lỗ hổng sau khi nó được công bố là điều không thực tế.
Một điểm khác nữa là phạm vi ảnh hưởng. Nếu thiết bị điều khiển của một máy dừng, thứ dừng lại là máy đó hoặc chuyền đó. Nếu hệ thống quản lý sản xuất dừng, thì đơn hàng, lệnh sản xuất, số liệu thực tế và cả xuất hàng đều dừng cùng lúc. Ảnh hưởng hiện ra dưới dạng cả nhà máy rơi xuống trạng thái vận hành chữa cháy bằng giấy và Excel.
“Vách đá năm 2025” vẫn chưa qua
“Vách đá năm 2025” mà Bộ Kinh tế, Thương mại và Công nghiệp Nhật Bản nêu ra, trái với ấn tượng từ cái tên, vẫn chưa được giải quyết dù đã sang năm 2026. Theo phân tích tại thời điểm tháng 1 năm 2026, 74% doanh nghiệp lớn của Nhật Bản vẫn đang sở hữu các hệ thống CNTT lão hóa, tức hệ thống legacy.
Cách đọc con số 74% này cần thận trọng. Nó không có nghĩa là “74% doanh nghiệp đang ở trạng thái nguy hiểm”. Điều nên rút ra là: việc tiếp tục vận hành trong khi vẫn ôm hệ thống legacy không phải ngoại lệ mà là tình trạng phổ biến. Không phải chỉ riêng công ty bạn chậm chân. Tuy nhiên, thời điểm hết hạn được ấn định không liên quan gì đến hoàn cảnh của từng doanh nghiệp, nên “phổ biến” không phải là căn cứ để yên tâm.
Cũng có những chuyển động tích cực. Tháng 2 năm 2026, JFE Steel công bố đã hoàn tất chuyển toàn bộ hệ thống lõi của tất cả các nhà máy thép và cơ sở sản xuất sang môi trường mở. Quy mô và bộ máy của họ khác xa bối cảnh của một nhà máy tại Thái Lan nên không thể tham chiếu nguyên xi, nhưng đó là ví dụ cho thấy một sự thật hiển nhiên: nếu lập kế hoạch dài hạn và thực thi thì việc chuyển đổi sẽ hoàn thành.
Dấu hiệu lão hóa nằm ở sự bào mòn vận hành, không nằm ở chỉ số kỹ thuật
Khi muốn đánh giá mức lão hóa của hệ thống, phần lớn mọi người đi tìm chỉ số kỹ thuật trước tiên. Số năm vận hành, thời gian phản hồi, tỷ lệ sử dụng ổ đĩa. Nhưng ở giai đoạn đầu của lão hóa, những chỉ số này gần như không nhúc nhích. Bởi trạng thái “vẫn chạy nhưng đã cũ” kéo dài rất lâu.
Thứ xuất hiện trước là sự bào mòn trong vận hành. Không phải bản thân hệ thống, mà công sức con người phải bỏ ra xung quanh hệ thống lặng lẽ tăng lên. Bốn dấu hiệu dưới đây là những gì thường được nêu trên thực tế khi cân nhắc thay thế hệ thống.
Dấu hiệu 1: Hiện trường bù đắp bằng Excel đã trở thành thường lệ
Đã có hệ thống quản lý sản xuất, nhưng kế hoạch thực tế lại được lập trên file Excel của một ai đó. Trong hệ thống thì người ta chỉ nhập lại kết quả sau khi mọi việc đã xong. Đây là dấu hiệu lão hóa dễ nhận ra nhất.
Điều cần nhìn ở đây không phải là việc có dùng Excel hay không. Excel là công cụ xuất sắc, và có vô số công việc phân tích không đáng đưa lên hệ thống. Vấn đề nằm ở chỗ file Excel đó tồn tại để lấp vào “những gì hệ thống không làm được” hay không. Yêu cầu nghiệp vụ đã thay đổi nhưng hệ thống không theo kịp, và phần chênh lệch được con người lấp bằng thao tác thủ công. Khi cấu trúc này đã hình thành, chức năng thực chất của hệ thống đã dịch chuyển sang cá nhân đang làm file Excel đó.
Dấu hiệu 2: Báo giá cho tính năng mới lần nào cũng tăng vọt, và ngày càng phải từ bỏ nhiều yêu cầu
Rõ ràng đã yêu cầu một sửa đổi ở mức tương đương trước đây, nhưng báo giá trả về lại nhảy lên một bậc chữ số. Hơn nữa căn cứ của con số cũng không rõ ràng. Hiện tượng này thường có lý do kỹ thuật.
Hệ thống dùng lâu năm sẽ tích tụ các xử lý ngoại lệ qua mỗi lần sửa. Động vào một chức năng thì ảnh hưởng lan tới đâu, không ai nắm được toàn cảnh. Vì thế nhà cung cấp phải tính thêm nhiều công cho khâu khảo sát ảnh hưởng và kiểm thử. Giá tăng không phải vì họ bắt chẹt, mà vì mức độ nguy hiểm của một thay đổi thực sự đã tăng.
Và vấn đề thật sự không nằm ở số tiền, mà ở điều xảy ra sau đó. Báo giá cao nên rút lại yêu cầu. Yêu cầu bị rút lại sẽ chảy về file Excel của hiện trường. Dấu hiệu 1 xấu đi. Hai dấu hiệu này kéo theo nhau.
Dấu hiệu 3: Nhân sự bảo trì phía nhà cung cấp giảm đi và phản hồi chậm lại
Trả lời câu hỏi chậm hơn, người phụ trách bị thay, những việc trước đây trả lời ngay thì nay phải mang về xem lại. Những thay đổi kiểu này thường là biểu hiện của việc số kỹ sư hiểu hệ thống đó ở phía nhà cung cấp đang giảm dần.
Người nắm công nghệ cũ sẽ ít đi vì nghỉ việc hoặc luân chuyển. Về phía nhà cung cấp, họ cũng khó đầu tư đào tạo người trẻ cho một công nghệ không còn dự án mới. Đây không phải chuyện thiện chí hay ác ý mà là chuyện cấu trúc. Cho dù thời hạn bảo trì theo hợp đồng vẫn còn xa, nếu trên thực tế không còn ai xử lý được thì ngày tháng ghi trong hợp đồng cũng ít ý nghĩa.
Dấu hiệu 4: Bắt đầu bị nêu vấn đề trong kiểm toán bảo mật nội bộ
Bộ phận CNTT của công ty mẹ hoặc kiểm toán nội bộ của tập đoàn bắt đầu nêu ra những mục trước đây chưa từng bị nhắc. Phiên bản hệ điều hành đang dùng, phương thức mã hóa, chính sách mật khẩu, thời gian lưu nhật ký.
Điều phiền toái của dấu hiệu này là thời hạn đến từ bên ngoài. Về mặt kỹ thuật có thể còn chạy được vài năm nữa, nhưng nếu kiểm toán ghi “khắc phục trước kỳ kiểm toán sau” thì mốc đó trở thành hạn hỗ trợ trên thực tế. Hơn nữa, hạn khắc phục của kiểm toán thường được đặt ngắn hơn khoảng thời gian cần thiết để chuyển đổi.
Điểm chung của bốn dấu hiệu là không cái nào được ghi nhận như một sự cố hệ thống. Tỷ lệ vận hành vẫn 100%, chỉ có gánh nặng của những người xung quanh là tăng lên. Vì vậy, báo cáo “không có vấn đề” dựa trên tỷ lệ vận hành cứ tiếp tục được đưa lên.
Mô hình chấm điểm 6 biến số cho quyết định thay thế
Nếu bàn về các dấu hiệu bằng cảm tính, kết luận sẽ thay đổi theo vị trí của người nói. Hiện trường nói “hết chịu nổi rồi”, kế toán nói “vẫn dùng được”. Cả hai đều nói thật lòng nhưng không gặp nhau, vì chưa có chung một thước đo.
Vì vậy, chúng tôi quy về hình thức chấm 6 biến số từ 0 đến 3 điểm, tổng từ 0 đến 18 điểm để phân loại. Trước hết là danh sách các biến số.
| Biến số | Đo cái gì |
|---|---|
| Biến số 1: Số năm còn lại đến hạn hỗ trợ | Còn bao nhiêu năm đến thời hạn sớm nhất trong phần mềm nền tảng và phần cứng |
| Biến số 2: Mức xấu đi của thời gian khôi phục sự cố | So với trước đây, khôi phục từ cùng loại sự cố nay mất gấp mấy lần thời gian |
| Biến số 3: Phạm vi bù đắp bằng Excel | Bảng tính ngoài hệ thống đang gánh tới đâu trong quy trình nghiệp vụ |
| Biến số 4: Mức thu hẹp của bộ máy bảo trì phía nhà cung cấp | Phía đối tác còn lại bao nhiêu kỹ sư hiểu hệ thống đó |
| Biến số 5: Điểm bị nêu trong kiểm toán bảo mật | Có bị yêu cầu khắc phục trong kiểm toán nội bộ hoặc kiểm toán khách hàng không |
| Biến số 6: Yêu cầu kết nối với các hệ thống xung quanh | Trong vòng 2 năm tới cần kết nối với những gì |
Dưới đây là tiêu chí chấm điểm cho từng biến số. Bạn hãy vừa đọc vừa thử áp giá trị của công ty mình. Với biến số mà bạn không biết con số, thì chính việc không biết đã là một dữ kiện để chấm điểm.
Biến số 1: Số năm còn lại đến hạn hỗ trợ
Lấy mốc sớm nhất trong số hệ điều hành, cơ sở dữ liệu, middleware và bảo trì phần cứng làm chuẩn. Đây là biến số mà nhiều nhà máy trả lời “vẫn còn ổn” khi chưa kiểm tra hết tất cả các thành phần.
| Điểm | Điều kiện |
|---|---|
| 0 điểm | Còn dư từ 5 năm trở lên |
| 1 điểm | Từ 3 năm đến dưới 5 năm |
| 2 điểm | Từ 1 năm đến dưới 3 năm |
| 3 điểm | Dưới 1 năm, hoặc đã quá hạn |
Khi tra thời hạn, hãy xem tài liệu công bố của nhà sản xuất chứ không phải hợp đồng. Dù hợp đồng bảo trì với nhà cung cấp vẫn còn hiệu lực, nếu phía sau đó hỗ trợ của hãng nền tảng đã hết thì nhà cung cấp cũng không thể sửa được những lỗi nghiêm trọng.
Biến số 2: Mức xấu đi của thời gian khôi phục sự cố
Hãy đo bằng xu hướng chứ không phải giá trị tuyệt đối. Một hệ thống vốn dĩ mất nửa ngày để khôi phục, nếu con số đó không đổi thì không phải là dấu hiệu lão hóa.
| Điểm | Điều kiện |
|---|---|
| 0 điểm | Không khác gì vài năm trước |
| 1 điểm | Có dài hơn đôi chút nhưng vẫn khôi phục trong ngày |
| 2 điểm | Kéo dài rõ rệt, đôi khi sang cả ngày hôm sau |
| 3 điểm | Có khi mất vài ngày chỉ riêng cho việc truy nguyên nhân |
Nếu rơi vào mức 3 điểm, phần lớn không phải vấn đề của hệ thống mà là vấn đề không còn ai hiểu cấu trúc của nó. Trường hợp này, sửa chữa cục bộ sẽ không giải quyết được.
Biến số 3: Phạm vi bù đắp bằng Excel
Đo bằng câu hỏi “Excel đang gánh phần nào của nghiệp vụ”, chứ không phải “có dùng Excel hay không”.
| Điểm | Điều kiện |
|---|---|
| 0 điểm | Chỉ dùng để phân tích và làm tài liệu. Dòng chảy nghiệp vụ hoàn tất trên hệ thống |
| 1 điểm | Một số biểu mẫu được định dạng lại bằng Excel |
| 2 điểm | Việc lập kế hoạch hoặc quyết định điều chỉnh tồn kho diễn ra trên Excel |
| 3 điểm | Excel mới là bản chính, hệ thống chỉ là bản ghi chép chạy theo sau |
Trạng thái 3 điểm sẽ không tự động biến mất khi thay hệ thống. Ngược lại, đó lại là phần tốn công nhất khi thực hiện thay thế, vì phải diễn đạt thành yêu cầu nghiệp vụ những logic ra quyết định đang nằm trong file Excel của một cá nhân.
Biến số 4: Mức thu hẹp của bộ máy bảo trì phía nhà cung cấp
Đây là câu chuyện khó hỏi, nhưng đáng để hỏi thẳng. Hãy thử hỏi “Bên anh chị có bao nhiêu kỹ sư có thể phụ trách hệ thống này?”; nếu không nhận được câu trả lời ngay, thì an toàn hơn là hiểu rằng trên thực tế mọi thứ đang phụ thuộc vào rất ít người. Bởi nếu nắm được số lượng thì đó là câu hỏi trả lời được ngay.
| Điểm | Điều kiện |
|---|---|
| 0 điểm | Có nhiều người phụ trách và việc đào tạo người kế nhiệm đang tiến triển |
| 1 điểm | Có nhiều người phụ trách nhưng phần sâu vẫn phụ thuộc vào 1 người cụ thể |
| 2 điểm | Thực chất chỉ 1 người. Người đó vắng mặt là mọi thứ dừng |
| 3 điểm | Người phụ trách đã nghỉ việc hoặc chuyển bộ phận, hoặc hợp đồng bảo trì đã kết thúc |
Biến số 5: Điểm bị nêu trong kiểm toán bảo mật
Xem xét việc bạn có bị nêu vấn đề trong kiểm toán của bộ phận CNTT công ty mẹ, kiểm toán nội bộ tập đoàn hoặc kiểm toán khách hàng hay không. Quan trọng hơn mức độ nặng nhẹ của kết luận kiểm toán là việc đã có hạn khắc phục hay chưa.
| Điểm | Điều kiện |
|---|---|
| 0 điểm | Không bị nêu vấn đề nào |
| 1 điểm | Chỉ được nhắc nhở bằng lời |
| 2 điểm | Bị nêu bằng văn bản và được yêu cầu nộp kế hoạch khắc phục |
| 3 điểm | Đã có hạn khắc phục cụ thể, hoặc đã quá hạn đó |
Biến số 6: Yêu cầu kết nối với các hệ thống xung quanh
Xem trong vòng 2 năm tới có cần kết nối hệ thống đó với thứ gì khác hay không. Kết nối vào hệ thống lõi hợp nhất của công ty mẹ, yêu cầu EDI từ khách hàng, thu thập tự động số liệu thực tế từ thiết bị đều là những yêu cầu điển hình.
| Điểm | Điều kiện |
|---|---|
| 0 điểm | Không có kế hoạch kết nối nào |
| 1 điểm | Khoảng một luồng trao đổi file theo ngày |
| 2 điểm | Kết nối với nhiều hệ thống, hoặc có yêu cầu kết nối vào chuẩn của công ty mẹ |
| 3 điểm | Bị yêu cầu kết nối gần thời gian thực hoặc cung cấp API, nhưng hiện trạng không đáp ứng được |
Sau khi chấm xong 6 biến số, hãy áp tổng điểm vào các khoảng dưới đây.
| Tổng điểm | Kết luận | Hành động tiếp theo |
|---|---|---|
| 0 đến 4 điểm | Theo dõi | Mỗi năm 1 lần, chỉ cần rà lại hạn hỗ trợ |
| 5 đến 9 điểm | Bắt đầu lập kế hoạch | Bắt tay so sánh các lựa chọn và lấy báo giá sơ bộ |
| 10 đến 14 điểm | Đưa vào ngân sách | Đưa vào ngân sách năm sau, chốt bộ máy và thời điểm |
| 15 đến 18 điểm | Khởi động ngay | Dựng tiến độ ngược từ thời hạn, đồng thời triển khai biện pháp tạm thời |
Bảng này có một quy tắc ngoại lệ. Nếu biến số 1 đạt 3 điểm, tức hạn hỗ trợ còn dưới 1 năm hoặc đã quá hạn, thì bất kể tổng điểm là bao nhiêu, hãy xử lý ở mức tối thiểu là “đưa vào ngân sách”. Vì dù các biến số khác đều tốt, bản thân thời hạn là thứ không thể thương lượng.
Không có ngoại lệ theo chiều ngược lại. Ngay cả khi biến số 1 là 0 điểm, nếu biến số 3 và biến số 4 cùng đạt 3 điểm thì đó là trạng thái vận hành đã sụp trước cả thời hạn kỹ thuật. Việc còn dư thời gian không xóa được các vấn đề khác.
Khi rơi đúng ranh giới giữa hai khoảng, ví dụ 9 điểm và 10 điểm, hãy phân biệt xem biến số đang đẩy điểm lên là “chuyện của hiện tại” hay “chuyện của tương lai”. Biến số 1 và biến số 5 là những biến số có thời hạn do bên ngoài quyết định, nên nếu chúng cao thì xếp vào khoảng trên sẽ an toàn hơn. Ngược lại, nếu điểm bị đẩy lên bởi yêu cầu kết nối ở biến số 6 mà kế hoạch đó mới ở giai đoạn “đang cân nhắc”, thì cứ để ở khoảng dưới cho đến khi kế hoạch được quyết định.
Thử chấm điểm cho một nhà máy mẫu
Bàn mãi ở mức trừu tượng cũng không ích gì, nên chúng tôi dựng một nhà máy với các điều kiện thường gặp để chấm điểm.
Một nhà sản xuất linh kiện điện tử vốn Nhật tại tỉnh Chonburi, 240 nhân viên. Cách đây 15 năm, họ xây dựng hệ thống quản lý sản xuất theo hướng sao chép nguyên mẫu cơ chế của công ty mẹ tại Nhật, sau đó liên tục sửa đổi từng phần. Nền tảng là Windows Server 2016.
| Biến số | Điều kiện áp dụng | Điểm |
|---|---|---|
| Biến số 1: Hạn hỗ trợ | Hỗ trợ mở rộng của Windows Server 2016 kết thúc ngày 12 tháng 1 năm 2027 | 3 điểm |
| Biến số 2: Thời gian khôi phục sự cố | Dài hơn trước nhưng vẫn khôi phục trong ngày | 1 điểm |
| Biến số 3: Phạm vi bù đắp bằng Excel | Lập kế hoạch sản xuất thực hiện trên Excel của phòng quản lý sản xuất | 2 điểm |
| Biến số 4: Bộ máy bảo trì của nhà cung cấp | Thực chất chỉ 1 người có thể xử lý | 2 điểm |
| Biến số 5: Kiểm toán bảo mật | Bị bộ phận CNTT công ty mẹ nêu bằng văn bản, đã nộp kế hoạch khắc phục | 2 điểm |
| Biến số 6: Yêu cầu kết nối | Đã có yêu cầu kết nối vào hệ thống lõi hợp nhất của công ty mẹ | 2 điểm |
Tổng cộng là 12 điểm, kết luận là “đưa vào ngân sách”. Thêm nữa, vì biến số 1 đạt 3 điểm nên quy tắc ngoại lệ cũng dẫn tới cùng một kết luận. Hành động nhà máy này cần làm là đưa vào ngân sách năm sau và chốt bộ máy cùng thời điểm triển khai.
Điều đáng chú ý là hệ thống của nhà máy này hôm nay vẫn chạy bình thường. Sự cố không tăng. Chỉ nhìn tỷ lệ vận hành thì hoàn toàn khỏe mạnh. Vậy mà vẫn được 12 điểm, vì áp lực đang đến đồng thời từ bốn hướng: thời hạn, vận hành, bộ máy và yêu cầu nghiệp vụ. Giá trị của mô hình chấm điểm nằm ở chỗ nó thể hiện được bằng con số cái trạng thái “chưa hỏng chỗ nào nhưng đã sát giới hạn”.
Thay thế toàn diện không phải là câu trả lời duy nhất
Ngay cả khi chấm được điểm cao, kết luận cũng không lập tức là làm mới toàn bộ. Chiến lược hiện đại hóa đang là dòng chính tại thời điểm năm 2026 thực ra đi theo hướng ngược lại.
Lời giải thực tế hiện nay là cấu hình lai (hybrid): giữ nguyên logic nghiệp vụ lõi và chỉ mở rộng các chức năng ngoại vi trên nền tảng đám mây. Logic tính giá thành và lập kế hoạch sản xuất đã được xây đắp qua nhiều năm thì giữ nguyên, còn các phần ngoại vi như API, giao diện, phân tích và AI thì làm trên nền tảng mới. Quan điểm chuyển đổi theo giai đoạn thực tế hơn chuyển đổi toàn bộ một lần đã được chia sẻ rộng rãi.
Lý do rất đơn giản: xác suất thất bại của việc chuyển đổi toàn bộ là cao. Trong một hệ thống đã chạy 15 năm luôn có những quy tắc nghiệp vụ không ai từng viết thành tài liệu. Việc đào hết chúng lên rồi triển khai lại trên hệ thống mới thuộc loại công việc dễ sai báo giá nhất.
Trên thực tế, các nước đi có thể quy về bốn lựa chọn sau.
| Lựa chọn | Nội dung chính | Xu hướng chi phí | Xu hướng thời gian | Phù hợp khi nào |
|---|---|---|---|---|
| Gia hạn hợp đồng bảo trì | Mua thêm thời hạn bằng ESU hoặc bảo trì riêng | Nhỏ nhất nhưng tăng dần theo năm | Gần như không cần | Đã có kế hoạch chuyển đổi và cần cầm cự đến khi hoàn tất |
| Kéo dài tuổi thọ theo hướng lai | Giữ lõi, mở rộng phần ngoại vi trên đám mây | Trung bình | Trung bình | Logic nghiệp vụ vẫn hiệu quả nhưng thiếu kết nối và giao diện |
| Chuyển toàn bộ sang gói phần mềm | Thay bằng gói quản lý sản xuất có sẵn | Lớn | Dài | Có thể ra quyết định điều chỉnh nghiệp vụ theo chuẩn của gói |
| Xây dựng lại từ đầu | Làm lại từ con số không | Lớn nhất | Dài nhất | Nghiệp vụ quá đặc thù, sản phẩm có sẵn không đáp ứng được |
Mỗi lựa chọn đều có cái bẫy riêng. Chọn chỉ vì rẻ rồi phải trả giá đắt về sau là chuyện giống hệt với việc đổi mới thiết bị.
| Lựa chọn | Điểm dễ bị bỏ sót |
|---|---|
| Gia hạn hợp đồng bảo trì | Chi phí được thiết kế tăng theo từng bậc, càng kéo dài càng bất lợi |
| Kéo dài tuổi thọ theo hướng lai | Bắt đầu khi chưa chốt phạm vi lõi cần giữ sẽ khiến ranh giới mơ hồ và đối tượng bảo trì phình ra |
| Chuyển toàn bộ sang gói phần mềm | Trì hoãn quyết định điều chỉnh theo chuẩn sẽ dẫn tới chi phí tùy biến ngang với làm mới từ đầu |
| Xây dựng lại từ đầu | Việc rà soát chức năng hiện hành tốn công nhất; thời gian còn tại vị của người hiểu đặc tả trở thành ràng buộc |
Gia hạn hợp đồng bảo trì không phải là một lựa chọn khi đứng một mình. Vì nó chỉ mua thời gian, nếu chưa xác định sẽ làm gì với khoảng thời gian mua được thì sang năm bạn sẽ lại lặp lại đúng quyết định đó.
Chọn gói phần mềm hay xây dựng lại từ đầu tự nó đã là một chủ đề độc lập. Chúng tôi đã sắp xếp các trục phán đoán trong bài viết so sánh nên chọn gói phần mềm hay xây dựng riêng cho hệ thống quản lý sản xuất. Khi việc đánh giá lão hóa đã dẫn đến quyết định “chuyển đổi”, đó là bài tiếp theo nên đọc.
Thời gian và chi phí thực tế của một dự án thay thế
Về thời gian, có một con số cần nắm. Từ khi nhận được thông báo EOSL, tức kết thúc hỗ trợ, cho đến khi vận hành chính thức, một dự án thay thế hệ thống quản lý sản xuất thực tế mất 12-18 tháng.
Con số 12-18 tháng này là khoảng thời gian với giả định việc phê duyệt diễn ra suôn sẻ và yêu cầu nghiệp vụ đã tương đối ổn định. Chỉ cần tờ trình bị trả lại một lần là mất luôn vài tháng.
Hãy thử tính với ví dụ IBM i 7.3 nêu ở trên. Thời hạn là ngày 30 tháng 9 năm 2026. Áp khoảng thời gian 12-18 tháng vào, để kịp thời hạn đó thì dự án lẽ ra đã phải khởi động từ trước. Nếu bây giờ mới bắt đầu cân nhắc, câu chuyện không còn là có kịp hay không, mà là xoay xở thế nào trên giả định sẽ quá hạn.
Cũng đáng biết vì sao thời gian lại kéo dài như vậy. Thứ ngốn nhiều thời gian nhất không phải là việc xây dựng hệ thống mà là việc kiểm kê nghiệp vụ hiện hành. Cái gì là đặc tả, cái gì là mẹo vận hành, cái gì chỉ là thói quen. Việc bóc tách này tốn thời gian nhất. Dài thứ hai là giai đoạn chạy song song và đánh giá điều kiện chuyển đổi. Hệ thống quản lý sản xuất có nhiều nghiệp vụ chốt theo tháng, nên cần chạy ít nhất vài kỳ chốt trên cả hệ thống cũ lẫn mới rồi đối chiếu kết quả.
Về chi phí, việc đưa ra một mức giá chung không có ý nghĩa. Bởi quy mô nhà máy, độ phức tạp nghiệp vụ, mức độ tài liệu hóa hiện tại và khối lượng dữ liệu cần chuyển đổi có thể làm thay đổi cả bậc chữ số. Tuy nhiên, cách chi phí được cộng dồn lại có những khuôn mẫu chung. Chúng tôi trình bày chi tiết, bao gồm cả điểm quan trọng là chi phí phát sinh hằng năm sau khi vận hành thường lớn hơn chi phí đầu tư ban đầu khi tính tổng, trong bài viết phân tách cơ cấu chi phí bảo trì hệ thống của nhà máy. Đó là dữ liệu để đặt chi phí kéo dài tuổi thọ hệ thống cũ và tổng chi phí 5 năm của hệ thống mới lên cùng một bàn cân.
Một quyết định nữa ảnh hưởng tới cả thời gian lẫn chi phí là đặt nền tảng mới trên đám mây hay tại chỗ (on-premise). Số nhà máy nhân dịp thay thế để chuyển lên đám mây đang tăng, nhưng với nhà máy tại Thái Lan thì do chất lượng đường truyền và định hướng của công ty mẹ, đám mây không phải lúc nào cũng là đáp án đúng. Chúng tôi đã tổng hợp các trục phán đoán này trong bài viết so sánh đám mây và on-premise cho hệ thống quản lý sản xuất.
Những vấn đề riêng của nhà máy Nhật tại Thái Lan
Đến đây là những nội dung chung với cả nhà máy tại Nhật. Nếu bạn có cơ sở tại Thái Lan, sẽ có thêm những dữ kiện đặc thù.
Đến hạn rồi cũng không mua bổ sung được tại chỗ
Ở Nhật, các đơn vị chuyên nhận bảo trì nền tảng cũ hay thị trường phần cứng đã qua sử dụng vẫn khá dồi dào. Tại Thái Lan, xác suất tìm được nhà cung cấp trong nước xử lý được thiết bị cùng thế hệ hoặc công nghệ tương tự thấp hơn hẳn. Nếu phải nhập từ Nhật hoặc Singapore, thời gian thông quan và vận chuyển sẽ cộng dồn thêm nhiều ngày.
Khác biệt này mới bộc lộ rõ khi bạn chọn phương án “gia hạn hợp đồng bảo trì” trong bốn lựa chọn. Việc công ty mẹ ở Nhật cũng đang kéo dài tuổi thọ theo cách đó không có nghĩa là cơ sở tại Thái Lan dùng được cùng một nước đi. Tính khả thi của biện pháp kéo dài tuổi thọ phải được xác nhận riêng cho từng cơ sở.
Ràng buộc về nguồn kỹ sư tại chỗ
Tình trạng thiếu kỹ sư thành thạo công nghệ cũ ở đây nghiêm trọng hơn cả ở Nhật. Dù có muốn tuyển mới một kỹ sư người Thái đủ sức bảo trì hệ thống viết bằng công nghệ của 20 năm trước, khả năng tìm được ứng viên cũng không cao.
Nhìn ngược lại, đây chính là giá trị phái sinh của việc thay thế hệ thống. Chuyển sang nền tảng mới không đơn thuần là né một thời hạn, mà còn là mở rộng nguồn nhân lực có thể tuyển được. Nếu việc bảo trì hệ thống hiện tại đang phụ thuộc vào đúng 1 người, thì việc gỡ bỏ tình trạng đó hoàn toàn xứng đáng được tính vào hiệu quả đầu tư.
Dung hòa giữa chuẩn của công ty mẹ và tối ưu tại chỗ
Đây là vấn đề khó nhất với nhà máy tại Thái Lan. Một bên là công ty mẹ đưa ra chủ trương gom về hệ thống lõi hợp nhất, một bên là cơ sở tại chỗ có cách vận hành phù hợp với tập quán kinh doanh địa phương. Yêu cầu thuế đặc thù của Thái Lan, định dạng chỉ thị giao hàng riêng cho từng khách hàng, thực tế trao đổi với nhà cung cấp nội địa. Ép những thứ này vào chuẩn của công ty mẹ thì hiện trường không chạy nổi, còn giữ nguyên tối ưu tại chỗ thì không làm được báo cáo cho công ty mẹ.
Phương án dung hòa thực tế là quyết định trước ranh giới phân chia. Kế toán tài chính và giá thành thì theo chuẩn công ty mẹ, còn lệnh sản xuất và thu thập số liệu thực tế thì cho phép tối ưu tại chỗ. Hãy thống nhất đường phân chia kiểu đó trước khi bước vào giai đoạn định nghĩa yêu cầu. Nếu tiến hành khi chưa có sự đồng thuận này, cùng một cuộc tranh luận sẽ lặp lại ở mỗi buổi định nghĩa yêu cầu và thời gian sẽ kéo dài ra.
Ở đây, tư duy cấu hình lai cũng phát huy tác dụng. Chỉ làm trên nền tảng mới phần cần thiết để kết nối với chuẩn của công ty mẹ, còn logic nghiệp vụ tại chỗ thì giữ lại như tài sản hiện có. Không cố làm tất cả cùng một lúc thì kết quả lại về đích nhanh hơn.
Ngôn ngữ và bàn giao
Bạn cũng cần quyết định các tài liệu tạo ra khi chuyển đổi sẽ được lưu bằng ngôn ngữ nào. Tài liệu thiết kế chỉ viết bằng tiếng Nhật sẽ không còn ai đọc được vào thời điểm người phụ trách người Nhật hết nhiệm kỳ. Tại các cơ sở ở Thái Lan, việc thay đổi cán bộ quản lý người Nhật diễn ra theo chu kỳ vài năm, nên vấn đề này tiến triển nhanh hơn so với nhà máy trong nước Nhật.
Tối thiểu, chúng tôi khuyến nghị lưu thêm quy trình vận hành và quy trình xử lý sự cố bằng tiếng Thái hoặc tiếng Anh. Đó là khoản bảo hiểm tương đối rẻ để nền tảng vừa làm mới không lại trở thành “hệ thống không ai biết bên trong có gì” sau 5 năm nữa.
Chọn đối tác thực hiện việc chuyển đổi như thế nào
Về việc chọn nơi đặt hàng, trước khi liệt kê các hạng mục đánh giá chi tiết, chúng tôi chỉ nêu ba tiêu chí loại trừ mang tính thực tế.
Thứ nhất là có đọc hiểu được hệ thống hiện hành hay không. Năng lực làm ra cái mới và năng lực giải mã cái cũ là hai kỹ năng khác nhau. Thứ thực sự cần trong dự án chuyển đổi là năng lực thứ hai; nếu giao cho đối tác yếu ở điểm này, toàn bộ việc rà soát chức năng hiện hành sẽ đổ về phía công ty bạn. Ngay ở giai đoạn đề xuất, hãy xem họ có giải thích được cụ thể sẽ khảo sát hệ thống hiện hành theo cách nào hay không.
Thứ hai là có bộ máy hoàn tất được việc bảo trì ngay trong Thái Lan hay không. Mô hình xây dựng do đội ở Nhật đảm nhận và bảo trì sau vận hành cũng xử lý từ Nhật thường khó vận hành trên thực tế vì ràng buộc về múi giờ và việc đi công tác. Hãy xác nhận trước khi ký hợp đồng rằng ai sẽ xử lý khi batch ban đêm bị lỗi và người đó đang ở đâu.
Thứ ba là có đưa ra được đề xuất chuyển đổi theo giai đoạn hay không. Nếu ngay từ buổi trao đổi đầu tiên chỉ có báo giá làm mới toàn bộ, thì đối tác đó chưa hề cân nhắc các lựa chọn. Việc họ khuyến nghị làm mới toàn bộ sau khi đã so sánh cả phương án kéo dài tuổi thọ theo hướng lai, hay ngay từ đầu chỉ có một đáp án duy nhất, chỉ cần nhìn cấu trúc hồ sơ đề xuất là biết.
Về cách chọn công ty phát triển hệ thống tại Thái Lan, bao gồm cả hình thức hợp đồng và cơ chế giao tiếp, chúng tôi đã sắp xếp trong bài viết tổng hợp cách chọn công ty phát triển hệ thống tại Thái Lan. Nếu bạn đã bước vào giai đoạn lấy báo giá so sánh, xin mời tham khảo thêm bài đó.
Thêm một điểm về thời điểm bắt đầu chọn đối tác. Ngay cả khi điểm số mới ở khoảng “bắt đầu lập kế hoạch”, bạn vẫn hoàn toàn có thể bắt đầu trao đổi. Thứ nên hỏi ở giai đoạn này không phải báo giá, mà là thông tin về việc với điều kiện của công ty bạn thì lựa chọn nào là khả thi. Nếu thu thập báo giá trước, phán đoán của bạn sẽ bị kéo lệch theo phạm vi mà đối tác đề xuất. Trình tự đúng là: đánh giá, thu hẹp lựa chọn, rồi mới lấy báo giá.
Câu hỏi thường gặp
Khi nào nên cân nhắc thay thế hệ thống quản lý sản xuất
Thời điểm dễ nhận biết nhất là khi hãng công bố kết thúc hỗ trợ cho phần mềm nền tảng hoặc phần cứng. Tuy nhiên bạn không cần chờ đến lúc đó. Cách làm thực tế là chấm 6 biến số trong bài này, và khi tổng điểm đạt từ 5 điểm trở lên thì bắt đầu so sánh các lựa chọn và lấy báo giá sơ bộ.
Cũng có cách tính ngược từ thời gian. Vì một dự án thay thế mất 12-18 tháng, nên mốc 2 năm trước thời hạn sớm nhất chính là hạn khởi động trên thực tế. Khoảng dư 2 năm này là biên độ để hấp thụ những tình huống không thể ghi vào kế hoạch, như tờ trình bị trả lại hay người phụ trách chuyển công tác.
Nếu cứ dùng tiếp khi đã hết hỗ trợ thì sao
Hệ thống sẽ không ngừng chạy ngay lập tức. Trong phần lớn trường hợp, nó tiếp tục chạy như chưa từng có chuyện gì. Chính điều này làm cho quyết định trở nên khó khăn.
Thứ thay đổi là các lựa chọn bạn có khi sự cố xảy ra. Lỗ hổng bảo mật được công bố nhưng không có bản vá. Sự cố xảy ra nhưng không thể hỏi hãng. Phần cứng hỏng nhưng không còn linh kiện bảo trì. Tất cả đều không lộ ra trong lúc bình thường và chỉ hiện hình đúng vào lúc bạn khó khăn nhất.
Thêm nữa, cách nhìn nhận trong kiểm toán khách hàng và kiểm toán công ty mẹ cũng thay đổi. Việc vận hành nghiệp vụ lõi trên nền tảng đã hết hỗ trợ là điểm bị nêu rõ ràng theo nhiều bộ tiêu chuẩn kiểm toán. Không ít trường hợp yêu cầu từ nội bộ và bên ngoài này trở thành thời hạn có hiệu lực trước cả rủi ro kỹ thuật.
Chi phí thay thế hệ thống khoảng bao nhiêu
Vì quy mô và hiện trạng làm thay đổi cả bậc chữ số nên không thể đưa ra dưới dạng một mức giá thị trường. Ngay cả với nhà máy cùng quy mô, chỉ riêng việc hệ thống hiện tại có được tài liệu hóa hay không đã làm công sức khảo sát chênh nhau vài lần.
Cách tiến hành thực tế không phải là đi tìm giá của công ty khác, mà là đặt cạnh nhau hai con số của chính công ty mình. Một là tổng chi phí lũy kế nếu kéo dài tuổi thọ hệ thống hiện tại thêm 5 năm nữa, bao gồm hỗ trợ có phí như ESU, chi phí sửa đổi ngày một tăng và chi phí nhân công đang tiêu tốn cho việc bù đắp bằng Excel. Hai là tổng chi phí 5 năm của hệ thống mới. Đặt hai con số này lên cùng một bàn cân thì không cần biết giá thị trường bạn vẫn quyết định được. Về cách dựng cơ cấu chi phí, xin tham khảo bài viết phân tách chi phí bảo trì hệ thống.
Ngoài thay thế toàn diện, có cách nào kéo dài tuổi thọ không
Có. Tại thời điểm năm 2026, dòng chính là cấu hình lai: giữ nguyên logic nghiệp vụ lõi và chỉ mở rộng các chức năng ngoại vi trên đám mây. Chuyển đổi theo giai đoạn được xem là lời giải thực tế hơn chuyển đổi toàn bộ, với ưu điểm là không phải vứt bỏ những logic đã xây đắp nhiều năm.
Tuy nhiên, cách này chỉ khả thi khi hội đủ một số điều kiện. Bản thân logic nghiệp vụ lõi vẫn còn hiệu quả, và nền tảng đang chứa phần lõi đó vẫn còn dư thời hạn. Nếu thời hạn của nền tảng còn chưa đầy 1 năm thì dù muốn giữ lõi, cái nền bên dưới cũng hết hạn trước. Trường hợp này không phải là cấu hình lai, mà trước hết cần chuyển đổi nền tảng.
Tổng kết
Sự lão hóa của hệ thống quản lý sản xuất không đo được bằng tỷ lệ vận hành. Các điểm cốt lõi để phán đoán có thể tóm lại như sau.
Việc hệ thống đang chạy và việc nó an toàn là hai chuyện khác nhau. Hỗ trợ mở rộng của IBM i 7.3 kết thúc vào ngày 30 tháng 9 năm 2026, và cùng ngày đó cũng là ngày kết thúc hỗ trợ tiêu chuẩn của IBM i 7.4. Một số mẫu IBM Power9 kết thúc bảo trì tiêu chuẩn phần cứng vào ngày 31 tháng 1 năm 2026, còn hỗ trợ mở rộng của Windows Server 2016 kết thúc vào ngày 12 tháng 1 năm 2027. Tình trạng 74% doanh nghiệp lớn của Nhật Bản vẫn đang sở hữu hệ thống legacy tuy phổ biến nhưng không đồng nghĩa với an toàn.
Dấu hiệu lão hóa hiện ra ở sự bào mòn vận hành chứ không ở chỉ số kỹ thuật. Việc bù đắp bằng Excel trở thành thường lệ, báo giá tăng vọt, bộ máy bảo trì của nhà cung cấp thu hẹp, kiểm toán bảo mật nêu vấn đề. Cả bốn dấu hiệu này đều không được ghi nhận như sự cố, nên chúng cùng tồn tại với những báo cáo “không có vấn đề” dựa trên tỷ lệ vận hành.
Quyết định có thể được cấu trúc hóa bằng cách chấm 6 biến số: số năm còn lại đến hạn hỗ trợ, mức xấu đi của thời gian khôi phục sự cố, phạm vi bù đắp bằng Excel, mức thu hẹp của bộ máy bảo trì phía nhà cung cấp, điểm bị nêu trong kiểm toán bảo mật và yêu cầu kết nối với các hệ thống xung quanh. Tổng điểm phân thành bốn mức: theo dõi, bắt đầu lập kế hoạch, đưa vào ngân sách, khởi động ngay. Tuy nhiên nếu hạn hỗ trợ còn dưới 1 năm thì bất kể tổng điểm, hãy xử lý ở mức đưa vào ngân sách.
Nước đi không chỉ có làm mới toàn bộ. Hãy so sánh bốn lựa chọn: gia hạn hợp đồng bảo trì, kéo dài tuổi thọ theo hướng lai, chuyển toàn bộ sang gói phần mềm, và xây dựng lại từ đầu. Lời giải thực tế tại thời điểm năm 2026 là cấu hình lai giữ lõi và mở rộng phần ngoại vi trên đám mây.
Và cuối cùng là thời gian. Từ khi có thông báo EOSL đến khi vận hành chính thức mất 12-18 tháng. Biết hay không biết con số này sẽ làm thời điểm khởi động lệch nhau tới một năm.
Hệ thống của công ty bạn hiện đang ở khoảng điểm nào, nên kéo dài tuổi thọ hay nên chuyển đổi, dù bạn còn đang phân vân thì cũng không sao. Chỉ cần biết phiên bản nền tảng và mức tải vận hành đang phát sinh, chúng tôi có thể gửi lại kết quả chấm điểm sơ bộ theo 6 biến số cùng những lựa chọn khả thi. Xem đây như một cuộc trao đổi ở giai đoạn trước báo giá, xin cứ thoải mái liên hệ với chúng tôi qua trang liên hệ. Dựa trên kinh nghiệm triển khai và chuyển đổi tại Thái Lan, chúng tôi sẽ trao đổi về phạm vi không quá đà mà cũng không trì hoãn.
Thông tin tham khảo
- Về việc kết thúc hỗ trợ mở rộng của IBM i 7.3 và kết thúc hỗ trợ tiêu chuẩn của IBM i 7.4 – C3index
- Về việc kết thúc bảo trì tiêu chuẩn phần cứng của các mẫu IBM Power9 – C3index
- Hướng dẫn hiện đại hóa AS/400 và IBM i 2026 – Aurant Technologies
- Lập kế hoạch cho việc kết thúc hỗ trợ Windows Server 2016 – Microsoft
- Rủi ro khi hết hạn bảo trì, thời gian cần cho một dự án thay thế và các dấu hiệu thực tế để bắt đầu cân nhắc – Venture Net
- “Vách đá năm 2025” vẫn chưa kết thúc trong năm 2026 – ITmedia Enterprise
- Hoàn tất chuyển toàn bộ hệ thống lõi của tất cả nhà máy thép và cơ sở sản xuất sang môi trường mở – JFE Steel
