Vì sao triển khai ERP thất bại?

Vì vậy, một dự án ERP có thể hoàn thành về mặt kỹ thuật nhưng vẫn không thành công về mặt kinh doanh. Hệ thống đã vận hành nhưng người dùng tiếp tục làm việc trên Excel, dữ liệu không đáng tin cậy, quy trình bị phá vỡ hoặc doanh nghiệp không thu được lợi ích như kỳ vọng.

Ngược lại, một dự án kéo dài chưa chắc đã thất bại hoàn toàn. Thời gian triển khai có thể tăng do doanh nghiệp chủ động chia nhỏ phạm vi, xử lý dữ liệu kỹ hơn hoặc lùi ngày vận hành để giảm rủi ro. Vấn đề chỉ thực sự nghiêm trọng khi tiến độ bị kéo dài mà phạm vi, chi phí, chất lượng và khả năng tạo giá trị đều không còn được kiểm soát.

Nguyên nhân cốt lõi của phần lớn dự án ERP không thành công là sự mất liên kết giữa bốn thành phần:

·         Mục tiêu kinh doanh

·         Quy trình vận hành

·         Con người và quyền ra quyết định

·         Công nghệ và dữ liệu

Khi một trong bốn thành phần này không sẵn sàng, các vấn đề sẽ lan sang những thành phần còn lại và tạo thành chuỗi trì hoãn.

Doanh nghiệp xem ERP là dự án công nghệ thay vì chương trình chuyển đổi vận hành

Sai lầm nền tảng là giao gần như toàn bộ trách nhiệm cho bộ phận công nghệ thông tin hoặc nhà cung cấp phần mềm. Cách tiếp cận này khiến doanh nghiệp tập trung vào cấu hình hệ thống, giao diện và chức năng nhưng không giải quyết câu hỏi quan trọng hơn: sau khi triển khai, doanh nghiệp sẽ vận hành khác đi như thế nào?

ERP tích hợp nhiều hoạt động vốn có quan hệ phụ thuộc với nhau. Một quyết định của bộ phận bán hàng có thể ảnh hưởng đến dự báo nhu cầu, tồn kho, kế hoạch sản xuất, mua nguyên vật liệu, công nợ và dòng tiền. Vì vậy, thay đổi tại một phân hệ không thể được quyết định riêng lẻ mà không đánh giá tác động đến toàn bộ chuỗi vận hành.

Khi dự án bị coi là nhiệm vụ của đội công nghệ, các phòng ban nghiệp vụ thường tham gia theo hình thức:

·         Chỉ cung cấp yêu cầu ban đầu

·         Tham dự một số buổi họp

·         Kiểm thử khi hệ thống gần hoàn thành

·         Nhận đào tạo ngay trước ngày vận hành

Đến giai đoạn kiểm thử, người dùng mới phát hiện hệ thống không phản ánh đúng nghiệp vụ thực tế. Dự án buộc phải quay lại làm rõ yêu cầu, sửa thiết kế, cấu hình lại, chuyển đổi lại dữ liệu và kiểm thử lại. Những vòng lặp này là một nguyên nhân trực tiếp khiến tiến độ kéo dài.

Trách nhiệm về kết quả ERP phải thuộc về lãnh đạo nghiệp vụ. Bộ phận công nghệ và đơn vị tư vấn chịu trách nhiệm về giải pháp, phương pháp và khả năng tích hợp; doanh nghiệp vẫn phải chịu trách nhiệm về quy trình, dữ liệu, chính sách và quyết định vận hành.

Mục tiêu dự án không đủ rõ hoặc không thể đo lường

Nhiều dự án được khởi động với các mục tiêu như “chuyển đổi số”, “quản trị tập trung”, “tăng hiệu quả” hoặc “minh bạch dữ liệu”. Đây là định hướng hợp lý nhưng chưa đủ để điều hành một chương trình ERP.

Nếu mục tiêu không được chuyển thành kết quả đo lường, đội dự án khó xác định chức năng nào thực sự cần thiết, quy trình nào phải thay đổi và yêu cầu nào có thể loại bỏ. Khi đó, mọi đề xuất từ các phòng ban đều có thể được xem là quan trọng, làm phạm vi dự án tăng liên tục.

Mục tiêu ERP cần gắn với các kết quả vận hành cụ thể, chẳng hạn:

·         Rút ngắn thời gian khóa sổ tài chính

·         Giảm số bước phê duyệt thủ công

