Chuyển đổi ERP không bao giờ là dễ dàng, Agile có thể giúp cải thiện kết quả của bạn.

Các kế hoạch hoạch định nguồn lực doanh nghiệp (ERP) là một tài sản thiết yếu đối với hầu hết các doanh nghiệp lớn, tuy nhiên việc chuyển đổi ERP thường tốn nhiều thời gian và phức tạp. Một cách tiếp cận linh hoạt (agile) có khả năng hợp lý hóa đáng kể các dự án ERP, nhưng các chuyên gia IT từ lâu đã tin rằng yếu tố linh hoạt không phù hợp với ERP. Tuy nhiên, kinh nghiệm của chúng tôi trong việc giúp nhiều tổ chức áp dụng, thực hành agile trong nhiều tình huống, đã chứng minh điều ngược lại: rằng agile có thể được áp dụng thành công trong các chương trình ERP, với kết quả tốt hơn về mặt định lượng. Phương pháp đơn giản là phải thích ứng với các yêu cầu độc nhất của các giải pháp phức tạp này.

Tại sao chuyển đổi ERP vẫn quan trọng

Các giải pháp ERP đã không nằm trong thứ tự ưu tiên ở chương trình nghị sự của cuộc họp quản trị công nghệ thông tin, để nhường chỗ cho các nội dung thời thượng hơn, như kĩ thuật số, big data, machine learrning và cloud. Tuy nhiên, không thể phủ nhận lợi ích mà giải pháp ERP mang lại, cụ thể là sự tích hợp liền mạch giữa các đơn vị chức năng, tiêu chuẩn hoá quy trình giữa các khu vực địa lí, các đơn vị kinh doanh, và biến các giải pháp này trở thành tài sản cơ bản của hầu hết các công ty lớn.

Hơn thế nữa, thế hệ tiếp theo của các giải pháp ERP, như là Oracle Cloud, và SAP S/4HANA đang hứa hẹn cung cấp những lợi ích về cả mặt chức năng và công nghệ. Các công ty tập trung vào chuyển đổi kĩ thuật số hoặc các chương trình phân tích chuyên sâu đã bắt đầu nhận ra rằng, để mở rộng khả năng đầu tư, liên kết yếu tố công nghệ với nền tảng ERP là một điều cần thiết.

Những thách thức của việc chuyển đổi ERP

Cơ bản như vậy, ba phần tư các dự án chuyển đổi ERP không đúng tiến độ hoặc ngân sách, và hai phần ba có lợi tức đầu tư âm. Có năm lý do chính:

• Không đồng bộ ưu tiên: Các bộ phận không chia sẻ chung mục tiêu
• Quản lý dự án kém: Hầu hết các tổ chức thiếu kinh nghiệm trong việc quản trị các dự án IT và các chương trình đa cấp độ
• Thiếu yếu tố kinh doanh – công nghệ: Hệ thống ERP yêu cầu sự kết hợp giữa kinh doanh và các bộ phận vận hành, quản trị dữ liệu và thẩm định
• Thiếu sự tập trung vào các giá trị tổ chức: Các hoạt động và vận hành có xu hướng dẫn dắt chuyển đổi ERP.
• Phương pháp thác nước: Phần lớn các dự án ERP đều sử dụng cách tiếp cận thác nước, điều này dẫn đến việc trì hoãn việc thực hiện giá trị của dự án

Đầu tiên, tất cả các bộ phận chức năng có thể không chia sẻ chung một mục tiêu. Ví dụ, một nhà tích hợp hệ thống có thể có xu hướng gia tăng phạm vi chương trình và thời lượng nếu điều đó đem lại lợi nhuận. Trong khi đó, công ty muốn vận hành dự án và mang lại giá trị nhanh nhất có thể.

Thứ hai, hầu hết các tổ chức thiếu kinh nghiệm trong việc quản trị các dự án IT lớn và các chương trình đa cung cấp (multivendor programs). Họ không có đủ người quản lý có kỹ năng, chưa bao giờ thiết lập nền tảng quản trị chặt chẽ cho các chương trình như vậy và không hiểu được mức độ thông tin đầu vào từ các nhà kinh doanh.

Tiếp theo, hệ thống ERP có một phạm vi rộng lớn, tích hợp, chức năng và do đó đòi hỏi các cuộc thảo luận phức tạp trong nội bộ doanh nghiệp về các mô hình hoạt động, quản lí dữ liệu và thẩm định. Những quyết định được đưa ra cho ban điều hành thường dựa trên những thông tin không có sẵn. Dự án thường phải tạm dừng để các quyết định được đưa ra, điều đó dẫn đến việc chậm tiến độ, thậm chí làm giảm giá trị của các ý tưởng.

