Triển khai ERP Clean Core cho nhà máy tại Thái Lan

Chìa khóa để triển khai ERP Clean Core thành công không phải là cấm mọi tùy chỉnh. Những quy trình không tạo khác biệt nên được đưa về chuẩn; những yêu cầu tạo lợi thế cạnh tranh nên được mở rộng bên ngoài ranh giới lõi theo cách vẫn có thể nâng cấp; còn ngoại lệ phải có người chịu trách nhiệm, thời hạn và điều kiện loại bỏ. Bài viết này cung cấp tiêu chí thực hành xuyên suốt từ RFP, Fit-to-standard, đánh giá 90 ngày đến nghiệm thu cho các nhà máy tại Thái Lan và ASEAN.

ERP Clean Core không có nghĩa là “không thay đổi”, mà là quản trị thay đổi

Clean Core không phải khẩu hiệu biến lõi ERP thành “vùng cấm” và từ chối mọi yêu cầu của nhà máy. Đây là kỷ luật thiết kế và vận hành nhằm duy trì khả năng theo kịp các bản phát hành chuẩn của ERP, đồng thời vẫn triển khai được những khác biệt kinh doanh thực sự cần thiết. Tài liệu chính thức của SAP nhìn Clean Core từ năm phương diện: quy trình nghiệp vụ, khả năng mở rộng, dữ liệu, tích hợp và vận hành. Vì vậy, chỉ giảm số lượng add-on là chưa đủ. Nếu vẫn còn dữ liệu chủ trùng lặp, giao diện không được giám sát và vận hành phụ thuộc vào một cá nhân, hệ thống chưa thể được coi là “clean”.

Tại một nhà máy ở Thái Lan, mẫu quy trình của tập đoàn, yêu cầu thuế địa phương, nhãn riêng của khách hàng, cách vận hành kho tại chỗ, kết nối thiết bị và luồng phê duyệt song ngữ Nhật–Thái thường cùng tồn tại. Ép toàn bộ về chuẩn có thể khiến hiện trường không vận hành được; đưa toàn bộ yêu cầu hiện trường vào lõi lại khiến lần nâng cấp tiếp theo bị đình trệ. Điều cần thiết là tách yêu cầu thành các đơn vị có thể thảo luận, rồi quyết định đặt ở đâu, ai phê duyệt và khi nào phải xem xét lại.

Trọng tâm quyết định không chỉ là “chuẩn hay riêng”. Trước hết cần xác nhận quy trình đó có thực sự cần cho giá trị khách hàng hoặc tuân thủ pháp luật hay không. Sau đó mới xét liệu có thể đáp ứng bằng cấu hình chuẩn, cần phần mở rộng nhẹ chạy trong ERP, hay nên tách thành ứng dụng bên ngoài. Chỉ những yêu cầu chưa thể quyết định mới được đưa vào ngoại lệ có thời hạn. Trình tự này giúp kiểm soát nợ kỹ thuật mà không xóa bỏ tiếng nói của hiện trường.

Chuyển năm nguyên tắc SAP Clean Core thành câu hỏi kiểm tra tại nhà máy

Năm phương diện do SAP nêu ra chỉ phát huy tác dụng khi được chuyển từ thuật ngữ sản phẩm thành bằng chứng tại nhà máy. Đơn vị đánh giá không phải là “đã giải thích”, mà là có lưu lại danh mục, người chịu trách nhiệm và kết quả kiểm thử hay không.

Về quy trình nghiệp vụ, không nên biến thao tác hiện tại thành yêu cầu bất biến. “Muốn tiếp tục nhập cùng dữ liệu ba lần” chỉ là mô tả hiện trạng. Yêu cầu thực sự nên được diễn đạt bằng kết quả và ràng buộc, chẳng hạn: “người phụ trách giải phóng lô phải kiểm tra được lịch sử phê duyệt trong vòng 10 phút”. Khi đó, workflow chuẩn hoặc ứng dụng phê duyệt bên ngoài cũng có thể đáp ứng.

Về dữ liệu, cần xác định nguồn chuẩn cho mã hàng, BOM, thiết bị, đối tác, lô và đơn vị tính. Về tích hợp, thay vì tăng kết nối điểm-điểm, cần quy định khi nào dùng API chuẩn, sự kiện hoặc tệp, cùng cơ chế giám sát tương ứng. Về vận hành, phải xác định ai kiểm thử lại nội dung nào sau mỗi bản cập nhật quý hoặc nâng phiên bản. Đưa cả năm phương diện vào cùng một hội đồng xét duyệt sẽ tránh tình trạng phần phát triển có vẻ “clean” nhưng vận hành vẫn phụ thuộc cá nhân.