·         Tăng độ chính xác của tồn kho

·         Giảm thời gian xử lý đơn hàng

·         Chuẩn hóa một quy trình cho nhiều đơn vị

·         Giảm số hệ thống và bảng tính trung gian

·         Tăng tỷ lệ giao hàng đúng hạn

Mỗi mục tiêu cần có đường cơ sở, chỉ số đo, người chịu trách nhiệm và thời điểm đánh giá. Nếu không có đường cơ sở trước triển khai, doanh nghiệp khó chứng minh hệ thống mới có tạo ra cải thiện hay không.

Mục tiêu không rõ còn làm phát sinh mâu thuẫn trong thiết kế. Phòng tài chính có thể ưu tiên kiểm soát, bộ phận bán hàng ưu tiên tốc độ, còn nhà máy ưu tiên tính linh hoạt. Nếu không có nguyên tắc ưu tiên cấp doanh nghiệp, từng bộ phận sẽ cố bảo vệ lợi ích cục bộ và kéo dự án vào quá trình tranh luận kéo dài.

Lãnh đạo bảo trợ nhưng không thực sự tham gia điều hành

Một dự án ERP có thể có chữ ký phê duyệt của lãnh đạo cao nhất nhưng vẫn thiếu sự bảo trợ thực chất. Bảo trợ không chỉ là cấp ngân sách hoặc tham dự cuộc họp khởi động. Lãnh đạo phải giải quyết các quyết định liên phòng ban mà đội dự án không có đủ thẩm quyền xử lý.

Các quyết định thường cần sự can thiệp của lãnh đạo gồm:

·         Có chuẩn hóa quy trình giữa các đơn vị hay không

·         Bộ phận nào là chủ sở hữu của từng loại dữ liệu

·         Có chấp nhận thay đổi chính sách vận hành hay không

·         Yêu cầu đặc thù nào thực sự tạo lợi thế cạnh tranh

·         Đơn vị nào phải từ bỏ cách làm hiện tại

·         Nguồn lực chủ chốt được ưu tiên cho dự án đến mức nào

·         Tiêu chí nào cho phép chuyển sang vận hành chính thức

Nếu các quyết định này không được đưa ra đúng thời điểm, đội triển khai thường chọn một trong hai cách: tạm dừng để chờ hoặc đưa ra giải pháp tạm thời. Cách thứ nhất làm chậm tiến độ; cách thứ hai tạo nợ thiết kế và phải sửa lại sau đó.

Quản trị yếu còn thể hiện ở việc không có cơ chế phân cấp quyết định. Những vấn đề nhỏ bị đẩy lên ban chỉ đạo, trong khi những vấn đề chiến lược lại được xử lý ở cấp nhóm chức năng. Hậu quả là thời gian phê duyệt dài nhưng chất lượng quyết định vẫn thấp.

Phạm vi dự án tăng liên tục và không có cơ chế kiểm soát thay đổi

ERP tác động đến nhiều phòng ban nên số lượng yêu cầu phát sinh thường rất lớn. Tuy nhiên, không phải mọi yêu cầu hợp lý về mặt nghiệp vụ đều phải được đưa vào giai đoạn triển khai đầu tiên.

Phạm vi thường mất kiểm soát khi:

·         Yêu cầu ban đầu chưa được xác định đầy đủ

·         Các bên liên quan tham gia quá muộn

·         Không phân biệt yêu cầu bắt buộc và yêu cầu mong muốn

·         Không đánh giá tác động của thay đổi đến chi phí và tiến độ

·         Không có người đủ thẩm quyền từ chối yêu cầu

·         Người dùng muốn tái tạo toàn bộ hệ thống cũ trên ERP mới

Một thay đổi tưởng như nhỏ có thể tác động đến cấu hình, phân quyền, báo cáo, tích hợp, dữ liệu chuyển đổi, tài liệu hướng dẫn và kịch bản kiểm thử. Vì vậy, chi phí thực tế của thay đổi không nằm riêng ở thời gian lập trình.

Mỗi yêu cầu bổ sung cần được đánh giá ít nhất theo bốn tiêu chí:

1.    Mức độ liên quan đến mục tiêu kinh doanh

2.    Mức độ bắt buộc về pháp lý hoặc kiểm soát

3.    Tác động đến tiến độ, chi phí và rủi ro

4.    Khả năng chuyển sang giai đoạn sau

