Tuần trước mình đọc một bài khá hay trên ERP Today của Sridevi Mutyala bên Oracle, nói về identity governance trong cloud ERP. Bài kể một chuyện tưởng đơn giản, một nhân viên chuyển phòng ban, HR update xong, mấy ứng dụng cloud ERP như Oracle Fusion, SAP S/4HANA, Dynamics 365 đều chạy đúng config, authentication OK, provisioning OK, integration OK, vậy mà quyền truy cập vẫn bị delay, vì approval paths mỗi ứng dụng một kiểu, role definitions không đồng bộ, còn quyết định cấp quyền thì không ai nhớ rõ là của ai. Chuyện ấy quen không? Với mình thì quen lắm.
Giả sử bạn là giám đốc một nhà máy vừa và nhỏ, trên bàn có hai bảng chào giá, một bên bảo Cloud ERP rẻ hơn, triển khai nhanh, bên kia bảo On-premise mới an toàn, dữ liệu xưởng sao mà đưa lên mây được. Tin ai bây giờ? Theo mình câu trả lời chưa bao giờ gói gọn trong một từ.
cloud ERP, cái được và cái mất # Cloud ERP bán chạy vì không cần đầu tư ban đầu lớn, không mua server, không thuê IT, không lo bảo trì, vendor lo hết, và với nhà máy vừa và nhỏ ở Việt Nam thì đây là đường ngắn nhất để có ERP. Có điều theo mình nó có mấy cái bẫy.
Tuần rồi mình đọc được hai case study trên ERP Today mà ngồi nghĩ cả buổi tối, một bài về ngành dược đang chạy SAP S/4HANA migration nhưng mối quan tâm số một lại không phải AI, một bài về Defense Logistics Agency (DLA) của Mỹ, nơi audit readiness mới là động lực chính cho ERP modernization. Một bên thuốc men, một bên vũ khí, khác nhau hoàn toàn, mà chung một câu chuyện là AI không cứu được bạn nếu integration với governance chưa có.
Mới đây ERP Today có bài phân tích khá hay về cuộc đua ERP ngành năng lượng giữa bốn ông lớn SAP, Oracle, IFS và Infor, đọc xong mình thấy có mấy điểm đáng nghĩ, nhất là với anh em đang tư vấn ERP cho nhà máy hay utility ở Việt Nam. Bài này không nhằm so xem ai tốt nhất, vì câu trả lời lúc nào cũng là tùy, mà để thấy mỗi ông có một góc tấn công riêng, và có cái khung đó trong đầu thì lúc chọn ERP mình đặt câu hỏi đúng hơn.
Data migration làm mình đau đầu nhất ở một chỗ nghe rất cơ bản, là không hiểu rõ thứ tự các loại data phải migrate, cái gì đi trước, cái gì đi sau, cái gì phụ thuộc cái gì, đổ sai thứ tự một cái là dữ liệu phía sau không còn chỗ mà bám. Theo mình đó cũng là lý do data migration không phải chuyện code với script, nó là chuyện hiểu dữ liệu, hiểu con người, hiểu quy trình, và hiểu cả những ô Excel tưởng vô hại.
Tuần trước, một anh quản lý sản xuất gọi mình hỏi:
“IFS giờ mua Softeon với 7bridges làm gì thế? Có phải đang cạnh tranh với Blue Yonder với Manhattan Associates không?”
Câu hỏi hay, nhưng theo mình câu trả lời không nằm ở chuyện cạnh tranh WMS với TMS, mà ở chỗ IFS đang xây một lớp vận hành (operations layer) cho nhà máy và tài sản công nghiệp, nơi AI không chỉ phân tích số liệu mà còn ra quyết định dựa trên bối cảnh vật lý thật ngoài xưởng. Bài này mình ngồi gỡ ba thương vụ M&A gần đây của IFS, xem họ đang nhắm tới cái gì, và cái bẫy mà ai làm tư vấn ERP cũng nên biết trước.
Người ta hay hỏi nhau “bên đó chạy ERP gì”, như thể chọn đúng phần mềm là xong một nửa dự án, nhưng càng làm mình càng thấy câu hỏi đó đặt sai chỗ, vì hai nhà máy chạy cùng một hệ thống vẫn có thể một bên trơn tru, một bên ngày nào cũng ngồi đối chiếu Excel. Khác nhau ở dữ liệu.
không phải ERP gì, mà dữ liệu có chạy xuyên không # Giả sử một nhà máy có ERP, có MES, có hệ thống kho, nhưng mỗi hệ thống là một ốc đảo, dữ liệu từ PLM sang ERP phải export Excel, từ ERP sang MES lại import bằng tay, mỗi lần đổi cấu hình sản phẩm là một đợt đối chiếu mệt nghỉ. Theo mình, cảnh này không hiếm ở nhà máy Việt. Ai cũng biết dữ liệu quan trọng, nhưng nối được một mạch từ khâu thiết kế đến khâu vận hành thì không nhiều nơi làm được, và phần mềm có xịn đến đâu mà dữ liệu đi bộ qua tay người thì cũng chỉ nhanh bằng người gõ.
Go-live xong, hệ thống chạy, nhưng người dùng lại work around, có cách né, không làm theo quy trình chuẩn, file Excel vẫn mở sẵn “cho chắc”. Với mình, đó là dấu hiệu rõ nhất một dự án ERP sắp có chuyện.
Vậy cái gì dẫn tới đó? Dưới đây là 5 lý do, có cái mình gặp thật, có cái là quan điểm của mình, và nếu bạn muốn một ví dụ cụ thể thì bài 3 cái bẫy cấu hình IFS Cloud Procurement cũng xuất phát từ những lỗi tương tự.
Mình mở blog này vì một lý do khá ích kỷ, là viết ra thì mới biết mình hiểu đến đâu. Mấy năm đi làm, có những thứ mình cứ tưởng là hiểu rồi, đến lúc ngồi gõ lại thành câu cho người khác đọc mới lòi ra chỗ nào mình còn mơ hồ, nên blog này về cơ bản là cái bàn nháp của mình. Nháp công khai.
mình là ai # Mình là Đức Quân, nghề chính là Business Analyst, chuyên triển khai ERP và quản lý chuỗi cung ứng (SCM) trong các nhà máy sản xuất. Việc hằng ngày xoay quanh IFS Cloud, từ procurement, inventory đến manufacturing, cộng thêm mấy dự án ERP tự viết. Mình có chứng chỉ CBAP của IIBA, nhưng thứ giúp mình làm được việc không phải mấy chữ cái đó, mà là những buổi chiều đứng dưới xưởng nghe quản đốc chửi hệ thống.
Giả sử module IFS Cloud Procurement đã go-live rồi mà team mua hàng vẫn ngập trong Excel và việc tay, theo mình chuyện này nằm gọn trong 5 lý do khiến dự án ERP thất bại, và root cause thường không nằm ở phần mềm mà ở cách người ta set-up nó từ lúc triển khai. Dưới đây là 3 cái bẫy mình thấy lặp đi lặp lại.
approval route một cỡ cho tất cả # Luồng duyệt mặc định của IFS Cloud là phẳng, mọi requisition chạy chung một chain bất kể giá trị, chủng loại hay phòng ban, và nhiều team cứ để vậy với ý nghĩ “sau này refine”. Kết quả là cái request mua giấy vài chục nghìn và cái đơn thiết bị bạc tỷ xếp chung một hàng chờ, ông approver nghỉ phép vài hôm là dây chuyền đứng.