Workshop Fit to Standard không phải buổi tái tạo màn hình cũ

Trong Fit-to-standard, trước tiên cần trình diễn kịch bản chuẩn trên hệ thống hoặc bằng một quy trình cụ thể. Người tham gia không chỉ nêu “khác với hiện tại ở đâu”, mà còn phải kiểm chứng “khác biệt đó có làm tổn hại kết quả kinh doanh hay không”. Nếu bắt đầu bằng cách hỏi cột nào phải có trong báo cáo cũ hoặc thứ tự màn hình hiện tại, dự án rất dễ trở thành việc xây lại hệ thống cũ. Trình tự nên là: demo chuẩn, kết quả nghiệp vụ, yêu cầu kiểm soát, rồi mới đến chênh lệch.

Thành phần phù hợp gồm chủ quy trình, key user tại hiện trường, đại diện chất lượng, tài chính, IT, tích hợp và đối tác triển khai. Chỉ có nhân sự nhà máy thì khó quyết định chuẩn toàn doanh nghiệp; chỉ có trụ sở chính lại dễ đánh giá sai tính khả thi. Mỗi chênh lệch nên được chuyển ngay trong cuộc họp sang một trong bốn trạng thái: chấp nhận, cần thêm bằng chứng, từ chối hoặc tạm giữ có thời hạn; không để yêu cầu bị chôn trong biên bản.

Tư tưởng Solution Standardization Board trong tài liệu của SAP quan trọng ở thiết kế quyền hạn hơn là tên gọi. Hội đồng không chỉ đóng dấu phê duyệt, mà phải quyết định khả năng tái sử dụng giữa các nhà máy, hướng quay về chuẩn và thời hạn xử lý nợ kỹ thuật. Nên thể hiện vai trò của người đề xuất, chủ nghiệp vụ, kiến trúc sư, an ninh và tài chính bằng RACI, đồng thời ghi rõ lý do từ chối và điều kiện nộp lại.

Phân loại yêu cầu thành STANDARD, IN-APP, SIDE-BY-SIDE và EXCEPTION

Đặt toàn bộ yêu cầu vào bốn nhóm sau sẽ giúp thảo luận về chuẩn hóa ERP trở nên cụ thể. Tên gọi có thể khác đôi chút theo từng sản phẩm, nhưng nguyên tắc quyết định vẫn giống nhau.

STANDARD: thực hiện bằng cấu hình và thay đổi quy trình

Kế toán, mua hàng, dịch chuyển tồn kho và ghi nhận sản xuất cơ bản không tạo khác biệt nên mặc định xem xét theo chuẩn. Việc theo chuẩn có thể giảm phạm vi kiểm thử cho các bản cập nhật tương lai và giảm tài liệu hướng dẫn riêng. Tuy nhiên, “chuẩn” không mặc nhiên đồng nghĩa với “đúng”. Phải xác nhận trong nghiệm thu rằng giải pháp đáp ứng phân tách nhiệm vụ, chứng từ thuế Thái Lan, hợp đồng khách hàng và phê duyệt chất lượng.

IN-APP: phần mở rộng nhẹ cần chạy trong ERP

Nhóm này gồm bổ sung trường, điều chỉnh màn hình, logic được cho phép và hỗ trợ biểu mẫu — những chức năng phải chạy sát giao dịch và có thể dùng extension point công khai của sản phẩm. Đội kỹ thuật cần lưu lại API, điểm mở rộng và khả năng tương thích khi nâng cấp. Không chọn IN-APP chỉ vì “làm trong ERP thì tiện hơn”.

SIDE-BY-SIDE: đặt phần khác biệt ra ngoài lõi

Lập kế hoạch nâng cao, cổng khách hàng, trợ lý AI, xử lý dữ liệu thiết bị và phê duyệt phức tạp có thể được xây như ứng dụng bên ngoài, kết nối ERP qua API công khai hoặc sự kiện. SAP khuyến nghị side-by-side trên BTP cho phần mở rộng phức tạp; tuy nhiên, từng dự án vẫn phải so sánh ERP đích, nền tảng cloud hiện có, an ninh và năng lực vận hành. Đưa chức năng ra ngoài không tự động làm nó an toàn. Vẫn cần hợp đồng API, quyền sở hữu dữ liệu, mức sẵn sàng và quy trình khi xảy ra sự cố.