Kiểm soát phạm vi không có nghĩa là từ chối mọi thay đổi. Mục tiêu là bảo đảm mỗi thay đổi được chấp nhận có giá trị lớn hơn chi phí và rủi ro mà nó tạo ra.

Quy trình chưa được chuẩn hóa trước khi cấu hình hệ thống

ERP không thể tự giải quyết một quy trình mà doanh nghiệp chưa thống nhất. Nếu cùng một nghiệp vụ được thực hiện theo nhiều cách tại các chi nhánh hoặc phòng ban, đội triển khai phải lựa chọn giữa chuẩn hóa, cho phép nhiều biến thể hoặc tùy chỉnh hệ thống.

Khi quyết định này không được đưa ra sớm, các buổi phân tích yêu cầu dễ biến thành quá trình mô tả chi tiết cách làm hiện tại. Nhà cung cấp ghi nhận hàng loạt ngoại lệ nhưng không biết ngoại lệ nào thực sự cần được duy trì.

Hệ quả thường gặp là:

·         Thiết kế ngày càng phức tạp

·         Số lượng quy tắc và luồng phê duyệt tăng

·         Khó kiểm thử đầy đủ mọi tình huống

·         Tài liệu hướng dẫn khó hiểu

·         Người dùng khó tuân thủ quy trình chung

·         Chi phí bảo trì và nâng cấp tăng

Doanh nghiệp cần phân biệt giữa sự khác biệt tạo giá trị và sự khác biệt hình thành do lịch sử. Những yêu cầu liên quan đến mô hình kinh doanh, quy định pháp lý hoặc lợi thế cạnh tranh có thể cần được giữ lại. Những khác biệt chỉ xuất phát từ thói quen địa phương nên được xem xét để chuẩn hóa.

ERP phát huy hiệu quả khi hệ thống hỗ trợ quy trình mục tiêu, không phải khi hệ thống sao chép nguyên trạng mọi bất cập của quy trình cũ.

Tùy chỉnh quá mức làm tăng độ phức tạp của toàn bộ vòng đời

Tùy chỉnh không phải lúc nào cũng sai. Một số doanh nghiệp có nghiệp vụ đặc thù mà phần mềm chuẩn không thể đáp ứng đầy đủ. Vấn đề xuất hiện khi tùy chỉnh trở thành phản ứng mặc định trước mọi khoảng cách giữa quy trình hiện tại và hệ thống.

Mỗi tùy chỉnh có thể kéo theo:

·         Thời gian phân tích và phát triển

·         Kiểm thử bổ sung

·         Phụ thuộc vào nhà cung cấp hoặc lập trình viên cụ thể

·         Khó khăn khi nâng cấp phiên bản

·         Rủi ro xung đột với chức năng chuẩn

·         Chi phí bảo trì lâu dài

·         Khó chuẩn hóa giữa các đơn vị

Tùy chỉnh quá mức thường không bắt nguồn từ giới hạn công nghệ mà từ việc doanh nghiệp không muốn thay đổi cách làm cũ. Khi đó, dự án dùng phần mềm mới để bảo tồn quy trình cũ và đánh mất phần lớn lợi ích của ERP.

Trước khi chấp nhận tùy chỉnh, đội dự án cần trả lời:

·         Khoảng cách này có ảnh hưởng đến yêu cầu bắt buộc hay không

·         Quy trình chuẩn của hệ thống có thể đáp ứng mục tiêu kinh doanh hay không

·         Có thể thay đổi chính sách hoặc cách vận hành thay vì sửa phần mềm hay không

·         Lợi ích tài chính có bù được chi phí vòng đời hay không

·         Tùy chỉnh sẽ ảnh hưởng thế nào đến nâng cấp và hỗ trợ sau này

Một quyết định tùy chỉnh chỉ hợp lý khi có lý do kinh doanh rõ ràng, không đơn thuần vì người dùng quen với giao diện hoặc quy trình hiện tại.

Dữ liệu nguồn kém chất lượng và trách nhiệm dữ liệu không rõ ràng

Dữ liệu thường bị đánh giá thấp vì nhiều doanh nghiệp xem chuyển đổi dữ liệu là công việc kỹ thuật: trích xuất, chuyển đổi và tải dữ liệu từ hệ thống cũ sang ERP.

Trên thực tế, phần khó nhất không phải là di chuyển dữ liệu mà là quyết định dữ liệu nào đúng, dữ liệu nào còn giá trị và ai chịu trách nhiệm xác nhận.

