Triển khai hệ thống quản lý sản xuất thất bại | 5 đứt gãy

Chuyện một dự án triển khai hệ thống quản lý sản xuất thất bại thường chỉ được kể sau khi hệ thống đã chạy chính thức. Hiện trường không dùng, giấy tờ vẫn còn, Excel quay trở lại. Nhưng đó là triệu chứng, không phải nguyên nhân. Đọc dữ liệu khảo sát của JUAS, có thể thấy chất lượng, ngân sách và tiến độ được giải thích phần lớn bởi quy mô dự án và cách lập kế hoạch, và phần lớn những điều đó đã được quyết định từ hơn một năm trước ngày go-live. Bài viết này sắp xếp lại năm điểm đứt gãy quyết định thất bại, theo thứ tự bên đặt hàng có thể chủ động can thiệp.

Thất bại khi triển khai hệ thống quản lý sản xuất được quyết định ở giai đoạn lập kế hoạch, không phải ngày go-live

Hầu hết các buổi tổng kết dự án đều diễn ra sau khi hệ thống đã vận hành. Đi một vòng nhà xưởng sau ba tháng go-live, bạn sẽ thấy màn hình nhập số liệu thực hiện bỏ trống, lệnh sản xuất được in ra rồi ghi tay lên đó, và một bảng kế hoạch sản xuất bằng Excel do ai đó dựng lại trên máy tính cá nhân. Từ đây sinh ra những kết luận quen thuộc: hiện trường phản kháng mạnh, đào tạo chưa đủ.

Những kết luận đó đúng ở góc độ quan sát, nhưng vô dụng ở góc độ hành động. Việc hiện trường không dùng hệ thống là kết quả, nó không giải thích vì sao đặc tả lại được thiết kế đến mức không dùng được. Tăng đào tạo cũng vô ích nếu trong quy trình vốn không có thời gian để nhập liệu. Xoa dịu phản kháng cũng vô ích nếu dữ liệu danh mục không khớp với thực tế, vì màn hình sẽ không bao giờ cho ra con số đúng.

Khi truy ngược trong thực tế công việc, mọi triệu chứng quan sát được sau go-live đều dẫn về những quyết định đã đặt ra từ 12 đến 18 tháng trước đó. Dự án được chia thành các mảng lớn cỡ nào, ai định nghĩa ngưỡng đạt của go-live và định nghĩa ra sao, ai là người viết ra nghiệp vụ hiện hành thành văn bản, thiết kế có bao gồm dữ liệu danh mục và cửa ngõ nhập số liệu thực hiện hay không, và tại nhà máy có ai đủ sức tiếp nhận vận hành hay không. Bốn điểm đầu thuộc phần thượng nguồn và thường được chốt trong vòng vài tháng kể từ khi khởi động dự án. Chỉ riêng việc bàn giao vận hành là còn có thể can thiệp đến sát ngày go-live, nhưng quỹ thời gian dành cho nó lại đã bị bốn quyết định thượng nguồn ấn định từ trước.

Điều quan trọng là trong năm điểm này, bên đặt hàng thực sự chỉ có hai điểm có thể tự do quyết định trước khi khởi động: cách chia nhỏ dự án, và ai sẽ viết đặc tả. Ba điểm còn lại phụ thuộc rất chặt vào hai quyết định đó. Nói cách khác, trước cả chuyện chọn nhà cung cấp giỏi hay dở, việc bạn có tự mình chốt được hai điểm này hay không mới là ngã rẽ.

Bảng dưới đây tóm tắt năm điểm đứt gãy được bàn trong bài. Mỗi chương tiếp theo sẽ đào sâu đúng một dòng của bảng này.

Năm điểm này không độc lập với nhau. Nếu chia sai ở đứt gãy 2, thời gian để viết đặc tả ở đứt gãy 3 biến mất, việc chỉnh trang dữ liệu danh mục ở đứt gãy 4 bị đẩy về sau, và thời gian đào tạo ở đứt gãy 5 bị cắt cuối cùng. Thất bại không xảy ra ở một chỗ, nó tiến triển theo kiểu quyết định thượng nguồn triệt tiêu dần các lựa chọn ở hạ nguồn.

Nhìn thất bại bằng dữ liệu — chất lượng, ngân sách và tiến độ phụ thuộc vào quy mô dự án

Để không bắt đầu bằng cảm tính, hãy đặt trước dữ liệu khảo sát đã công bố. Nguồn tham chiếu là báo cáo “Khảo sát xu hướng CNTT doanh nghiệp 2026” do Hiệp hội Người dùng Hệ thống Thông tin Nhật Bản (JUAS) công bố tháng 4 năm 2026 (khảo sát năm tài chính 2025, khoảng 950 đến 1,000 doanh nghiệp trả lời). Đây là khảo sát theo dõi các doanh nghiệp người dùng tại Nhật theo chuỗi thời gian dài, trong đó mức độ tuân thủ chất lượng, ngân sách và tiến độ (QCD) của phát triển hệ thống được tổng hợp liên tục.

Theo khảo sát này, mức độ tuân thủ QCD trong phát triển hệ thống có xu hướng đi xuống trong suốt mười năm qua. Điểm đáng chú ý là cơ cấu bên trong con số đó tách bạch rất rõ theo quy mô dự án. Các dự án quy mô nhỏ tương đối tốt, trong khi ở các dự án từ 500 người-tháng trở lên, cả chất lượng, ngân sách lẫn tiến độ đều có 30 đến 50 phần trăm bị đánh giá tiêu cực.

Chỉ riêng điểm này đã mang hàm ý lớn cho thực tế công việc. Bởi có thể đọc rằng “làm thật lớn để xong một lần” không phải là theo đuổi hiệu quả, mà là chồng thêm rủi ro. Chia nhỏ không phải là nhượng bộ, đó là một trong số ít biện pháp hữu hiệu quan sát được bằng thống kê.

Các khảo sát nước ngoài cũng chỉ về cùng hướng. Trong khảo sát năm 2024 của Gartner được Viện Nghiên cứu Nomura giới thiệu, hơn 70 phần trăm dự án triển khai hoặc đổi mới gói ERP kết thúc mà không đạt được mục tiêu kinh doanh đề ra ban đầu. Điều cần lưu ý ở đây là “thất bại” này không có nghĩa hệ thống không chạy. Hệ thống vẫn chạy. Chạy rồi mà vẫn không chạm tới mục tiêu quản trị đặt ra lúc đầu. “Đứt gãy mục đích” ở đứt gãy 1 chính là vấn đề mà con số này đang chỉ ra.