EXCEPTION: giữ tạm thời, có hạn và điều kiện loại bỏ

Nhóm ngoại lệ dành cho yêu cầu chưa thể xử lý ngay, chẳng hạn đang chờ giải thích pháp lý, chờ chức năng chuẩn, phục vụ hợp đồng khách hàng ngắn hạn hoặc giai đoạn chuyển đổi. Mỗi ngoại lệ bắt buộc có chủ nghiệp vụ, chủ kỹ thuật, lý do được chấp thuận, mức ảnh hưởng, ngày hết hạn, ngày đánh giá lại, điều kiện loại bỏ và phương án thay thế. Không tự động gia hạn khi quá hạn; phải đưa trở lại hội đồng xét duyệt.

Giảm ERP add-on: ưu tiên theo rủi ro và mức sử dụng, không chỉ đếm số lượng

Con số “giảm từ 100 xuống 50 add-on” không đủ để đánh giá giá trị kinh doanh. Ba mươi báo cáo không còn ai dùng và một logic liên kết chặt có thể làm dừng xử lý đơn hàng có mức rủi ro hoàn toàn khác nhau. Khi kiểm kê, cần đánh giá tần suất sử dụng, mức quan trọng với nghiệp vụ, độ gắn chặt vào lõi, khả năng thay thế bằng chuẩn, công sức kiểm thử, lịch sử sự cố và độ nhạy cảm của dữ liệu.

Trước tiên phải thu thập log sử dụng thực tế. Nếu chỉ hỏi người dùng, câu trả lời “cứ giữ lại phòng khi cần” sẽ ngày càng nhiều. Hãy kiểm tra số lần gọi, người dùng, ngày sử dụng cuối và đối tượng xử lý. Sau đó mới xác định ứng viên có thể thay thế bằng chuẩn, chức năng trùng mục đích hoặc yêu cầu pháp lý đã hết hiệu lực. Loại bỏ không chỉ là nhấn nút xóa; còn bao gồm đổi SOP, đào tạo, thu hồi quyền, lưu trữ và duy trì dấu vết kiểm toán.

Có thể sắp ưu tiên theo công thức nội bộ như “độ gắn lõi × tần suất thay đổi × ảnh hưởng nghiệp vụ”. Điểm số chỉ dùng để so sánh trong doanh nghiệp, không phải chuẩn thị trường. Hạng mục rủi ro cao nhưng có chức năng chuẩn thay thế nên được giảm trước; hạng mục rủi ro cao nhưng tạo khác biệt cần thiết nên được đánh giá để chuyển sang SIDE-BY-SIDE.

Hoạt động kiểm kê này nên được thực hiện không chỉ khi thay ERP, mà còn mỗi sáu tháng, trước bản phát hành lớn, khi M&A hoặc mở nhà máy mới. Tách ngân sách duy trì add-on không còn dùng khỏi ngân sách di chuyển add-on đang dùng nhưng nguy hiểm sẽ giúp ban lãnh đạo ra quyết định rõ hơn.

Ranh giới cho phép và điều cấm với mở rộng ERP side-by-side

Side-by-side là phương thức hiệu quả để bảo vệ ERP đồng thời tăng tốc khác biệt hóa. Nhưng nếu ranh giới không rõ, cụm ứng dụng bên ngoài có thể trở thành một hệ thống legacy mới. Ngay từ thiết kế cần phân biệt dữ liệu chuẩn nằm trong ERP, dữ liệu chuẩn nằm trong ứng dụng ngoài, cache tạm thời và bản sao phân tích; hạn chế tối đa cập nhật hai chiều.

Các trường hợp phù hợp thường gồm tiền xử lý dữ liệu thiết bị, giao diện hiện trường, cổng khách hàng hoặc nhà cung cấp, đề xuất bằng AI, lập lịch phức tạp và ứng dụng cần chu kỳ cải tiến ngắn. Ngược lại, không nên vô cớ sao chép ra ngoài các xử lý không thể tách khỏi giao dịch ERP như tính toàn vẹn bút toán hay định giá tồn kho. Tiêu chí nghiệm thu cũng phải bao gồm: nhà máy có tiếp tục vận hành khi mất kết nối không và sau khôi phục có ngăn được ghi nhận hai lần không.