Các vấn đề phổ biến gồm:

·         Mã khách hàng hoặc nhà cung cấp bị trùng

·         Quy tắc đặt mã không thống nhất

·         Đơn vị tính không đồng nhất

·         Thông tin bắt buộc bị thiếu

·         Số dư không khớp giữa các hệ thống

·         Dữ liệu không còn sử dụng nhưng chưa được đóng

·         Quan hệ giữa dữ liệu danh mục và giao dịch bị sai

·         Không xác định được nguồn dữ liệu chính thức

Dữ liệu kém chất lượng làm chậm thiết kế, kiểm thử và vận hành. Khi dữ liệu thử nghiệm không đại diện cho thực tế, kết quả kiểm thử trở nên thiếu tin cậy. Khi dữ liệu sai được đưa vào hệ thống chính thức, người dùng mất niềm tin và quay lại sử dụng công cụ cũ.

Chất lượng dữ liệu phải được quản trị như một luồng công việc độc lập với các vai trò rõ ràng:

·         Chủ sở hữu dữ liệu quyết định quy tắc nghiệp vụ

·         Data steward tổ chức làm sạch và duy trì chất lượng

·         Đội kỹ thuật thực hiện chuyển đổi

·         Người dùng nghiệp vụ đối soát kết quả

·         Ban điều hành giải quyết các tranh chấp về nguồn dữ liệu

Cần thực hiện nhiều vòng chuyển đổi thử thay vì chờ đến sát ngày vận hành mới chạy dữ liệu lần đầu.

Tích hợp với hệ thống khác bị đánh giá thấp

ERP hiếm khi hoạt động độc lập. Hệ thống thường phải trao đổi dữ liệu với thương mại điện tử, ngân hàng, quản lý kho, sản xuất, chấm công, CRM, vận tải, hóa đơn điện tử hoặc các ứng dụng chuyên ngành.

Tích hợp bị chậm không chỉ vì kỹ thuật kết nối. Mỗi giao diện còn đòi hỏi làm rõ:

·         Hệ thống nào tạo dữ liệu gốc

·         Dữ liệu được đồng bộ theo thời gian thực hay theo lô

·         Quy tắc xử lý khi giao dịch lỗi

·         Cách chống trùng dữ liệu

·         Cơ chế đối soát

·         Trách nhiệm vận hành và hỗ trợ

·         Yêu cầu bảo mật và phân quyền

Nếu những quyết định này được để đến cuối dự án, đội triển khai có thể hoàn thành từng phân hệ nhưng không thể kiểm thử quy trình xuyên suốt.

Một giao diện hoạt động trong điều kiện thử nghiệm cũng chưa đủ để chứng minh khả năng vận hành. Hệ thống phải được kiểm tra với khối lượng dữ liệu thực tế, tình huống mất kết nối, giao dịch trùng, dữ liệu thiếu và khả năng phục hồi sau lỗi.

Kiểm thử chỉ xác nhận chức năng, không xác nhận khả năng vận hành

Một dự án có thể báo cáo tỷ lệ kiểm thử cao nhưng vẫn gặp sự cố lớn sau khi vận hành. Nguyên nhân là kiểm thử tập trung vào từng chức năng riêng lẻ thay vì các quy trình kinh doanh xuyên suốt.

Ví dụ, chức năng tạo đơn hàng, xuất kho và lập hóa đơn có thể hoạt động riêng biệt. Tuy nhiên, quy trình từ tiếp nhận đơn hàng đến ghi nhận doanh thu vẫn có thể thất bại khi dữ liệu, phân quyền, tích hợp hoặc trường hợp ngoại lệ không khớp nhau.

Kiểm thử ERP cần bao phủ nhiều lớp:

Kiểm thử chức năng

Xác nhận từng chức năng hoạt động theo thiết kế

Kiểm thử tích hợp

Xác nhận dữ liệu di chuyển đúng giữa các phân hệ và hệ thống

Kiểm thử quy trình xuyên suốt

Xác nhận một giao dịch có thể đi từ điểm bắt đầu đến kết quả cuối cùng

Kiểm thử phân quyền và kiểm soát

Xác nhận người dùng có đúng quyền và các xung đột trách nhiệm được kiểm soát

Kiểm thử hiệu năng

Xác nhận hệ thống đáp ứng được khối lượng giao dịch thực tế

