Bạn có thể cứu ERP bị lỗi - hoặc bắt đầu lại không?
- Câu trả lời ngắn gọn:* Một số ERP thất bại đáng được giải cứu — kiến trúc ổn nhưng giao diện, quy trình làm việc hoặc dữ liệu sai. Những người khác có những vấn đề về thiết kế cơ bản khiến cho việc giải cứu trở nên tốn kém hơn so với việc thay thế có chọn lọc. Kiểm toán có cấu trúc sẽ cho bạn biết bạn đang ở trong tình huống nào trước khi bạn cam kết nhiều ngân sách hơn cho một trong hai con đường.
# Quyết định không phải là nhị phân
Hầu hết các cuộc trò chuyện về ERP bị lỗi đều bắt đầu ở điểm sai: "Chúng ta nên sửa chữa hay thay thế nó?" Câu hỏi hữu ích hơn là: "Cái gì thực sự bị hỏng và nó có thể sửa chữa được với chi phí hợp lý không?"
Một hệ thống có thể bị bỏ rơi vì một quy trình làm việc khó khăn mà không ai giải quyết được. Hoặc vì dữ liệu chưa bao giờ được làm sạch và không ai tin vào những con số. Hoặc vì giao diện di động chưa bao giờ được xây dựng và nhân viên sàn không có cách nào thực tế để sử dụng nó. Đây là những vấn đề có thể khắc phục được. Giải cứu là một cuộc gọi đúng đắn.
Nhưng một hệ thống được xây dựng dựa trên các giả định về quy trình làm việc không chính xác - trong đó toàn bộ mô hình quy trình sai đối với cách thức hoạt động của doanh nghiệp - thì việc gỡ rối sẽ tốn nhiều chi phí hơn là xây dựng lại các mô-đun bị ảnh hưởng một cách có chọn lọc. Trong trường hợp đó, việc thay thế các thành phần cụ thể sẽ rẻ hơn so với việc vá lỗi vĩnh viễn.
Dịch vụ kiểm tra hệ thống và cứu hộ ERP được cấu trúc để trả lời câu hỏi này bằng bằng chứng chứ không phải ý kiến.
# ERP bị lỗi thường trông như thế nào
Các triệu chứng bề mặt nhất quán giữa các ngành:
- Nhân viên duy trì các bản ghi song song trong Excel hoặc WhatsApp cùng với ERP
- Đội ngũ Tài chính đối chiếu thủ công vì không tin tưởng vào con số của hệ thống
- Hoạt động chạy trên bản in hoặc cuộc gọi điện thoại chứ không phải dữ liệu hệ thống
- Ban quản lý nhìn thấy bảng điều khiển không phản ánh những gì đang thực sự xảy ra
Các nguyên nhân cơ bản khác nhau. Tài nguyên về lý do tại sao các dự án ERP không thành công và trang vấn đề về ERP không được nhân viên sử dụng trình bày chi tiết về các mẫu chẩn đoán. Phiên bản ngắn gọn: hầu hết các lỗi ERP là lỗi thiết kế và triển khai, không phải lỗi công nghệ.
# Khung quyết định giải cứu
| Tìm kiếm | Đường dẫn được đề xuất |
|---|---|
| Kiến trúc đúng, UX kém | Thiết kế lại các thành phần hướng tới người dùng; giữ cốt lõi |
| Logic tốt, dữ liệu xấu | Dọn dẹp và di chuyển dữ liệu; hệ thống ở lại |
| Thiếu một quy trình công việc quan trọng | Xây dựng phần còn thiếu; tích hợp nó |
| Logic quy trình làm việc cơ bản sai | Xây dựng lại các mô-đun bị ảnh hưởng; di chuyển dữ liệu sạch |
| Không có tài liệu, không có khả năng bảo trì | Đánh giá rủi ro tiếp tục của nhà cung cấp/nhà phát triển trước |
| Nhân viên tích cực chống đối hệ thống | Nghiên cứu người dùng và thiết kế lại trước khi có bất kỳ thay đổi công nghệ nào |
# Nội dung kiểm tra cứu hộ ERP là gì
Kiểm toán có cấu trúc tạo ra một bức tranh rõ ràng về:
- Hệ thống được xây dựng để làm gì so với những gì doanh nghiệp thực sự cần nó làm
- Mô-đun nào phù hợp về mặt kỹ thuật và mô-đun nào có vấn đề về thiết kế
- Chất lượng dữ liệu — những gì có thể được làm sạch, những gì phải di chuyển, những gì cần loại bỏ
- Khoảng cách tích hợp — những gì hệ thống không kết nối được với nó
- Rào cản chấp nhận của người dùng — các màn hình, quy trình làm việc hoặc vai trò cụ thể mà hệ thống không đáp ứng được yêu cầu của người dùng
- Danh sách sửa chữa được ưu tiên với ước tính chi phí và công sức cho từng hạng mục
Điều này mang lại cho chủ doanh nghiệp cơ sở thực sự để đưa ra quyết định chi tiêu hay thay thế, thay vì khuyến nghị của nhà cung cấp dựa trên những gì họ muốn bán.
# Cái giá của việc không làm gì
ERP không được sử dụng không phải là tình huống trung lập. Nhân viên duy trì song song các quy trình thủ công, điều đó có nghĩa là chi phí vận hành hai hệ thống. Dữ liệu trong ERP càng không được xử lý càng xa thực tế, điều này càng làm tăng chi phí dọn dẹp cuối cùng. Và doanh nghiệp sẽ mất đi những cải tiến hoạt động mà họ đã chi trả.
Chi phí thời gian cho một cuộc kiểm tra cứu hộ thường là từ hai đến bốn tuần. Chi phí để ERP bị lỗi tồn tại thêm sáu tháng nữa thường lớn hơn.
# Điều gì khiến cuộc giải cứu có nhiều khả năng thành công hơn
- Chủ sở hữu nội bộ có thẩm quyền thúc đẩy việc áp dụng, không chỉ nhóm CNTT
- Sẵn sàng thu hút người dùng tuyến đầu tham gia vào quá trình thiết kế lại, không chỉ người quản lý
- Tiến trình rõ ràng về việc ngừng sử dụng các hệ thống song song (Excel, WhatsApp) sau khi sửa lỗi ERP
- Kỳ vọng thực tế: một cuộc giải cứu khắc phục hệ thống; việc áp dụng vẫn đòi hỏi sự cam kết của quản lý
Câu hỏi thường gặp
# Làm cách nào để biết liệu nhà phát triển ERP của chúng tôi có còn hỗ trợ hệ thống hay không?
Một cuộc kiểm tra cứu hộ đánh giá điều này một cách trực tiếp. Nếu nhà phát triển ban đầu không có mặt hoặc mã không có tài liệu, quá trình kiểm tra sẽ đánh dấu rủi ro và đề xuất đường dẫn để tìm hỗ trợ hoặc xây dựng lại các thành phần bị ảnh hưởng bằng tài liệu thích hợp.
# Chúng ta có thể giải cứu một ERP được xây dựng trên nền tảng mà chúng ta không tự chọn không?
Tùy thuộc vào nền tảng, vâng. Nếu hệ thống được xây dựng trên một khung tiêu chuẩn và cơ sở mã có thể truy cập được thì nhà phát triển mới có thể tiếp quản nó. Nếu nó được xây dựng trên nền tảng độc quyền do nhà cung cấp ban đầu kiểm soát thì các tùy chọn sẽ bị hạn chế hơn - quá trình kiểm tra sẽ cho bạn biết bạn đang ở trong tình huống nào.
# Có đáng để giải cứu ERP nếu nhà cung cấp đã tạo ra nó không còn phản hồi nữa không?
Đây là một trong những tình huống giải cứu phổ biến nhất. Câu trả lời phụ thuộc vào việc liệu cơ sở mã có thể truy cập được, ghi lại và được xây dựng trên khung mà nhà phát triển khác có thể làm việc hay không. Quá trình kiểm tra sẽ thiết lập điều này trong tuần đầu tiên.
- Nếu ERP của bạn không hoạt động và bạn không chắc chắn nên sửa chữa hay thay thế nó thì bước đầu tiên đúng đắn là kiểm tra trung thực — chứ không phải một đợt vá lỗi khác. WhatsApp us để mô tả vấn đề bạn đang giải quyết.*