RFP cho phần mở rộng cần quy định việc chỉ dùng API công khai, xác thực và phân quyền, audit log, tính idempotent, gửi lại, timeout, quản lý phiên bản, giám sát, trách nhiệm sự cố, xóa dữ liệu và chuyển giao khi kết thúc hợp đồng. Có thể đưa các điều khoản kết nối trong bài phát triển tích hợp API cho sản xuất vào tiêu chí xét duyệt Clean Core.

Bảo vệ ERP CORE bằng quản trị giao diện tích hợp

Với Clean Core, không chỉ bản thân ERP mà mọi kết nối cũng thuộc phạm vi quản trị. Nhà máy thường có MES, WMS, gateway thiết bị, hệ thống nhãn, chất lượng, EDI, ngân hàng, thuế và BI; cùng một dữ liệu có thể đi qua nhiều tuyến. Danh mục giao diện phải ghi nguồn, đích, chủ sở hữu dữ liệu, phương thức, tần suất, độ trễ tối đa, gửi lại, chống trùng, giám sát, dữ liệu cá nhân và quy trình khi kết nối dừng.

Tài liệu Clean Core Integration của SAP Help đưa ra cách phân loại kỹ thuật cho giao diện, từ đó trực quan hóa mức tuân thủ, phạm vi giám sát và ứng viên cần cải thiện. Trong thực tế, không nên dừng ở nhãn “đây là API”, mà cần phân biệt công khai hay không công khai, đồng bộ hay bất đồng bộ, được quản lý hay tự phát, có giám sát hay không. Nếu vẫn còn truy cập DB trực tiếp hoặc trao đổi qua thư mục dùng chung, không nhất thiết cấm ngay lập tức; hãy đưa vào ngoại lệ có đánh giá ảnh hưởng và hạn chuyển đổi.

Giám sát không chỉ là server còn chạy, mà còn phải kiểm tra tính đầy đủ nghiệp vụ như số đơn hàng, số lần xuất kho và thời gian tồn đọng lỗi. Màn hình hạ tầng có thể xanh nhưng nhà máy vẫn gặp vấn đề nếu một phần thông điệp bị thiếu. Trong họp vận hành, ngoài số sự cố, cần theo dõi số ngày còn lại của giao diện ngoại lệ, số kết nối chưa giám sát và kế hoạch loại bỏ API không công khai.

So sánh TCO 5 năm phải tách chi phí ban đầu, hồi quy, bảo trì và nâng cấp

Trong triển khai ERP Clean Core, việc tách ứng dụng và tự động hóa kiểm thử có thể khiến chi phí ban đầu trông cao hơn. Vì vậy, nên so sánh riêng chi phí ban đầu, hồi quy và bảo trì hằng năm, cùng chi phí nâng cấp. Phần dưới đây chỉ là giả định để hỗ trợ đối thoại lập kế hoạch, không phải giá thị trường, số liệu trung bình đã thực hiện hay cam kết báo giá.

Giả định áp dụng cho một nhà máy tại Thái Lan, 120 người dùng và thời gian năm năm.

Công thức của A là 4.80 + (1.20 × 5) + 2.40 = 13.20M THB; của B là 5.40 + (0.65 × 5) + 0.80 = 9.45M THB. Chênh lệch là 13.20 − 9.45 = 3.75M THB, tương đương 3.75 ÷ 13.20 × 100 = 28.4% so với A, làm tròn một chữ số thập phân. Dù chi phí ban đầu của B cao hơn 0.60M THB, tổng chi phí năm năm thấp hơn theo bộ giả định này.

Không được quảng bá 28.4% như tỷ lệ tiết kiệm phổ biến. Kết quả thực tế phụ thuộc vào add-on hiện tại, chất lượng dữ liệu, giấy phép, hợp đồng cloud, số nhà máy, thời gian dừng cho phép, năng lực nội bộ và số tích hợp. Trong RFP, hãy yêu cầu các nhà cung cấp trả lời theo cùng một bảng chi phí cho triển khai ban đầu, vận hành năm năm, nâng cấp, loại bỏ và chuyển đổi; đồng thời làm rõ phạm vi bao gồm.

Ngoài ra nên lập bảng riêng cho những rủi ro khó quy đổi thành tiền: trì hoãn nâng cấp, chậm bản vá bảo mật, phụ thuộc cá nhân, kiểm toán, thời gian ngừng và lead time thay đổi. Tách giả định và bằng chứng sẽ giúp hội đồng quản trị kiểm chứng tốt hơn là gom tiền và rủi ro vào một chỉ số “ROI” duy nhất.