Kiểm thử chấp nhận của người dùng

Xác nhận quy trình có thể được thực hiện trong điều kiện vận hành thật

Kiểm thử chấp nhận thường thất bại khi người dùng tham gia quá muộn, kịch bản không phản ánh công việc thực tế hoặc dữ liệu kiểm thử quá đơn giản. Việc “ký xác nhận” khi lỗi nghiêm trọng chưa được xử lý chỉ chuyển rủi ro từ dự án sang giai đoạn vận hành.

Các cuộc đánh giá của Cơ quan Kiểm toán Chính phủ Hoa Kỳ đối với những chương trình ERP quy mô lớn đã nhiều lần liên hệ điểm yếu trong kiểm thử, kiểm soát thay đổi, xác minh độc lập và quản lý lịch trình với chậm tiến độ, vượt chi phí hoặc nguy cơ không đạt mục tiêu.

Quản trị thay đổi và đào tạo được thực hiện quá muộn

Đào tạo người dùng không đồng nghĩa với quản trị thay đổi. Đào tạo giúp người dùng biết thao tác; quản trị thay đổi giúp họ hiểu tại sao phải thay đổi, trách nhiệm mới là gì và cách công việc của họ sẽ bị ảnh hưởng.

Người dùng có thể chống đối ERP vì nhiều lý do:

·         Quy trình mới làm thay đổi quyền phê duyệt

·         Hệ thống tăng tính minh bạch và khả năng truy vết

·         Một số bước kiểm soát trở nên bắt buộc

·         Công việc được phân bổ lại giữa các phòng ban

·         Dữ liệu phải được nhập sớm và chính xác hơn

·         Các công cụ cá nhân không còn được chấp nhận

·         Người dùng lo ngại không đáp ứng được yêu cầu mới

Nếu những tác động này chỉ được truyền thông ngay trước ngày vận hành, doanh nghiệp không có đủ thời gian điều chỉnh vai trò, chính sách và năng lực.

Đào tạo hiệu quả phải dựa trên vai trò và tình huống công việc. Người dùng cần thực hành toàn bộ quy trình bằng dữ liệu gần với thực tế, không chỉ xem trình bày chức năng. Quản lý trực tiếp cũng phải được chuẩn bị để hỗ trợ nhân viên và xử lý việc không tuân thủ sau khi hệ thống vận hành.

Nghiên cứu về triển khai ERP cho thấy mức độ phù hợp giữa hệ thống và tổ chức, sự hỗ trợ của lãnh đạo, năng lực đội dự án, chất lượng tư vấn và khả năng chấp nhận của người dùng đều có quan hệ trực tiếp với kết quả triển khai.

Doanh nghiệp không bố trí đủ nhân sự nghiệp vụ có năng lực

ERP thường phải cạnh tranh nguồn lực với hoạt động kinh doanh hằng ngày. Những nhân sự hiểu quy trình nhất cũng thường là những người đang giữ vị trí quan trọng nhất trong vận hành.

Nếu doanh nghiệp chỉ cho phép họ tham gia bán thời gian nhưng vẫn giữ nguyên toàn bộ công việc hiện tại, dự án sẽ gặp ba vấn đề:

·         Quyết định nghiệp vụ bị chậm

·         Yêu cầu được cung cấp không đầy đủ

·         Kiểm thử và xác nhận dữ liệu bị thực hiện vội vàng

Thay thế chuyên gia nghiệp vụ bằng người ít kinh nghiệm không giải quyết được vấn đề. Người tham gia cần hiểu cả quy trình chính thức lẫn các tình huống ngoại lệ đã xảy ra trong thực tế.

Đội dự án cũng cần có quyền đưa ra quyết định trong phạm vi được giao. Nếu mọi vấn đề đều phải quay về xin ý kiến lãnh đạo phòng ban, tốc độ xử lý sẽ không đáp ứng được nhịp độ triển khai.

Nguồn lực cần được lập kế hoạch theo từng giai đoạn. Nhu cầu nhân sự thường tăng mạnh trong các thời điểm thiết kế, làm sạch dữ liệu, kiểm thử, đào tạo, chuyển đổi và hỗ trợ sau vận hành. Phân bổ nhân sự đồng đều trong toàn bộ dự án có thể khiến doanh nghiệp thiếu người đúng lúc quan trọng nhất.

Kế hoạch dự án dựa trên ngày mục tiêu thay vì khối lượng công việc thực tế