Cũng trong khảo sát này của JUAS, tỷ lệ doanh nghiệp tăng ngân sách CNTT trong năm tài chính 2025 là 52.6%, chỉ số DI đạt 43.3 điểm, tăng năm năm liên tiếp, và DI dự báo cho năm tài chính 2026 là 39.9 điểm. Các lý do tăng ngân sách được nêu nhiều nhất là nâng cấp, thay mới và tăng cường chức năng cho hệ thống hiện hữu 66.3%, đồng yên yếu cùng chi phí nhân sự và chi phí nhà cung cấp tăng cao 46.6%, và gia tăng dịch vụ đám mây 45.0% (đây là câu hỏi nhiều lựa chọn, nên mỗi con số là tỷ lệ doanh nghiệp có nêu lý do đó). Có thể đọc ra bức tranh rằng ngân sách tuy tăng nhưng động lực chính của phần tăng thêm nằm ở việc duy trì, cập nhật hệ thống cũ và ở đơn giá leo thang. Không có nghĩa là hạn mức dành cho các sáng kiến mới tự động rộng ra. Khi đã thất bại một lần, cơ hội làm lại sẽ bị đẩy sang chu kỳ ngân sách kế tiếp.

Nguyên nhân số một khiến tiến độ xấu đi là thiếu cân nhắc khi lập kế hoạch, ngân sách là thay đổi đặc tả liên tục, chất lượng là nhà cung cấp thiếu kỹ năng

Cũng trong khảo sát năm tài chính 2025 của JUAS, nguyên nhân đứng đầu khiến từng yếu tố QCD xấu đi được sắp xếp như sau.

Ba dòng này gần như vô hiệu hóa những cặp đối lập thường được đem ra tranh luận.

Thứ nhất là lập luận “cứ dùng gói phần mềm là không thất bại”. Việc nguyên nhân số một khiến tiến độ xấu đi là thiếu cân nhắc khi lập kế hoạch, và nguyên nhân số một khiến ngân sách xấu đi là thay đổi đặc tả liên tục, hoàn toàn độc lập với lựa chọn phương thức hiện thực hóa là gói sẵn hay viết mới. Chọn gói sẵn mà lúc lập kế hoạch không tính công hấp thụ độ vênh nghiệp vụ thì tiến độ vẫn trễ, và nếu sát ngày go-live mới phát hiện “thiếu biểu mẫu này thì không xuất hàng được” thì thay đổi đặc tả vẫn nổ ra hàng loạt. Cuộc tranh luận về phương thức hiện thực hóa không giải quyết được hai điều đó.

Thứ hai là lập luận “giao cho nhà cung cấp lớn là yên tâm”. Việc nguyên nhân số một khiến chất lượng xấu đi là nhà cung cấp thiếu kỹ năng, và con số này chiếm tới 60% doanh nghiệp không hài lòng về chất lượng, có nghĩa lựa chọn nhà cung cấp vẫn là rủi ro chất lượng lớn nhất. Tuy nhiên điều thực sự có tác dụng không phải quy mô công ty, mà là người được phân công cụ thể có hiểu hình thái sản xuất của ngành đó hay không. Giữa sản xuất theo đơn hàng riêng lẻ và sản xuất lặp lại, các chức năng nằm dưới cùng một cụm từ “hệ thống quản lý sản xuất” khác nhau hoàn toàn.

Thứ ba là lập luận “bắt đầu nhỏ rồi cuối cùng cũng phải làm lại”. Vì mức tuân thủ QCD trong dữ liệu JUAS càng tốt khi dự án càng nhỏ, kết luận phù hợp với dữ liệu hơn là bản thân việc chia nhỏ đã là biện pháp giảm rủi ro chủ đạo. Lựa chọn làm hết mọi thứ một lần vì sợ phải làm lại chính là hành vi tự đưa mình vào dải từ 500 người-tháng trở lên.

Đứt gãy 1 — Đứt gãy mục đích, khi bản thân việc go-live trở thành mục đích

Viện Nghiên cứu Nomura sắp xếp nguyên nhân thất bại của các dự án triển khai và đổi mới ERP thành ba nhóm: thiếu tầm nhìn (sao Bắc Đẩu), khoảng cách nhận thức giữa hiện trường và cấp quản lý, và khó khăn trong quản lý tích hợp giữa nhiều dự án song song.

Trong đó, “thiếu sao Bắc Đẩu” chính là đứt gãy 1. Đó là hiện tượng mục đích lặng lẽ bị thay thế, từ “giải quyết bài toán quản trị” thành “chạy được đúng ngày đã hẹn” khi dự án tiến triển.

Cách thay thế này có khuôn mẫu rõ ràng. Tài liệu khởi động dự án bao giờ cũng ghi những mục đích rất đẹp: rút ngắn lead time, giảm tồn kho, minh bạch giá thành. Nhưng rồi giai đoạn xác định yêu cầu kéo dài, khâu kiểm thử phát sinh lỗi, và khi ngày go-live đến gần, nội dung các cuộc họp chỉ còn lại một câu hỏi duy nhất là còn gì chưa xong. Đến lúc đó, không còn ai nhắc lại mục đích ban đầu. Khoảnh khắc toàn bộ chức năng chạy được đúng ngày go-live, dự án được báo cáo là thành công. Con số hơn 70 phần trăm không đạt mục tiêu kinh doanh ban đầu trong khảo sát của Gartner chính là sự chênh lệch giữa báo cáo và thực tế, được lượng hóa.

Nguyên nhân thất bại thứ hai, khoảng cách nhận thức giữa hiện trường và cấp quản lý, cũng phái sinh từ đứt gãy mục đích. Mục đích mà cấp quản lý nói đến là các chỉ số quản trị, còn thứ hiện trường nhận được là khối lượng nhập liệu tăng thêm. Nếu không có một ngôn ngữ trung gian bắc cầu giữa hai điều đó, với hiện trường thì việc triển khai hệ thống không mang ý nghĩa nào khác ngoài “một sự kiện làm tăng việc”.

Đổi tiêu chí đánh giá go-live từ “có chạy không” sang “đã giảm được cái gì”

Chỉ có một cách bịt được đứt gãy này. Đó là định nghĩa ngưỡng đạt của go-live bằng sự thay đổi của nghiệp vụ chứ không phải bằng hoạt động của chức năng, và ghi nó thành văn bản ngay từ giai đoạn lập đề án.