Đánh giá 90 ngày: đo hiện trạng và tạo lộ trình có thể đồng thuận

Đánh giá 90 ngày không phải dự án thiết kế hoàn chỉnh mọi thứ. Mục tiêu là giảm độ mờ của hiện trạng và thống nhất phạm vi, ưu tiên, giả định chi phí cùng phương thức nghiệm thu cần thiết cho quyết định đầu tư. Có thể triển khai theo bốn giai đoạn DISCOVER, DECIDE, BUILD và VERIFY.

Ngày 1–20: DISCOVER

Thu thập add-on, giao diện, job, báo cáo, dữ liệu chủ, quyền truy cập, sự cố và lịch sử thay đổi. Đi khảo sát nhà máy để kiểm tra trực tiếp terminal, giấy tờ, Excel, nhãn và kết nối thiết bị. Nếu không lấy được log sử dụng, phải ghi nhận chính sự không chắc chắn đó. Phỏng vấn lãnh đạo về mục tiêu kinh doanh, hiện trường về điều kiện buộc phải dừng và IT về ràng buộc nâng cấp.

Ngày 21–45: DECIDE

Thực hiện Fit-to-standard cho các quy trình chính và phân chênh lệch vào bốn nhóm. Xác định add-on và giao diện rủi ro cao, sau đó quyết định nguyên tắc và ngoại lệ trong hội đồng chuẩn hóa. Chưa cần viết đặc tả chi tiết cho toàn bộ yêu cầu, nhưng phải xác định chủ sở hữu và thời hạn của ngoại lệ.

Ngày 46–70: BUILD

Dùng các kịch bản đại diện để kiểm chứng quy mô nhỏ khả năng thực hiện bằng cấu hình chuẩn, IN-APP, SIDE-BY-SIDE và giám sát. PoC không chỉ trình diễn màn hình đẹp; phải bao gồm lỗi, mất kết nối, gửi lại, phân quyền và audit log. Đồng thời chuẩn bị mẫu trả lời RFP và bảng giá chuẩn hóa.

Ngày 71–90: VERIFY

Ban lãnh đạo và nhà máy cùng rà soát lộ trình, giả định TCO, các wave chuyển đổi, tiêu chí nghiệm thu, cơ cấu và rủi ro. Không che giấu điểm chưa rõ; phải gắn người phụ trách và hạn điều tra thêm. Kết quả cuối cùng không nhất thiết là “mua sản phẩm”, mà là bộ tài liệu đủ để quyết định tiếp tục, thu hẹp phạm vi, triển khai từng giai đoạn hay tạm dừng.

Kết hợp với bài thời gian triển khai hệ thống quản lý sản xuất sẽ giúp phân biệt rõ 90 ngày đánh giá với thời gian triển khai chính thức. Chỉ chuyển sang chọn sản phẩm sau khi đáp ứng điều kiện Exit của giai đoạn đánh giá sẽ giảm rủi ro so sánh báo giá dựa trên yêu cầu còn mơ hồ.

Những câu hỏi về chuẩn hóa ERP và Clean Core cần đưa vào RFP

Trong RFP, nên tránh câu hỏi Yes/No như “Có hỗ trợ Clean Core không?”. Cần yêu cầu nhà thầu trả lời phương thức, ràng buộc, bằng chứng, trách nhiệm và chi phí theo cùng một định dạng.

1. Phân loại quy trình chuẩn và yêu cầu Delta bằng quy trình nào, ai phê duyệt?
2. Có trình bày được tiêu chí chọn STANDARD, IN-APP, SIDE-BY-SIDE và EXCEPTION không?
3. Có liệt kê API công khai, điểm mở rộng, chức năng sắp ngừng hỗ trợ và khả năng tương thích cập nhật không?
4. Thiết kế nguồn dữ liệu chuẩn, đồng bộ, gửi lại, chống trùng và audit log như thế nào?
5. Ước tính phạm vi, công sức và trách nhiệm kiểm thử hồi quy cho cập nhật quý/năm ra sao?
6. Dùng dữ liệu nào để xác nhận mức sử dụng add-on hiện tại và nghiệm thu việc loại bỏ như thế nào?
7. Gắn chủ sở hữu, thời hạn và điều kiện loại bỏ cho ngoại lệ, đánh giá trong cuộc họp nào?
8. Khi kết thúc hợp đồng, chuyển giao mã nguồn, cấu hình, log, dữ liệu và tri thức vận hành như thế nào?