Thứ tư, các hoạt động và vận hành có xu hướng dẫn dắt hoạt động chuyển đổi ERP; tuy nhiên, việc chuyển đổi phải dựa trên giá trị doanh nghiệp, phải được định lượng, ghi lại và theo dõi để định hướng.

Cuối cùng, hầu hết các dự án ERP được thực hiện bằng cách sử dụng cách tiếp cận thác nước tuần tự, tuyến tính, làm trì hoãn việc thực hiện giá trị của dự án.

Những thách thức này thường khiến việc triển khai ERP kéo dài từ năm thậm chí đến mười năm. Quá trình triển khai điển hình thường bao gồm các giai đoạn: thiết kế, thông số kỹ thuật và kế hoạch chi tiết nhưng không mang lại tác động có thể đo lường được trong khi giá trị cổ đông giảm dần theo từng ngày.

Số liệu cụ thể cho thấy thách thức của việc chuyển đổi ERP

Những quan niệm sai lầm và sự thật về linh hoạt, ERP

Quan niệm triết lí linh hoạt (Agile) không thể ứng dụng cho việc triển khai ERP xuất phát từ một vài quan niệm sai lầm: rằng việc triển khai ERP quá lớn, và phức tạp để các nhóm Agile có thể quản lí và phân chia được thành các thẻ người dùng (user stories) để có thể phát triển, và kiểm thử trong một sprint ngắn; rằng ERP là một tiêu chuẩn phần mềm, và do đó cách tiếp cận linh hoạt được thiết kế cho các yêu cầu liên tục thay đổi hoặc không xác định, do đó không cần thiết hoặc áp dụng, và rằng một số giải pháp ERP có thể được hiện hữu dần cho người dùng cuối, vì họ sẽ không thể nhận thấy một giá trị nào cho tới khi sản phẩm được xây dựng và tích hợp đầy đủ.

Trong thực tế, việc thực hành Agile có thể giảm thiểu nhiều rủi ro và thách thức cho việc thực hiện ERP trong một số trường hợp. Chẳng hạn, theo triết lí Agile, các nhà cung cấp và các nhà tích hợp hệ thống làm việc cùng nhau trong một nhóm để tập trung đạt được cùng một bộ hiệu suất chính (KPI) và kết quả.

Điều đó cũng liên quan đến tốc độ nhanh hơn, minh bạch hơn, giúp các nhà quản lí dễ dàng đưa ra các quyết định quan trọng và kịp thời. Không giống với suy nghĩ của nhiều người, Agile không có nghĩa là không có kế hoạch. Agile thay thế các giai đoạn dài bằng các phân đoạn ngắn, từ 2  đến 3 tuần để các nhà quản lí có thể dễ dàng theo dõi kết quả, tiến độ và thách thức.

Agile kêu gọi các nhóm kinh doanh và IT làm việc trong cùng một nhóm, hướng đến việc xây dựng giá trị. Hai nhóm chức năng này cùng hợp tác từ đầu dự án, thúc đẩy năng lực của cả hai. Và Agile cũng giúp phân chia phạm vi chức năng của ERP thành các bộ phận, nhóm nhỏ để cung cấp giá trị trong các Sprint. Vòng lặp phát triển của Agile sẽ giúp các dự án đạt được giá trị kinh doanh nhanh chóng.

Tóm lại, thực hành Agile là chính xác những gì cần để triển khai ERP. Không có gì ngạc nhiên khi các nhà cung cấp ERP hàng đầu như SAP, hiện đang khuyến khích cách tiếp cận Agile nhiều hơn.

Làm thế nào để thích ứng Agile với ERP

Một số cách tiếp cận Agile có thể được áp dụng trực tiếp vào việc triển khai ERP mà không cần điều chỉnh: hình thành các nhóm nhỏ, làm việc từ khi bắt đầu đến khi kết thúc dự án, nhóm liên chức năng, với các chủ sở hữu sản phẩm là doanh nghiệp và người dùng cuối, làm việc theo chu kì ngắn từ hai đến ba tuần để sản xuất phần mềm (hoặc cấu hình, giao diện,…) tăng dần, áp dụng các sự kiện trong scrum, tập trung cải tiến liên tục, với sự minh bạch, và KPI, sử dụng công cụ và công nghệ như: tự động hoá các thử nghiệm, tích hợp liên tục, giúp tối ưu hoá và tăng tốc quá trình làm ra sản phẩm.

Tuy nhiên, một số thực hành Agile khác cần được điều chỉnh. Ví dụ, toàn bộ phạm vi dự án cần được xác định ở cấp độ cao, bao gồm các tiêu chí thành công rõ ràng – điều này hoàn toàn khác với cách tiếp cận agile phổ biến với một số sản phẩm tối thiểu (minimum viable product). Các nhóm có thể được phép đặt phạm vi chi tiết và sắp xếp thứ tự ưu tiên trong quá trình vận hành.