Cụ thể, hãy chốt trước các chỉ số sẽ đo sau go-live một khoảng thời gian nhất định, kèm theo con số và phương pháp đo. Điều quan trọng không phải bản thân chỉ số, mà là chốt trước “ai đo và đo bằng cách nào”. Chỉ số nào chưa có phương pháp đo thì chắc chắn sẽ không được đo sau khi hệ thống chạy.

Điền đủ bảng này cho ba đến năm hạng mục ngay từ giai đoạn lập đề án sẽ làm thay đổi tính chất của cả dự án. Bởi khi có đề xuất bổ sung chức năng trong lúc xác định yêu cầu, câu hỏi “chức năng đó tác động lên giá trị mục tiêu nào” mới trở nên có căn cứ. Đề xuất nào không trả lời được câu hỏi đó thì hạ mức ưu tiên cũng chẳng ai thiệt. Tình trạng thay đổi đặc tả liên tục nói ở đứt gãy 3 phần lớn bắt nguồn từ việc câu hỏi này chưa được chuẩn bị sẵn.

Giá trị mục tiêu có thể đặt khiêm tốn, không sao cả. Thậm chí điều quan trọng hơn là thu hẹp về phạm vi đo được trong giai đoạn đầu tiên. Những chỉ số như tổng giá trị tồn kho toàn công ty sẽ không nhúc nhích sau ba tháng, và có quá nhiều yếu tố ngoài hệ thống nên không giải thích được quan hệ nhân quả. Hãy chọn chỉ số đo được, giải thích được là nó chuyển động, và hiện trường cảm nhận được.

Đứt gãy 2 — Đứt gãy quy mô, chia thời gian triển khai và người-tháng ra sao

Với câu hỏi triển khai hệ thống quản lý sản xuất mất bao lâu, nói thật thì không có câu trả lời duy nhất. Bởi phạm vi, số lượng nhà máy, hình thái sản xuất và tình trạng hệ thống hiện hữu có thể làm con số lệch nhau cả một bậc. Nhưng có thể đổi sang một câu hỏi trả lời được: một giai đoạn nên cắt ở đâu.

Điều dữ liệu JUAS chỉ ra là quan hệ giữa quy mô và QCD. Từ 500 người-tháng trở lên thì cả chất lượng, ngân sách và tiến độ đều có 30 đến 50 phần trăm tiêu cực, còn dự án nhỏ tương đối tốt. Nghĩa là thiết kế thời gian triển khai không phải công việc ước lượng tổng khối lượng, mà là công việc chia tổng khối lượng sao cho ra khỏi dải rủi ro.

Vượt 50 người-tháng và 6 tháng cho một giai đoạn thì hãy nghi ngờ và chia nhỏ

Như một mốc thực dụng, tại công ty chúng tôi, khi xuất hiện kế hoạch vượt quá 50 người-tháng và 6 tháng cho một giai đoạn, việc đầu tiên là xem xét khả năng chia nhỏ. Đây không phải con số do JUAS đưa ra mà là ngưỡng vận hành từ thực tế hiện trường. Có ba căn cứ.

Thứ nhất là khoảng thời gian con người còn nhớ được đặc tả. Nếu từ lúc xác định yêu cầu đến go-live vượt quá 6 tháng, các bên liên quan sẽ không còn nhớ nổi bối cảnh của những đặc tả chốt ở giai đoạn đầu. Khi “vì sao lại chọn đặc tả này” biến mất, mọi cảm giác lấn cấn xuất hiện lúc kiểm thử chỉ còn cách xử lý dưới dạng thay đổi đặc tả.

Thứ hai là luân chuyển nhân sự phía nghiệp vụ và sự thay đổi của mặt hàng sản xuất. Sau nửa năm đến một năm, người đưa ra yêu cầu đã chuyển bộ phận, sản phẩm mục tiêu đã kết thúc vòng đời, và dây chuyền mới được dựng lên. Dự án kéo dài đồng nghĩa với việc phải ngắm mãi một mục tiêu di động.

Thứ ba là mức độ chi tiết của việc ra quyết định. Giai đoạn càng lớn thì càng khó ra quyết định dừng lại hay đổi hướng giữa chừng. Vì chi phí đã bỏ ra quá lớn, dự án không dừng được ngay cả khi đã thấy rõ hướng đi không ổn. Giá trị bản chất của việc chia nhỏ không nằm ở cắt giảm chi phí, mà ở chỗ có được nhiều cơ hội ra quyết định.

Về cách cắt, chia theo ranh giới khép kín của nghiệp vụ sẽ hiệu quả hơn chia theo chức năng.

Trong đó, cách cắt theo dữ liệu đặc biệt hiệu quả với những nhà máy từng có kinh nghiệm thất bại. Vì các chức năng kế hoạch phụ thuộc vào độ chính xác của dữ liệu thực hiện tại hiện trường, xây chức năng kế hoạch khi số liệu thực hiện chưa vào được thì cũng không chạy. Đặt thu thập số liệu thực hiện và trực quan hóa vào giai đoạn đầu tiên nghĩa là vượt qua trước đứt gãy 4 sẽ nói ở phần sau, rồi mới tiến sang phần kế hoạch.

Về bản thân việc thiết kế cách chia, bài triển khai hệ thống theo hướng khởi đầu nhỏ sắp xếp riêng cách xác định phạm vi giai đoạn đầu tiên và cách tạo điểm nối sang giai đoạn kế tiếp. Phần khó của việc chia nhỏ không nằm ở chỗ “làm cho nhỏ”, mà ở chỗ “vẫn nhỏ mà vẫn nối được với nhau”.

Có một thứ nhất định phải chốt trước khi chia. Đó là dữ liệu danh mục và hệ thống mã dùng chung giữa các giai đoạn. Nếu để mỗi giai đoạn tự quyết phần này, đến lúc tích hợp sẽ phải dựng lại toàn bộ dữ liệu và lợi ích của việc chia nhỏ biến mất. Riêng hệ thống mã hàng, mã công đoạn, mã đối tác và mã nhà máy phải được toàn công ty chốt xong trước giai đoạn đầu tiên.

Đứt gãy 3 — Đứt gãy đặc tả, không ai giải thích được nghiệp vụ hiện hành