Câu trả lời không nên chỉ là “theo chuẩn”, mà phải có màn hình, cấu hình, đặc tả API, test case, màn hình giám sát và ranh giới trách nhiệm. Hãy tách phí license, triển khai, cloud bên ngoài, nền tảng tích hợp, giám sát, bảo trì năm năm, kiểm thử nâng cấp và hỗ trợ loại bỏ; đồng thời ghi số người dùng và khối lượng giao dịch giả định.

Đánh giá đề xuất không chỉ dựa vào điểm giá, mà còn vào mức phù hợp chuẩn, độ an toàn của phần mở rộng, khả năng vận hành, chuyển đổi, bằng chứng nghiệm thu và hỗ trợ tại Thái Lan. Demo sản phẩm nên dùng kịch bản của chính doanh nghiệp, xử lý ngoại lệ, khôi phục lỗi và kiểm soát quyền. Case study là thông tin tham khảo, không phải bằng chứng bảo đảm cùng thời gian hay hiệu quả.

Chứng minh “đã chuẩn hóa” bằng FAT, SAT và bằng chứng nghiệm thu

Clean Core không hoàn tất trên tài liệu thiết kế. FAT cần kiểm tra cấu hình, phần mở rộng, API và xử lý ngoại lệ trong môi trường được quản lý. SAT/UAT cần chạy nghiệp vụ trong điều kiện gần thực tế với mạng nhà máy, thiết bị đầu cuối, nhãn, hệ thống xung quanh, quyền truy cập và dữ liệu gần với sản xuất.

Tiêu chí nghiệm thu phải bao gồm không chỉ luồng bình thường mà cả mất kết nối, timeout, thông điệp trùng, dừng thiết bị, dữ liệu chủ sai, thiếu quyền, người phê duyệt vắng mặt và đối soát sau khi khởi động lại. Mỗi test cần có điều kiện trước, dữ liệu đầu vào, kết quả mong đợi, kết quả thực tế, bằng chứng, người phán định và ID lỗi. Với STANDARD, phải chứng minh cấu hình và kết quả nghiệp vụ; IN-APP chứng minh điểm mở rộng cho phép và hồi quy; SIDE-BY-SIDE chứng minh hợp đồng API và khôi phục; EXCEPTION chứng minh thời hạn và phương án thay thế.

Sau Go-Live, cần tiếp tục thu thập bằng chứng trong giai đoạn ổn định để ngoại lệ không biến thành cách vận hành vĩnh viễn mới. Kết nối với cơ chế quản lý 30 ngày trong bài ERP Hypercare sau Go-Live để theo dõi sự cố, workaround, biện pháp lâu dài và việc quay về chuẩn trên cùng một backlog.

Chương trình depa tại Thái Lan và yêu cầu địa phương cần kiểm tra

Theo trang Tax 200% của depa Thailand Digital Catalog, doanh nghiệp SME thuộc đối tượng được nêu có vốn đã góp không quá 5 triệu THB và doanh thu năm không quá 30 triệu THB; khoản mua hoặc thuê sản phẩm, dịch vụ số đã đăng ký có thể thuộc phạm vi chương trình; mức khấu trừ đặc biệt tối đa được nêu là 300.000 THB; thời gian áp dụng được công bố từ ngày 24/06/2025 đến 31/12/2027. Đây là bản tóm tắt thông tin trên trang của chương trình, không bảo đảm doanh nghiệp cụ thể đủ điều kiện. Phạm vi chi phí, chứng từ, giao dịch liên quan và phương thức kê khai cần được xác nhận với chuyên gia thuế/kế toán và thông tin mới nhất từ depa.

depa là chương trình của Thái Lan và không trực tiếp áp dụng cho doanh nghiệp hoặc nhà máy tại Việt Nam. Nhà máy ở Việt Nam không nên coi các ngưỡng vốn, doanh thu, mức 300.000 THB hay thời hạn nêu trên là ưu đãi tại Việt Nam. Nếu dự án bao gồm cả pháp nhân Thái Lan và Việt Nam, cần tách chủ thể ký hợp đồng, nơi phát sinh chi phí và quy định thuế của từng nước, đồng thời tham vấn chuyên gia tại địa phương trước khi đưa ưu đãi vào business case.