Ngoài ra, để đảm bảo tính nhất quán, phải tập trung vào quy trình và mục tiêu kinh doanh hơn là việc triển khai Agile thông thường để công việc có thể được phân chia vào các nhóm nhỏ.

Các mối liên kết giữa các nhóm Agile cũng cung cấp các chức năng và “chuyển đổi” nhóm, như là các nhóm không chức năng. Ví dụ, nhóm di chuyển dữ liệu, nhóm tích hợp, và sự thay đổi nhóm có thể hỗ trợ cho vịệc phát triển chức năng hay tính năng nào đó. Tất cả các nhóm nên được đồng bộ hoá để hoạt động chung một nhịp và cùng nhau về đích.

“Sản xuất sẵn sàng” (Production ready) trong phần mềm có thể không được áp dụng thường xuyên như thường lệ. Một giai đoạn thử nghiệm từ đầu đến cuối (E2E) và cắt ngang là rất cần thiết để củng cố các chức năng đã được phân chia cho các nhóm lẻ, và để kiểm tra các giao diện phức tạp trong các hệ thống cũ, việc này thường mất nhiều thời gian hơn so với độ dài của một Sprint.

Cuối cùng, một bộ phận quản lí chương trình Agile (PMO) nên được hình thành để giải quyết các vấn đề nhanh hơn và đưa ra các quyết định liên nhóm.

Quy trình triển khai Agile trong ERP

Áp dụng Agile vào cách tiếp cận truyền thống

Theo cách tiếp cận truyền thống, việc triển khai ERP có bốn giai đoạn: phát triển chiến lược, xây dựng lộ trình, thiết lập chương trình, triển khai và tiến hành sử dụng (deployment). Mỗi giai đoạn có thể ứng dụng Agile.

Phát triển một chiến lược ERP và xây dựng lộ trình với các nguyên lí, tình huống kinh doanh để thực hiện một giải pháp mới. Giai đoạn này vẫn không thay đổi nhiều, nhưng có thể được tăng tốc bằng cách phân tích những khoảng cách phù hợp (fit-gap) ở cấp độ cao hơn là những kế hoạch chi tiết, và chia nhỏ thành các sprint để tránh sa đà vào các tình huống kinh doanh cụ thể. Chủ sở hữu sản phẩm (Product owner) có thể được trao quyền để đưa ra các quyết định quan trọng từ đầu, và các nhóm liên chức năng nhỏ hơn nên được hình thành để cùng đạt được mục tiêu của chương trình.

Thiết lập chương trình thay đổi đáng kể theo cách tiếp cần Agile, nhanh hơn nhiều, chủ yếu là do các đội được trao quyền để nhanh chóng giải quyết các vấn đề khó khăn thực tế thay vì tập trung vào thiết kế lí thuyết, Giai đoạn này bao gồm việc nhanh chóng lựa chọn đối tác có kinh nghiệm với giải pháp, và agile, trái ngược với việc tham gia vào quá trình xây dựng một bản đề xuất dài cho nỗ lực tìm kiếm nhà cung cấp, và thương lượng với một giá trị hợp đồng cố định, xây dựng sản phẩm hoàn hảo, bản lộ trình các tính năng vĩ mô, dựa trên danh sách các cải tiến đã xác định, đủ chi tiết để xác định quy mô và hình thái của tổ chức linh hoạt cần để làm được chương trình, đào tạo nhân sự trong tổ chức theo cách thức làm việc linh hoạt, và xây dựng một PMO đủ mạnh để điều phối các luồng công việc chức năng và không chức năng.

Thực hiện giải pháp là khác biệt đáng kể theo cách tiếp cận Agile. Việc thực thi có thể diễn ra theo một số cách để nhanh chóng tạo nên giá trị. Các nhóm phân phối chứng năng thực hành Scrum theo cách điển hình. Các nhóm cộng tác từ đầu đến cuối gồm tám đến mười thành viên, bao gồm cả kinh doanh, IT và tích hợp hệ thống, thiết kế, phát triển và thử nghiệm hệ thống theo Sprint từ hai đến ba tuần. E2E kiểm thử và thử nghiệm người dùng (UAT) được thực hiện thường xuyên thay vì chỉ diễn ra một lần khi kết thúc quá trình phát triển, dẫn đến việc chất lượng code tốt hơn, tự động hoá thử nghiệm liên tục.

Các công việc không chức năng (ví dụ, di chuyển dữ liệu, đào tạo và tiến hành sử dụng) ít bị ảnh hưởng bởi cách tiếp cận Agile, mặc dù cần có sự phối hợp chặt chẽ giữa các nhóm chức năng và không chức năng, ví dụ, bởi vì dữ liệu cần có sớm để thực hiện kiểm thử chức năng, nhóm di chuyển dữ liệu cần phải thu thập thông tin để sẵn sàng trong môi trường test. Kiểm tra không chức năng và giai đoạn cắt ngang vẫn giống như cách thức triển khai truyền thống.