Trong khảo sát của JUAS có một câu hỏi về rào cản khi đẩy mạnh nội bộ hóa phát triển (nhiều lựa chọn, n=953). Đứng đầu là thiếu số lượng nhân lực phát triển 52.7%, thiếu chất lượng nhân lực phát triển 49.6%, thiếu nhân lực quản lý dự án 44.4%, nhưng nặng hơn trong thực tế lại là các mục xếp ngay sau đó.

Thiếu hiểu biết về nghiệp vụ hiện hành 38.2%, không chuyển được yêu cầu kinh doanh thành đặc tả hệ thống 34.5%, không nắm được đặc tả hệ thống hiện hành 25.9%. Đây không phải thiếu năng lực phát triển. Đây là tình trạng không giải thích nổi chính công ty mình đang làm việc như thế nào.

Cũng theo khảo sát của JUAS, khoảng 60 phần trăm doanh nghiệp đang nội bộ hóa một phần hoặc toàn bộ hoạt động phát triển hệ thống và tìm cách phân vai giữa tự làm và thuê ngoài, trong đó đối tượng nội bộ hóa tập trung vào các công đoạn thượng nguồn như hoạch định hệ thống và xác định yêu cầu. Đang muốn giành lại phần thượng nguồn về tay mình, nhưng lại thiếu chính thứ mà thượng nguồn cần, là hiểu biết về nghiệp vụ hiện hành. Đó là cấu trúc hiện nay của các doanh nghiệp người dùng. Cùng khảo sát đó, các năng lực bị coi là thiếu hụt nhất trong tổ chức CNTT gồm tuyển dụng và đào tạo nhân lực CNTT 73.9%, khai thác và quản trị dữ liệu 71.9%, tìm kiếm và đánh giá công nghệ mới 69.5% (n khoảng 946), cũng chỉ về cùng một hướng.

Trong tình trạng đó mà khoán trắng phần xác định yêu cầu cho nhà cung cấp thì chuyện gì xảy ra. Nhà cung cấp không biết nghiệp vụ hiện hành nên sẽ thiết kế dựa trên một luồng nghiệp vụ tiêu chuẩn. Đến lúc kiểm thử, khi hiện trường bắt đầu chạm tay vào, hàng loạt ý kiến “bên tôi không làm như vậy” nổ ra cùng lúc. Đó chính là thực chất của nguyên nhân số một khiến ngân sách xấu đi, tức thay đổi đặc tả liên tục. Thay đổi đặc tả không phải sự tùy tiện của hiện trường, đó là món nợ trả chậm của việc nghiệp vụ hiện hành chưa được ghi thành tài liệu ở thời điểm xác định yêu cầu.

Cách xử lý thì rất mộc mạc. Trước khi đặt hàng, hãy tự tay bên đặt hàng viết ra nghiệp vụ hiện hành. Không cần vẽ sơ đồ luồng nghiệp vụ đầy đủ mọi ngóc ngách. Chỉ cần viết bốn điểm sau, mỗi nghiệp vụ mục tiêu gói trong một trang là đủ.

Mục thứ tư hay bị xem nhẹ nhưng lại tác động trực tiếp đến chi phí. Nếu báo giá được lập trên giả định bê nguyên biểu mẫu hiện hành sang, thì sẽ có công sức bị chất thêm chỉ để phục vụ những mục mà thực tế không ai nhìn. Kiểm kê hiện trạng không phải công việc để thêm chức năng, đó là công việc để tạo căn cứ mà cắt bớt.

Ranh giới giữa tùy chỉnh và phát triển từ đầu cho hệ thống quản lý sản xuất

Chỉ khi nghiệp vụ hiện hành đã thành tài liệu thì mới phán đoán được nên đi bằng tùy chỉnh gói phần mềm hay phát triển từ đầu (bao gồm cả tự làm nội bộ). Có rất nhiều dự án làm ngược thứ tự này, chọn sản phẩm xong mới bắt đầu đếm độ vênh nghiệp vụ, nên đến khi biết độ vênh lớn cỡ nào thì cả ngân sách lẫn thời gian đều không còn xê dịch được nữa.

Phán đoán được thực hiện theo từng vùng chức năng, không phải cho toàn bộ nghiệp vụ. Ngay trong một hệ thống, vùng dùng chức năng chuẩn là đủ và vùng cần làm riêng theo đặc thù công ty chắc chắn sẽ tách ra.

Nguyên tắc phán đoán rất rõ ràng. Vùng nào không gắn trực tiếp với năng lực cạnh tranh và làm giống các công ty khác cũng được thì dồn về chức năng chuẩn. Ngược lại, vùng chứa đựng thế mạnh riêng của công ty và vùng bị khách hàng hoặc cơ quan quản lý chỉ định mẫu biểu thì đáng để làm riêng. Làm riêng tất cả thì không bảo trì nổi, dồn tất cả về chuẩn thì hiện trường không chạy được.

Ngoài chi phí, tùy chỉnh còn kéo theo hai loại chi phí duy trì. Một là gánh nặng kiểm chứng lại khi nâng cấp phiên bản. Những chỗ đã can thiệp vào chức năng chuẩn sẽ phải kiểm tra hoạt động mỗi lần sản phẩm cập nhật. Hai là sự phụ thuộc vào cá nhân. Nếu đặc tả phần chế lại không được ghi thành tài liệu, đến khi người phụ trách thay đổi thì nó trở thành hộp đen không ai dám động vào. Khi quyết định tùy chỉnh, hãy đưa việc nhận bàn giao tài liệu đặc tả phần chế lại và danh sách các điểm đã chế lại vào hợp đồng như một hạng mục bàn giao.

Về bản thân các trục so sánh sản phẩm, bài so sánh các hệ thống quản lý sản xuất sắp xếp mức độ phù hợp theo hình thái sản xuất và những tiêu chí đánh giá không xuất hiện trên bảng so sánh. Lựa chọn sản phẩm là công đoạn đến sau đứt gãy 3, và giữ đúng thứ tự chính là quyết định có hiệu quả chi phí cao nhất.

Đứt gãy 4 — Đứt gãy dữ liệu, hệ thống không có số liệu thực hiện sẽ chết ngay tháng sau

Khi một hệ thống quản lý sản xuất đã chạy nhưng vài tháng sau không còn ai dùng, nguyên nhân hầu hết nằm ở dữ liệu. Hoặc con số hiển thị trên màn hình không khớp với thực tế, hoặc con số vốn dĩ không vào được hệ thống. Chỉ một trong hai điều đó.