Với dự án Clean Core tại Thái Lan, không nên chọn sản phẩm chỉ vì có ưu đãi hay cơ chế thuế. Cần kiểm tra dịch vụ có nằm trong danh mục đăng ký không, chủ thể hợp đồng có phải pháp nhân Thái Lan không, thời điểm chi tiêu có nằm trong kỳ áp dụng không và chi phí chuẩn bị hồ sơ có hợp lý so với trần khấu trừ không. Dù ưu đãi làm giảm chi phí ban đầu, dự án vẫn đi sai mục tiêu nếu tổng chi phí vận hành, tích hợp và nâng cấp năm năm tăng lên.

Các yêu cầu đặc thù Thái Lan như chứng từ thuế, dữ liệu cá nhân, hiển thị tiếng Thái, mạng tại nhà máy, lịch nghỉ địa phương, xuất nhập khẩu và vận hành liên quan BOI cần được nhận diện sớm. Tuy nhiên, không nên xếp yêu cầu pháp luật và cách làm “từ trước đến nay vẫn vậy” cùng một mức ưu tiên; phải xác nhận căn cứ và người chịu trách nhiệm. Chênh lệch với mẫu quy trình của tập đoàn không nên bị để mặc trong EXCEPTION, mà phải quyết định xử lý bằng cấu hình chuẩn, chức năng bản địa hóa hay dịch vụ bên ngoài.

Bài học từ case study công khai và những điều không được khái quát hóa

Trong case Colombina do SAP công bố tháng 9/2026, doanh nghiệp có 7 nhà máy và 39 trung tâm logistics đã chuyển đổi đồng thời tại 16 quốc gia, tích hợp ERP với các hệ thống xung quanh. Case Damen Shipyards nêu việc hợp nhất 80% nghiệp vụ trên một nền tảng SAP và áp dụng nguyên tắc “Reuse before Buy before Build”. Case Evatec mô tả việc triển khai Cloud ERP Public Edition trong 10 tháng, sau đó có sáu tháng Hypercare.

Đây là các trường hợp riêng lẻ do nhà cung cấp công bố. Không thể dùng 16 quốc gia, 80%, 10 tháng hay sáu tháng làm chuẩn hoặc mức trung bình cho nhà máy tại Thái Lan, Việt Nam hay ASEAN. Điều nên học không phải bản thân con số, mà là cách áp dụng một nguyên tắc chung cho nhiều cơ sở, xác định thứ tự tái sử dụng–mua–xây và đưa giai đoạn ổn định sau Go-Live vào kế hoạch. Doanh nghiệp cần ước tính dựa trên danh mục hiện trạng, điều kiện dừng, chất lượng dữ liệu, số người dùng và số tích hợp của mình.

KPI sau triển khai và cách vận hành hội đồng chuẩn hóa

Nếu chỉ dùng tỷ lệ chuẩn hóa làm KPI, tổ chức có thể vô tình cắt cả khác biệt cần thiết. Bộ KPI nên kết hợp kết quả, khả năng nâng cấp, ngoại lệ và chất lượng vận hành.

Hội đồng chuẩn hóa có thể họp hàng tháng hoặc theo từng bản phát hành để xử lý yêu cầu mới, ngoại lệ đến hạn, API sắp ngừng hỗ trợ, ảnh hưởng cập nhật và cải tiến sau sự cố. Tài liệu họp nên đặt vấn đề cần quyết định lên đầu, giảm mục chỉ để chia sẻ thông tin. Mỗi quyết định cần lưu lý do, phương án, ảnh hưởng, chủ sở hữu và hạn để sáu tháng sau vẫn có thể truy lại.

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

Triển khai ERP Clean Core là gì?

Đó là phương thức triển khai tránh sửa lõi ERP một cách thiếu kiểm soát và liên tục quản trị quy trình, phần mở rộng, dữ liệu, tích hợp cùng vận hành. Chức năng chuẩn được ưu tiên; khác biệt cần thiết được đặt vào phương thức mở rộng công khai hoặc side-by-side; ngoại lệ phải có chủ sở hữu, thời hạn và điều kiện loại bỏ.

SAP Clean Core có cấm tùy chỉnh không?

Không cấm tuyệt đối. Một yêu cầu chính đáng mà chuẩn không đáp ứng có thể được triển khai theo cách vẫn bảo đảm khả năng nâng cấp và trách nhiệm vận hành. Nếu phải chạy trong ERP, hãy xem xét IN-APP/on-stack được cho phép; nếu phức tạp và cần triển khai độc lập, hãy cân nhắc side-by-side, đồng thời lưu lại lý do và bằng chứng.