Ví dụ, một công ty thực hiện chuyển đổi tổ chức thành 26 nhóm. Trong đó, 11 nhóm là nhóm agile liên chức năng cung cấp các tính năng, 15 nhóm khác là nhóm chuyển đổi hỗ trợ các nhóm Agile. Tất cả các nhóm Agile đều có những năng lực cần thiết để cung cấp giải pháp từ đầu tới cuối, bao gồm cả đại diện kinh doanh.

Triển khai giải pháp phần lớn tuân theo cách tiếp cận truyền thống. Tuy nhiên, quá trình triển khai diễn ra thường xuyên hơn và thực hành agile có thể giúp loại bỏ các nút thắt cổ chai. Việc triển khai theo hướng Agile có thể giảm thiểu các rủi ro sớm, các nhà phân tích có thể nhanh chóng tối ưu hoá các quy trình (ví dụ, số lượng người dùng chính được đào tạo) và các biểu mẫu được thiết kế sớm để đào tạo người dùng. Một giai đoạn hypercare ngắn có thể được lập kế hoạch từ trước vì liên tục tập trung vào chất lượng. Vì các đợt phát hành thường xuyên được diễn ra theo cách tiếp cận Agile, các bước trong quá trình triển khai có thể nhanh chóng được công nghiệp hoá.

Điều quan trọng cần lưu ý, trong quá trình triển khai thích nghi agile, các giai đoạn ban đầu được thực hiện nhanh chóng hơn so với phương pháp truyền thống. Hầu hết thời gian đều dành cho các giai đoạn sau, tập trung vào việc cung cấp các tính năng.

Lợi ích của việc thích ứng nhanh với ERP

Agile trở nên phổ biến do kết quả mà nó đem lại. Các nghiên cứu cho thấy, các tổ chức agile có 70% cơ hội nằm trong nhóm các tổ chức khoẻ mạnh, và có hiệu suất dài hạn tốt nhất. Hơn thế nữa, các công ty như vậy cũng lấy khách hàng làm trung tâm hơn, thời gian cung cấp sản phẩm ra thị trường nhanh hơn, lợi nhuận cao hơn, chi phí thấp hơn, và động lực làm việc cao hơn.

Cụ thể, đối với việc triển khai ERP, quá trình triển khai ERP theo cách Agile không phân biệt công nghệ, mà mang lại một loạt các lợi ích cả hữu hình và vô hình (Hình 2)

• Giảm 10% chi phí sản xuất chương trình, chủ yếu do ít phải làm lại trong các giai đoạn thử nghiệm và UAT của E2E
• Tăng giá trị chương trình lên 20% thông qua việc cho chủ sở hữu có cơ hội đủ để theo dõi tiến trình của dự án, tập trung vào các phần có giá trị cao
• Có thể thực hiện nhiều công việc hơn gấp ba lần vào một khoảng thời gian nhất định thông qua sự hợp tác của các nhóm chức năng
• Nhiều người dùng cuối chấp nhận sản phẩm hơn vì họ có tham gia trong suốt quá trình thực hiện
• Tinh thần đồng đội được cải thiện, khi họ thấy được tiến độ mỗi ngày

Lập kế hoạch chuyển đổi nguồn lực luôn luôn là công việc thách thức, nhưng những thách thức này có thể được giải quyết phần nào thông qua cách tiếp cận agile

• Tăng khối lượng công việc hoàn thành trong cùng một thời điểm
• Nhiều người dùng chấp nhận giải pháp hơn
• Cải thiện tinh thần đồng đội
• Tăng giá trị của chương trình
• Giảm chi phí sản xuất chương trình

Mặc dù hệ thống ERP thường được coi là “một ác quỷ thiết yếu”, nhưng hệ thống ấy vẫn ở đây, và các tổ chức không thể bỏ qua trong quá trình chuyển đổi số. Cách tiếp cận truyền thống thường biến quá trình chuyển đổi ERP trở nên phức tạp, do đó, cần thay đổi và thích ứng với các nguyên lí agile.

Các doanh nghiệp và các nhà tích hợp hệ thống thay vì cho những lầm tưởng rằng agile không thể áp dụng cho ERP, hãy nhanh chóng thực hiện cách tiếp cận agile để chuyển đổi ERP. Theo đó, các giải phảp ERP sẽ khiến việc triển khai được thực hiện theo từng giai đoạn, với kết quả là chi phó thấp hơn, và giá trị mang lại cao hơn.

Chuyển đổi ERP luôn luôn là thách thức, nhưng có thể giảm bớt phần nào với cách tiếp cận Agile.

Lợi ích của ERP

Chương trình Tư vấn & Huấn luyện Agile cho doanh nghiệp