Khi các con số mất uy tín, hiện tượng tiến triển theo một chiều. Đầu tiên hiện trường bắt đầu kiểm tra lại con số trên màn hình. Tiếp theo, để kiểm tra lại thì họ mở Excel và quản lý song song. Cuối cùng, Excel trở thành bản chính còn hệ thống chỉ còn là nơi để nhập liệu. Quá trình này diễn ra rất nhanh, không hiếm trường hợp nó đã bắt đầu ngay trong tháng sau go-live.

Đứt gãy dữ liệu chia làm hai phía, phía dữ liệu danh mục và phía số liệu thực hiện.

Đo độ chính xác của dữ liệu danh mục trước khi chuyển đổi

Việc chuyển đổi dữ liệu danh mục ở nhiều dự án bị coi là “công việc bê dữ liệu sang” và bị đẩy về công đoạn sau. Nhưng trên thực tế, độ chính xác của dữ liệu danh mục chính là chất lượng vận hành hiện tại, và bê sang thì nó cũng không tự tốt lên.

Bốn thứ sau nhất định phải đo trước khi chuyển đổi. Đo ở đây nghĩa là rút mẫu ra và đối chiếu với hiện vật.

Trong đó BOM và thời gian định mức là tiền đề của tính nhu cầu vật tư và tính tải công đoạn. Nếu cho chức năng kế hoạch chạy khi tiền đề đã vỡ, sẽ không ai tin kế hoạch do hệ thống đưa ra, và rốt cuộc quay lại điều chỉnh bằng kinh nghiệm. Tình trạng này bị đánh giá là “hệ thống không dùng được”, nhưng thực ra thứ không dùng được là dữ liệu danh mục.

Nếu kết quả đo xấu thì có hai lựa chọn. Hoặc chỉnh trang trước khi chuyển đổi, hoặc loại chức năng đó ra khỏi giai đoạn đầu tiên. Vì chỉnh trang tốn thời gian, hãy phán đoán gắn liền với thiết kế chia giai đoạn ở đứt gãy 2. Điều cần tránh nhất là để lại trong phạm vi go-live những chức năng mà phần chỉnh trang chưa xong.

Phía số liệu thực hiện còn đơn giản hơn, tất cả nằm ở chỗ thời gian để nhập liệu có được bảo đảm ngay trong công đoạn hay không. Cách vận hành gom lại nhập một lượt vào cuối ngày chắc chắn sẽ giảm độ chính xác. Lý do là nó dựa vào trí nhớ. Số liệu thực hiện cần được nhập ngay tại nơi công việc kết thúc, như một phần của chính công việc đó.

Lấy tự động là lý tưởng nhưng không phải công đoạn nào cũng làm được. Trên thực tế, tổ hợp khả thi là công đoạn nào tự động hóa được thì tự động hóa, phần còn lại dồn về quét mã vạch, và nhập tay chỉ giới hạn cho xử lý ngoại lệ.

Còn một điểm nữa là kết nối với hệ thống lõi. Khi nối kế toán hoặc quản lý bán hàng với quản lý sản xuất, thứ phải chốt trước cả phương thức kỹ thuật của giao diện là bên nào giữ dữ liệu gốc. Với từng đối tượng gồm danh mục mã hàng, danh mục đối tác và số lượng tồn kho, hãy chốt từng dòng một xem hệ thống nào là bản gốc và hệ thống nào là bản sao. Nếu kết nối khi điểm này còn mơ hồ, cả hai bên đều cập nhật được và không ai biết bên nào đúng. Chu kỳ đồng bộ (thời gian thực hay theo ngày) và cách phát hiện khi đồng bộ thất bại cũng là những mục phải chốt lúc thiết kế.

Đứt gãy 5 — Đứt gãy vận hành, tại nhà máy ở Thái Lan thì “bám rễ” mới là ải cuối cùng

Bốn điểm nêu trên đúng cả ở Nhật lẫn ở các cơ sở nước ngoài. Riêng đứt gãy 5 thì trọng lượng thay đổi ở các cơ sở nước ngoài, đặc biệt là tại các nhà máy Nhật ở Thái Lan.

Khi mang một hệ thống thiết kế tại trụ sở Nhật triển khai xuống nhà máy ở Thái Lan, có một tiền đề được đặt ra một cách ngầm định: “người thao tác sẽ đọc tài liệu hướng dẫn bằng tiếng Nhật hoặc tiếng Anh và hiểu bối cảnh của các quy tắc nghiệp vụ”. Không nhiều cơ sở đáp ứng được tiền đề đó. Những điều dưới đây không phải thống kê, mà là cấu trúc lặp đi lặp lại trong thực tế công việc (về môi trường kinh doanh của doanh nghiệp Nhật tại Thái Lan, xin tham khảo khảo sát xu hướng mở rộng hoạt động của JETRO nêu ở mục nguồn tham khảo cuối bài).

Thứ nhất là ngôn ngữ. Nếu nhãn trên màn hình và thông báo lỗi vẫn để nguyên tiếng Nhật hoặc tiếng Anh, người thao tác bản địa không đọc được nội dung. Hành vi con người trước một màn hình không đọc được là cố định: học thuộc vị trí, bấm đúng nút ở đúng chỗ theo đúng thứ tự. Ở trạng thái này, chỉ cần bố cục màn hình thay đổi một chút là phải đào tạo lại, và khi có ngoại lệ thì không ai phán đoán được.

Thứ hai là phạm vi đào tạo. Ở Nhật, nhiều khi chỉ cần dạy thao tác hệ thống là đủ. Lý do là bối cảnh của quy tắc nghiệp vụ vốn đã được chia sẻ sẵn. Ở cơ sở nước ngoài, cần giải thích từ ngữ cảnh nghiệp vụ, rằng vì sao phải nhập dữ liệu này và con số này sẽ được dùng vào việc gì ở công đoạn sau. Nếu chỉ huấn luyện thao tác, việc nhập liệu sẽ trở nên hình thức và độ chính xác không tăng.

Thứ ba là biến động nhân sự. Nếu đặt trên tiền đề rằng người thao tác và cán bộ quản lý hiện trường sẽ thay đổi, thì vận hành phải nằm trong tài liệu quy trình chứ không nằm ở mức thành thạo của cá nhân. Chất lượng vận hành sau một năm sẽ khác nhau tùy vào việc tài liệu quy trình lập lúc go-live có tồn tại bằng tiếng bản địa hay không, và có ai được giao trách nhiệm cập nhật hay không.