Nhiều doanh nghiệp lựa chọn ngày vận hành trước khi hoàn thành phân tích phạm vi, đánh giá dữ liệu, xác định số lượng tích hợp và kiểm tra năng lực nguồn lực.

Khi thời hạn được đặt ra theo mong muốn quản trị thay vì dữ liệu lập kế hoạch, đội dự án thường phải:

·         Thực hiện nhiều luồng công việc đồng thời

·         Rút ngắn kiểm thử

·         Giảm thời gian đào tạo

·         Chấp nhận lỗi tồn đọng

·         Trì hoãn xử lý dữ liệu

·         Đưa các chức năng chưa sẵn sàng sang giải pháp thủ công

Điều này tạo ra tiến độ “xanh” trên báo cáo nhưng tích tụ rủi ro bên dưới. Đến gần ngày vận hành, hàng loạt phụ thuộc chưa hoàn thành mới xuất hiện và buộc dự án phải lùi lịch.

Lịch trình ERP cần thể hiện mối quan hệ giữa thiết kế, phát triển, dữ liệu, tích hợp, kiểm thử, đào tạo và chuyển đổi. Một mốc chỉ có ý nghĩa khi các điều kiện đầu vào của nó đã hoàn tất.

Trường hợp hệ thống Expeditionary Combat Support System của Bộ Quốc phòng Hoa Kỳ cho thấy hậu quả của quản lý lịch trình yếu: chương trình bị hủy sau khi đã tiêu khoảng 1 tỷ USD, được dự kiến cần thêm khoảng 1 tỷ USD và có thể trì hoãn triển khai đến năm tài chính 2020; cơ quan quản lý cũng thừa nhận việc thiếu lịch trình tổng thể tích hợp đã góp phần vào quyết định chấm dứt chương trình.

Phụ thuộc quá mức vào nhà cung cấp và tư vấn triển khai

Đơn vị tư vấn có thể cung cấp kinh nghiệm, phương pháp và nguồn lực chuyên môn, nhưng không thể thay doanh nghiệp sở hữu quy trình hoặc đưa ra mọi quyết định nghiệp vụ.

Sự phụ thuộc quá mức xuất hiện khi:

·         Nhà cung cấp tự xác định yêu cầu thay cho doanh nghiệp

·         Tài liệu thiết kế không được đội nội bộ hiểu rõ

·         Kiến thức cấu hình chỉ nằm ở tư vấn

·         Doanh nghiệp không có kế hoạch chuyển giao

·         Mọi sự cố sau vận hành đều phải thuê ngoài xử lý

·         Tiêu chí nghiệm thu do chính bên cung cấp giải pháp chi phối

Xung đột lợi ích cũng có thể phát sinh. Nhà cung cấp có động cơ hoàn thành phạm vi hợp đồng, trong khi doanh nghiệp cần bảo đảm kết quả vận hành dài hạn. Hai mục tiêu này không phải lúc nào cũng trùng nhau.

Doanh nghiệp cần duy trì năng lực chủ sở hữu giải pháp nội bộ, bao gồm kiến thức về quy trình, dữ liệu, cấu hình, tích hợp, kiểm soát và vận hành. Chuyển giao kiến thức phải được thực hiện xuyên suốt dự án thay vì tổ chức một số buổi bàn giao ở giai đoạn cuối.

Quyết định vận hành chính thức dựa trên áp lực tiến độ

Go-live là thời điểm chuyển rủi ro từ môi trường dự án sang hoạt động kinh doanh. Vì vậy, quyết định vận hành không nên chỉ dựa trên việc đã đến ngày kế hoạch.

Các điều kiện sẵn sàng cần được đánh giá độc lập, bao gồm:

·         Quy trình trọng yếu đã được kiểm thử xuyên suốt

·         Không còn lỗi nghiêm trọng chưa có phương án xử lý

·         Dữ liệu đã được đối soát và phê duyệt

·         Tích hợp đã được kiểm tra với khối lượng thực tế

·         Người dùng trọng yếu đã hoàn thành đào tạo

·         Bộ phận hỗ trợ đã có quy trình tiếp nhận và phân loại sự cố

·         Kế hoạch chuyển đổi và quay lui đã được diễn tập

·         Báo cáo quản trị và kiểm soát tài chính đã được xác nhận

Việc lùi ngày vận hành có thể gây tốn kém, nhưng vận hành khi chưa sẵn sàng có thể gây gián đoạn đơn hàng, tồn kho, sản xuất, thanh toán và báo cáo tài chính.