Fit to Standard có bỏ qua yêu cầu của hiện trường không?

Điều này phụ thuộc vào cách tổ chức. Cần tách yêu cầu tái tạo nguyên trạng màn hình cũ khỏi kết quả bắt buộc do pháp luật, khách hàng, chất lượng hoặc lợi thế cạnh tranh. Khi căn cứ, tần suất, ảnh hưởng và phương án thay thế của Delta được hội đồng chuẩn hóa đánh giá minh bạch, yêu cầu hiện trường sẽ được ưu tiên hợp lý thay vì bị bỏ qua.

Nên bắt đầu giảm ERP add-on từ đâu?

Hãy kiểm kê log sử dụng thực tế, mức quan trọng nghiệp vụ, độ gắn lõi, chức năng chuẩn thay thế, công sức hồi quy và lịch sử sự cố. Loại bỏ hạng mục không dùng hoặc trùng lặp; chuyển hạng mục cần thiết nhưng nguy hiểm sang ứng viên dùng extension công khai hoặc side-by-side. Hoàn tất cả SOP, đào tạo, quyền và dấu vết kiểm toán, không chỉ xóa mã.

Cần lưu ý gì khi mở rộng ERP theo side-by-side?

Phải định nghĩa nguồn dữ liệu chuẩn, hợp đồng API, xác thực, idempotency, gửi lại, giám sát, SLA, trách nhiệm sự cố và chuyển giao khi kết thúc hợp đồng. Đưa chức năng ra ngoài không tự động làm nó “clean”. Hạn chế cập nhật hai chiều giữa ERP và ứng dụng ngoài, đồng thời nghiệm thu cả mất kết nối và khôi phục.

So sánh hiệu quả chi phí Clean Core như thế nào?

Không chỉ so sánh chi phí ban đầu, mà phải đưa bảo trì và hồi quy hằng năm, nâng cấp, nền tảng tích hợp, giám sát, loại bỏ và đào tạo vào cùng một kỳ. Con số 13.20M THB so với 9.45M THB trong bài chỉ là giả định để thảo luận kế hoạch, không phải trung bình thị trường. Cần ước tính lại theo số cơ sở, người dùng, tích hợp, add-on và điều kiện dừng của doanh nghiệp.

Kết luận: không để ngoại lệ tồn tại vô thời hạn và không có người chịu trách nhiệm

Mục tiêu của triển khai ERP Clean Core không phải là thi đua tỷ lệ chuẩn hóa. Điều cốt lõi là đưa nghiệp vụ không tạo khác biệt về chuẩn, đặt khác biệt cần thiết trong một ranh giới có thể nâng cấp và quản lý ngoại lệ bằng chủ sở hữu, thời hạn cùng điều kiện loại bỏ. Khi năm nguyên tắc, Fit-to-standard, bốn nhóm, danh mục giao diện, FAT/SAT và KPI vận hành được nối vào cùng một hệ thống quyết định, nhà máy sẽ dễ cân bằng giữa vận hành hiện trường hôm nay và khả năng cập nhật trong tương lai.

Ngay cả khi mới ở giai đoạn kiểm kê phần mở rộng trước khi chọn sản phẩm, chuẩn bị workshop Fit-to-standard hoặc xây RFP và tiêu chí nghiệm thu, doanh nghiệp vẫn có thể trao đổi với chúng tôi. Nếu cần bắt đầu từ danh mục hiện trạng của nhà máy tại Thái Lan hoặc ASEAN và cùng xác định phần nên theo chuẩn, phần khác biệt cần giữ lại, vui lòng liên hệ TOMAS TECH.

Tài liệu tham khảo

1. SAP Help: Clean Core Extensibility for SAP Cloud ERP
2. SAP Help: Clean Core Integration
3. SAP: Clean Core Business Processes for SAP S/4HANA Cloud
4. SAP News: Colombina—faster delivery, stronger security, AI readiness (18/09/2026)
5. SAP News: Damen Shipyards (14/09/2026)
6. SAP News: Evatec Cloud ERP implementation (16/09/2026)
7. depa Thailand Digital Catalog: Tax 200%

*Bài viết dựa trên thông tin công khai tính đến ngày 20/09/2026. Điều kiện pháp lý, thuế, thông số sản phẩm và khả năng áp dụng chương trình cần được xác nhận theo thông tin chính thức mới nhất và ý kiến chuyên gia. Các số liệu case study và phép tính TCO không phải mức trung bình thị trường hay cam kết kết quả.*