Thứ tư là ranh giới giữa chuẩn của trụ sở và tối ưu tại chỗ. Hệ thống mã và mẫu biểu mà trụ sở đã chốt làm chuẩn toàn công ty thì cần tuân thủ, nhưng nếu ép cả những dòng chảy thương mại và yêu cầu khách hàng đặc thù bản địa vào chuẩn của trụ sở, hiện trường chắc chắn sẽ lập Excel riêng ở phía sau. Hãy phân định rõ ràng phạm vi phải giữ và phạm vi giao cho bản địa, từ trước khi go-live. Trong thực tế, cách phân chia ít đổ vỡ nhất là hệ thống mã, cấu trúc dữ liệu danh mục và các mục kết nối kế toán theo chuẩn trụ sở, còn phương thức nhập số liệu thực hiện, bố cục biểu mẫu tại hiện trường và ngôn ngữ thì để bản địa quyết định.

Thứ năm là bộ máy hỗ trợ ngay sau go-live. Trong một tháng đầu, mỗi ngày đều xuất hiện những ngoại lệ không lường trước. Nếu trong giai đoạn này không có người tại chỗ trả lời được câu hỏi, hiện trường sẽ tự dựng cách vận hành theo phán đoán của họ, và cách đó sẽ bám rễ. Sửa về sau tốn kém hơn làm đúng ngay từ đầu.

Về cách đưa các điểm này vào kế hoạch, bài triển khai hệ thống cho cơ sở ở nước ngoài sắp xếp cùng với việc phân vai giữa trụ sở và bản địa cũng như cách xác định thứ tự triển khai.

Quy trình triển khai tránh thất bại — sáu điều phải chốt trước khi đặt hàng

Chuyển năm điểm đứt gãy nói trên thành hành động trước khi đặt hàng thì được sáu mục. Thứ tự có ý nghĩa. Không chốt lần lượt từ trên xuống thì không chốt được các mục bên dưới.

Ngay cả khi thuê ngoài dịch vụ hỗ trợ triển khai gói phần mềm, trong sáu mục này không có mục nào có thể nhờ người khác quyết định thay. Bên hỗ trợ chỉ có thể chuẩn bị vật liệu để ra quyết định, trình bày các lựa chọn cùng tác động, và sắp xếp thành tài liệu. Bản thân quyết định vẫn thuộc về bên đặt hàng.

Ngược lại, nếu lấy báo giá khi sáu mục này đã đầy đủ, bạn sẽ đọc được vì sao giá của các nhà cung cấp khác nhau. Chênh lệch sẽ đến từ phạm vi công việc giả định, kinh nghiệm của người được phân công, hoặc cách tính dự phòng rủi ro. Nếu lấy báo giá khi sáu mục còn bỏ ngỏ, mỗi nhà cung cấp sẽ tự gánh phần chưa chốt vào giá, con số vì thế phân tán và việc so sánh không còn thành lập.

Về mặt quy trình triển khai, hãy dành riêng một khoảng thời gian để hoàn tất sáu mục này như một công đoạn trước khi xác định yêu cầu, và ghi rõ nó trong kế hoạch. Nếu để nó thành “phần chuẩn bị” nằm ngoài kế hoạch, trên thực tế nó sẽ bị làm song song sau khi dự án đã khởi động, và món nợ trả chậm nói ở đứt gãy 3 sẽ phát sinh.

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

Tỷ lệ thất bại khi triển khai hệ thống quản lý sản xuất là bao nhiêu?

Không có thống kê chính thức nào được thiết lập riêng cho tỷ lệ thất bại của hệ thống quản lý sản xuất. Có hai chỉ số gần nhất có thể tham chiếu. Một là báo cáo “Khảo sát xu hướng CNTT doanh nghiệp 2026” của JUAS, theo đó mức tuân thủ chất lượng, ngân sách và tiến độ trong phát triển hệ thống nhìn chung đi xuống trong mười năm qua, và ở các dự án từ 500 người-tháng trở lên thì cả ba yếu tố đều có 30 đến 50 phần trăm bị đánh giá tiêu cực. Hai là khảo sát năm 2024 của Gartner do Viện Nghiên cứu Nomura giới thiệu, theo đó hơn 70 phần trăm dự án triển khai và đổi mới gói ERP kết thúc mà không đạt mục tiêu kinh doanh ban đầu. Điều nên đọc ra từ hai nguồn này không phải bản thân con số tỷ lệ thất bại, mà là cấu trúc rằng phân bố của thất bại phụ thuộc vào quy mô. Dự án nhỏ tương đối tốt, càng lớn thì đánh giá tiêu cực càng nhiều. Nghĩa là xác suất thất bại không phải điều kiện cho sẵn, mà là biến số bên đặt hàng có thể dịch chuyển bằng cách chia nhỏ dự án. Ngoài ra, không tồn tại thống kê giới hạn theo khu vực kiểu “ở Thái Lan có bao nhiêu phần trăm thất bại”, nên nếu bắt gặp con số như vậy hãy kiểm tra nguồn gốc.

Triển khai hệ thống quản lý sản xuất mất bao lâu?

Vì phạm vi, số lượng nhà máy, hình thái sản xuất và tình trạng hệ thống hiện hữu có thể làm con số lệch nhau cả một bậc, việc đưa ra một khoảng thời gian chung gần như vô nghĩa. Câu hỏi thực dụng hơn là “một giai đoạn nên cắt ở đâu”. Tại công ty chúng tôi, khi xuất hiện kế hoạch vượt quá 50 người-tháng và 6 tháng cho một giai đoạn, chúng tôi xem xét ngay khả năng chia nhỏ. Đây không phải con số do JUAS đưa ra mà là ngưỡng vận hành, nhưng có ba căn cứ. Thứ nhất, vượt 6 tháng thì các bên liên quan không còn nhớ bối cảnh của những đặc tả chốt lúc đầu, và mọi lấn cấn ở giai đoạn kiểm thử sẽ bị xử lý như thay đổi đặc tả. Thứ hai, trong nửa năm đến một năm sẽ có luân chuyển nhân sự và thay đổi mặt hàng, khiến dự án phải ngắm mãi một mục tiêu di động. Thứ ba, giai đoạn càng lớn thì càng khó ra quyết định dừng giữa chừng. Giá trị bản chất của việc chia nhỏ không phải cắt giảm chi phí mà là có nhiều cơ hội ra quyết định. Rút ngắn một chu kỳ ra quyết định sẽ cho hiệu quả đến sớm hơn là cố rút ngắn tổng thời gian dự án.