Tuy nhiên, yêu cầu “không còn bất kỳ lỗi nào” cũng không thực tế. Doanh nghiệp cần phân loại lỗi theo mức ảnh hưởng và xác định rõ lỗi nào bắt buộc phải xử lý trước, lỗi nào có giải pháp tạm thời và lỗi nào có thể chuyển sang giai đoạn ổn định hệ thống.

Thất bại thường hình thành từ chuỗi nguyên nhân chứ không phải một lỗi đơn lẻ

Một dự án ERP hiếm khi thất bại chỉ vì một nguyên nhân. Các yếu tố thường liên kết và khuếch đại lẫn nhau.

Một chuỗi thất bại điển hình có thể diễn ra như sau:

1.    Mục tiêu kinh doanh không rõ nên phạm vi khó ưu tiên

2.    Phạm vi tăng làm thiết kế phức tạp

3.    Thiết kế phức tạp làm phát sinh nhiều tùy chỉnh

4.    Tùy chỉnh làm chậm tích hợp và kiểm thử

5.    Kiểm thử bị dồn về cuối để giữ ngày vận hành

6.    Người dùng được đào tạo trên hệ thống chưa ổn định

7.    Dữ liệu chưa sạch nhưng vẫn được chuyển đổi

8.    Hệ thống vận hành với nhiều lỗi và quy trình thủ công

9.    Người dùng mất niềm tin và quay lại công cụ cũ

10.  Doanh nghiệp không đạt được lợi ích dự kiến

Cách nhìn theo chuỗi nguyên nhân quan trọng hơn việc tìm một bên để quy trách nhiệm. Một lỗi kỹ thuật xuất hiện cuối dự án có thể chỉ là biểu hiện của quyết định phạm vi, dữ liệu hoặc quản trị đã được đưa ra từ nhiều tháng trước.

Khi nào dự án kéo dài nhưng chưa thể xem là thất bại?

Tiến độ dài hơn kế hoạch không tự động đồng nghĩa với triển khai ERP thất bại. Việc điều chỉnh lịch có thể hợp lý khi doanh nghiệp phát hiện rủi ro quan trọng và chủ động xử lý trước khi vận hành.

Dự án kéo dài nhưng vẫn có thể được kiểm soát nếu:

·         Phạm vi điều chỉnh được phê duyệt minh bạch

·         Lợi ích kinh doanh mục tiêu vẫn còn khả thi

·         Chi phí hoàn thành được dự báo lại đáng tin cậy

·         Các rủi ro chính có người chịu trách nhiệm

·         Chất lượng thiết kế và kiểm thử tiếp tục được cải thiện

·         Ban điều hành có tiêu chí rõ ràng để tiếp tục hoặc dừng

·         Thời gian bổ sung dùng để xử lý nguyên nhân gốc

Ngược lại, dự án có dấu hiệu thất bại khi lịch liên tục thay đổi nhưng không xác định được phạm vi còn lại, chi phí hoàn thành, mức độ sẵn sàng và giá trị kinh doanh có thể đạt được.

Thành công cũng không nên chỉ được định nghĩa là “đúng hạn và đúng ngân sách”. Một hệ thống được đưa vào sử dụng đúng ngày nhưng không được chấp nhận, không tạo dữ liệu đáng tin cậy hoặc không cải thiện vận hành vẫn là một kết quả không thành công.

Cách nhận biết sớm dự án ERP đang mất kiểm soát

Các dấu hiệu cảnh báo thường xuất hiện trước khi dự án chính thức trễ tiến độ:

·         Quyết định quan trọng tồn đọng qua nhiều kỳ báo cáo

·         Phạm vi tăng nhưng ngân sách và lịch trình không thay đổi

·         Số lượng tùy chỉnh tiếp tục tăng sau khi thiết kế đã được phê duyệt

·         Dữ liệu không có chủ sở hữu rõ ràng

·         Các vòng chuyển đổi thử liên tục không thể đối soát

·         Kiểm thử bị lùi nhưng ngày vận hành vẫn giữ nguyên

·         Người dùng chủ chốt vắng mặt trong các buổi thiết kế

·         Lỗi được đóng để đạt chỉ tiêu thay vì được xử lý dứt điểm

·         Nhiều quy trình vẫn cần bảng tính hoặc thao tác thủ công