Gói phần mềm và phát triển từ đầu, cái nào ít thất bại hơn?

Bản thân câu hỏi này đã nằm ngoài các nguyên nhân thất bại chủ yếu. Trong khảo sát năm tài chính 2025 của JUAS, nguyên nhân số một khiến QCD xấu đi lần lượt là tiến độ do thiếu cân nhắc khi lập kế hoạch, ngân sách do thay đổi đặc tả liên tục, chất lượng do nhà cung cấp thiếu kỹ năng (chiếm 60% doanh nghiệp không hài lòng về chất lượng). Cả ba đều độc lập với lựa chọn phương thức hiện thực hóa. Chọn gói sẵn mà lúc lập kế hoạch không tính công hấp thụ độ vênh nghiệp vụ thì tiến độ vẫn trễ, và bắt tay phát triển khi yêu cầu chưa chốt thì thay đổi đặc tả vẫn nổ ra liên tục. Thứ cần phán đoán không phải chủng loại sản phẩm, mà là ranh giới giữa dồn về chức năng chuẩn hay làm riêng, xét theo từng vùng chức năng. Vùng không gắn với năng lực cạnh tranh và làm giống công ty khác cũng được thì dồn về chuẩn, còn vùng chứa thế mạnh riêng và vùng bị khách hàng hoặc cơ quan quản lý chỉ định mẫu biểu thì làm riêng. Hãy vạch ranh giới đó theo từng vùng chức năng, sau khi đã ghi nghiệp vụ hiện hành thành tài liệu. Nếu chọn tự làm nội bộ, trước hết hãy kiểm tra xem các rào cản nội bộ hóa mà JUAS chỉ ra, tức thiếu số lượng nhân lực phát triển 52.7%, thiếu chất lượng nhân lực phát triển 49.6% và thiếu nhân lực quản lý dự án 44.4%, có đúng với công ty mình hay không.

Được phép tùy chỉnh hệ thống quản lý sản xuất đến đâu?

Đừng quyết định bằng trần chi phí, hãy quyết định bằng việc có gánh nổi chi phí duy trì hay không. Ngoài chi phí ban đầu, tùy chỉnh kéo theo hai loại chi phí duy trì. Một là gánh nặng kiểm chứng lại khi sản phẩm nâng cấp phiên bản, vì những chỗ đã can thiệp vào chức năng chuẩn phải kiểm tra hoạt động mỗi lần cập nhật. Hai là sự phụ thuộc vào cá nhân, vì nếu đặc tả phần chế lại không thành tài liệu thì khi người phụ trách thay đổi, nó trở thành hộp đen không ai dám động. Chỉ những vùng mà bạn có bộ máy gánh được hai chi phí đó mới là vùng được phép tùy chỉnh. Trên thực tế, biểu mẫu và nhãn do khách hàng chỉ định cùng cửa ngõ thu thập số liệu thực hiện vốn phụ thuộc mạnh vào môi trường hiện trường là những chỗ làm riêng dễ sinh giá trị, còn can thiệp vào chính logic tính nhu cầu vật tư nên là biện pháp cuối cùng. Thêm nữa, ngay khi quyết định tùy chỉnh, hãy đưa việc nhận tài liệu đặc tả phần chế lại và danh sách các điểm đã chế lại vào hợp đồng như hạng mục bàn giao. Chức năng làm riêng theo một hợp đồng không cho nhận mã nguồn và tài liệu thiết kế sẽ trở thành tài sản mà vài năm sau không ai đụng vào được.

Hệ thống đã thất bại một lần thì chỉ còn cách làm lại từ đầu?

Trên thực tế, làm lại từ đầu hiếm khi là lựa chọn đầu tiên. Bởi cách xử lý thay đổi tùy theo triệu chứng thất bại đến từ đứt gãy nào. Nếu lý do hiện trường không dùng nằm ở độ chính xác dữ liệu danh mục, thì có thay hệ thống mới cũng cho cùng kết quả chừng nào dữ liệu chưa được sửa. Trường hợp này phải chỉnh trang dữ liệu trước. Nếu lý do số liệu thực hiện không vào được nằm ở thời gian và địa điểm nhập liệu, việc xem lại phương thức nhập (quét mã vạch hoặc lấy tự động từ thiết bị) đôi khi đã giải quyết được. Nếu tình trạng là không giải thích được hiệu quả vì mục đích chưa từng được định nghĩa, bạn vẫn có thể định nghĩa chỉ số đánh giá go-live về sau và bắt đầu từ việc đo. Chỉ khi bản thân nghiệp vụ đã thay đổi đến mức cấu trúc dữ liệu của hệ thống hiện hành không biểu diễn nổi thì mới cần làm lại. Để phán đoán, trước hết hãy phân loại thất bại theo đứt gãy chứ không theo triệu chứng. Sau khi phân loại, không hiếm trường hợp phạm vi cần động tới chỉ là một phần của hệ thống hiện hành. Xác định xem giữ lại được bao nhiêu tài sản hiện có rồi mới cắt phạm vi nhỏ để bắt tay, cách đó chắc chắn hơn là thay mới toàn bộ.

Khi triển khai hệ thống quản lý sản xuất tại nhà máy ở Thái Lan cần đặc biệt lưu ý gì?

Có năm điểm. Thứ nhất là ngôn ngữ của màn hình và thông báo lỗi. Trước màn hình không đọc được, hành vi của người thao tác sẽ là học thuộc vị trí, nên mỗi lần đổi bố cục lại phải đào tạo lại, và khi có ngoại lệ thì không ai phán đoán được. Thứ hai là phạm vi đào tạo. Ở Nhật nhiều khi chỉ cần dạy thao tác là đủ vì bối cảnh quy tắc nghiệp vụ đã được chia sẻ, còn ở cơ sở nước ngoài phải giải thích từ chỗ vì sao cần nhập dữ liệu này và con số này dùng vào việc gì ở công đoạn sau. Thứ ba là tài liệu quy trình. Trên tiền đề nhân sự sẽ thay đổi, hãy chốt trước go-live tài liệu quy trình bằng tiếng bản địa và người chịu trách nhiệm cập nhật nó. Thứ tư là ranh giới giữa chuẩn của trụ sở và tối ưu tại chỗ. Trong thực tế, cách phân chia ít đổ vỡ nhất là hệ thống mã, cấu trúc dữ liệu danh mục và các mục kết nối kế toán theo chuẩn trụ sở, còn phương thức nhập số liệu thực hiện, bố cục biểu mẫu hiện trường và ngôn ngữ thì để bản địa quyết. Thứ năm là bộ máy hỗ trợ trong một tháng đầu sau go-live. Nếu giai đoạn này không có người tại chỗ trả lời được câu hỏi, cách vận hành do hiện trường tự tạo sẽ bám rễ nguyên như vậy. Xin lưu ý đây là những cấu trúc thực tiễn lặp lại tại các nhà máy ở Thái Lan, không phải phát biểu dưới dạng thống kê tỷ lệ thất bại theo khu vực.

Kết luận

Thất bại khi triển khai hệ thống quản lý sản xuất không xảy ra vào ngày go-live, nó đã được quyết định từ 12 đến 18 tháng trước đó. Các triệu chứng quan sát được sau go-live, tức hiện trường không dùng, giấy tờ vẫn còn, Excel quay trở lại, đều là hệ quả của việc các quyết định thượng nguồn đã triệt tiêu lựa chọn ở hạ nguồn. Liệt kê triệu chứng thì không thành biện pháp.

Điều báo cáo “Khảo sát xu hướng CNTT doanh nghiệp 2026” của JUAS chỉ ra là mức tuân thủ chất lượng, ngân sách và tiến độ nhìn chung đi xuống trong mười năm qua, và ở các dự án từ 500 người-tháng trở lên thì cả ba yếu tố đều có 30 đến 50 phần trăm bị đánh giá tiêu cực, trong khi các dự án nhỏ tương đối tốt. Nguyên nhân số một khiến QCD xấu đi lần lượt là tiến độ do thiếu cân nhắc khi lập kế hoạch, ngân sách do thay đổi đặc tả liên tục, chất lượng do nhà cung cấp thiếu kỹ năng (chiếm 60% doanh nghiệp không hài lòng về chất lượng). Cả ba đều độc lập với lựa chọn gói sẵn hay viết mới, và quy về cách chia nhỏ quy mô cùng cách làm phần xác định yêu cầu. Con số hơn 70 phần trăm dự án ERP kết thúc mà không đạt mục tiêu kinh doanh ban đầu, trong khảo sát năm 2024 của Gartner do Viện Nghiên cứu Nomura giới thiệu, cũng cho thấy go-live và thành công là hai chuyện khác nhau.

Năm điểm đứt gãy đặt ra trong bài là mục đích, quy mô, đặc tả, dữ liệu và vận hành. Ở đứt gãy mục đích, hãy đổi tiêu chí đánh giá go-live từ “có chạy không” sang “đã giảm được cái gì”, và viết trọn bộ giá trị hiện tại, giá trị mục tiêu, phương pháp đo và người chịu trách nhiệm đo. Ở đứt gãy quy mô, khi xuất hiện kế hoạch vượt 50 người-tháng và 6 tháng cho một giai đoạn thì hãy nghi ngờ và chia nhỏ, cắt theo quy trình nghiệp vụ, theo nhà máy, theo mặt hàng hoặc theo dữ liệu. Ở đứt gãy đặc tả, hãy để chính bên đặt hàng viết ra nghiệp vụ hiện hành. Việc các rào cản nội bộ hóa của JUAS xếp cạnh nhau gồm thiếu hiểu biết về nghiệp vụ hiện hành 38.2%, thiếu năng lực hoạch định hệ thống 34.5% và không nắm được đặc tả hệ thống hiện hành 25.9% cho thấy đây là công việc không thể thuê ngoài. Ở đứt gãy dữ liệu, hãy đo thực tế độ chính xác của mã hàng, BOM, công đoạn và tồn kho trước khi chuyển đổi, và thiết kế việc nhập số liệu thực hiện như một thao tác nằm trong công đoạn. Ở đứt gãy vận hành, hãy chuẩn bị người tiếp nhận vận hành tại nhà máy, tài liệu quy trình bằng tiếng bản địa, và bộ máy hỗ trợ một tháng đầu sau go-live.

Và trong năm điểm này, thứ bên đặt hàng tự do quyết định được trước khi khởi động chỉ có hai: cách chia nhỏ quy mô, và ai viết đặc tả. Chọn nhà cung cấp là công đoạn đến sau, và nếu lấy báo giá khi hai điểm này còn bỏ ngỏ thì con số sẽ phân tán và việc so sánh không thành lập. Ngược lại, khi hai điểm này đã chốt thì ba điểm còn lại bị thu hẹp lựa chọn rất nhiều. Nói “tránh thất bại” có lẽ chưa thật chính xác. Thứ chúng ta thực sự làm là tạo ra trạng thái còn phán đoán được, trước khi thất bại kịp được quyết định.

Ngay cả khi bạn chưa xác định được nên bắt đầu từ đâu cũng không sao. Nếu được xem luồng nghiệp vụ hiện hành cùng các biểu mẫu và tệp Excel đang thực sự dùng tại hiện trường, chúng tôi có thể chỉ đưa ra các phương án cắt giai đoạn, kèm nhận định phần nào trong năm điểm đứt gãy còn bỏ ngỏ và nên cắt giai đoạn đầu tiên ra sao để giữ được cơ hội ra quyết định. Chúng tôi cũng nhận tư vấn từ tình huống đã từng triển khai không thành công một lần. Xin liên hệ thoải mái qua trang liên hệ.

Nguồn tham khảo

• Báo cáo khảo sát xu hướng công nghệ thông tin doanh nghiệp 2026 (Hiệp hội Người dùng Hệ thống Thông tin Nhật Bản, JUAS, tháng 4 năm 2026)
• Thông cáo báo chí đợt một về “Khảo sát xu hướng công nghệ thông tin doanh nghiệp 2026” (JUAS, năm 2026)
• Hiện thực hóa chuyển đổi quản trị bằng triển khai và đổi mới ERP, đọc ra bí quyết thành công từ ba nguyên nhân thất bại (Viện Nghiên cứu Nomura, tháng 8 năm 2025)
• Cái khó và giải pháp cho dự án triển khai và đổi mới gói ERP (Viện Nghiên cứu Nomura, NRI Management Review số 24, tháng 1 năm 2026)
• JUAS công bố số liệu sơ bộ của “Khảo sát xu hướng công nghệ thông tin doanh nghiệp 2026” (i Magazine, tháng 2 năm 2026)
• Khảo sát xu hướng mở rộng hoạt động của doanh nghiệp Nhật Bản tại Thái Lan, năm tài chính 2024 (JETRO, tháng 2 năm 2025)