·         Đội dự án báo cáo tiến độ dựa trên phần trăm hoàn thành chủ quan

·         Kế hoạch đào tạo bắt đầu khi hệ thống chưa ổn định

·         Nhà cung cấp và doanh nghiệp liên tục tranh luận về trách nhiệm

·         Ban chỉ đạo nhận nhiều báo cáo nhưng ít đưa ra quyết định

Một dấu hiệu riêng lẻ chưa đủ để kết luận dự án thất bại. Tuy nhiên, nếu nhiều dấu hiệu xuất hiện đồng thời và kéo dài, doanh nghiệp cần đánh giá lại toàn bộ phạm vi, mô hình quản trị và khả năng hoàn thành, thay vì chỉ yêu cầu đội dự án “đẩy nhanh tiến độ”.

Làm thế nào để giảm nguy cơ triển khai ERP thất bại?

Doanh nghiệp không thể loại bỏ toàn bộ rủi ro, nhưng có thể giảm đáng kể xác suất dự án kéo dài hoặc không tạo giá trị bằng một số nguyên tắc quản trị cốt lõi.

Xác định kết quả kinh doanh trước khi chọn giải pháp

Mỗi mục tiêu phải có chỉ số, đường cơ sở, chủ sở hữu và thời điểm đo lường. Phạm vi chức năng phải được ưu tiên dựa trên các kết quả này.

Thiết lập quyền quyết định rõ ràng

Cần quy định vấn đề nào do nhóm chức năng quyết định, vấn đề nào cần kiến trúc giải pháp xem xét và vấn đề nào phải được ban chỉ đạo phê duyệt. Mỗi quyết định phải có thời hạn xử lý.

Ưu tiên quy trình chuẩn

Doanh nghiệp nên bắt đầu từ quy trình chuẩn của hệ thống, sau đó chỉ giữ lại những khác biệt có căn cứ pháp lý, kiểm soát hoặc giá trị cạnh tranh rõ ràng.

Quản trị dữ liệu từ đầu dự án

Dữ liệu cần có chủ sở hữu nghiệp vụ, tiêu chuẩn chất lượng, quy tắc làm sạch, nhiều vòng chuyển đổi thử và cơ chế đối soát chính thức.

Kiểm soát thay đổi bằng giá trị và tác động

Mọi yêu cầu bổ sung phải được đánh giá về lợi ích, chi phí vòng đời, ảnh hưởng đến lịch trình và khả năng chuyển sang giai đoạn sau.

Kiểm thử theo quy trình xuyên suốt

Không chỉ kiểm tra từng màn hình hoặc chức năng. Kịch bản phải phản ánh giao dịch thực tế, ngoại lệ, phân quyền, tích hợp và khối lượng vận hành.

Chuẩn bị người dùng trước ngày đào tạo

Truyền thông về vai trò mới, thay đổi quy trình và trách nhiệm dữ liệu phải bắt đầu từ giai đoạn thiết kế. Đào tạo chỉ là một phần của quá trình chuẩn bị.

Ra quyết định go-live dựa trên mức độ sẵn sàng

Ngày vận hành phải được bảo vệ bằng tiêu chí định lượng, đánh giá rủi ro và phương án quay lui, không chỉ bằng cam kết tiến độ.

Triển khai ERP thất bại thường không bắt đầu ở thời điểm hệ thống phát sinh lỗi. Thất bại hình thành sớm hơn, khi doanh nghiệp đặt mục tiêu không rõ, giao trách nhiệm không đúng, trì hoãn quyết định, cho phép phạm vi tăng, bảo tồn quy trình cũ và đánh giá thấp dữ liệu cùng yếu tố con người.

Công nghệ có thể là nơi vấn đề biểu hiện rõ nhất, nhưng nguyên nhân sâu xa thường thuộc về quản trị và năng lực chuyển đổi tổ chức. Muốn dự án thành công, doanh nghiệp phải quản lý ERP như một chương trình thay đổi vận hành có sự tham gia của lãnh đạo, chủ sở hữu quy trình, đội dữ liệu, người dùng và đối tác triển khai.

Một dự án ERP tốt không phải dự án có nhiều chức năng nhất hoặc tùy chỉnh sát hệ thống cũ nhất. Đó là dự án tạo ra quy trình rõ hơn, dữ liệu đáng tin cậy hơn, trách nhiệm minh bạch hơn và kết quả kinh doanh có thể đo lường.