Tháng thứ 9 của dự án, requirement đã chốt, solution design đã duyệt, dev đang chạy full sprint, mọi thứ đi đúng lộ trình, rồi vendor publish roadmap, và trong danh sách tính năng mới có một feature standard làm y chang cái mà team đã bỏ mấy tháng thiết kế custom. Cả phòng im lặng, rồi ai đó hỏi, vậy giờ làm sao?
Mình đã ngồi đúng khoảnh khắc đó hai lần. Lần đầu mình im, vì chưa biết nên nói gì, lần thứ hai mình mở miệng, không phải để trả lời mà để hỏi.
không phải kế hoạch dở, mà là bản chất của cloud ERP#
Hồi on-premise, bạn mua version 10.2, triển khai version 10.2, go-live version 10.2, platform đứng yên cả năm. Cloud ERP thì khác, Oracle, SAP, Workday, IFS release 2-4 phiên bản mỗi năm, tính năng mới ra liên tục, có thứ team thiết kế custom 6 tháng trước thì giờ vendor đã gói thành standard, test sẵn, document sẵn, có sẵn cả upgrade path. Đây không phải bug, nó là hệ quả tất yếu khi triển khai trên một nền tảng liên tục tiến hóa, có điều nó đặt lên bàn steering committee một bài toán đau thật, tiếp tục build custom, dừng lại đợi standard, hay đi đường hybrid.
phản xạ đầu tiên luôn là làm tiếp đi#
Tâm lý này dễ hiểu, team đã bỏ công mấy tháng, sponsor đã cam kết deadline, đổi hướng giữa chừng nhìn giống thất bại. Nhưng nó không phải thất bại, nó là governance có kỷ luật.
Bài báo trên ERP Today tuần này của Gina, một chuyên gia từng làm ở Deloitte, EY, Accenture, tả rất đúng cảnh hai phe trong steering committee cãi nhau, phe một bảo làm tiếp đi sắp xong rồi, phe hai hỏi nếu vendor sắp có standard thì build làm gì cái mà go-live xong lại phải retire. Cả hai đều có lý, nhưng trước khi đứng về phe nào thì cần dữ liệu chứ không phải ý kiến.
năm câu hỏi trước khi quyết#
Tác giả đưa ra một khung đánh giá khá thực dụng, không phải slide đẹp, mà là mấy câu BA và PM có thể mang thẳng lên steering committee.
Câu đầu là phần nào của customization thật sự trùng với standard. Đừng nhìn tổng thể, mổ ra từng module, từng function, có khi 70% trùng nhưng 30% còn lại là thứ chỉ business của mình mới có, standard không làm được.
Câu thứ hai là chi phí thật của việc làm tiếp là bao nhiêu, không chỉ tiền dev mà cả maintain, upgrade, test hồi quy mỗi lần vendor release, có những customization hôm nay build 2 tháng nhưng nuôi nó mất 5 năm.
Câu thứ ba là dừng lại thì vận hành bị ảnh hưởng thế nào, ai bị đứt process, có workaround tạm được không hay user đứng hình, câu này phải hỏi thẳng người dùng cuối chứ không đoán trong phòng họp.
Câu thứ tư là bao lâu nữa standard feature đó mới có thật. Vendor nói upcoming release, nhưng release nào, tháng sau, quý sau, hay chỉ là nằm trên roadmap mơ hồ, phải verify với account manager, đừng tin slide marketing.
Câu cuối là quyết định nào tạo giá trị dài hạn nhất, không phải cái nào giữ được schedule hay giữ được sunk cost, mà là cái nào để ba năm nữa nhìn lại mình không thấy hối hận.
ba con đường và cái giá của từng đường#
Bài báo tả ba kịch bản dựa trên những pattern lặp lại ở nhiều dự án ERP lớn, không gắn với khách hàng cụ thể nào, nhưng ai làm ERP lâu chắc sẽ thấy quen.
Đường thứ nhất là làm tiếp custom và go-live đúng hạn, lựa chọn phổ biến nhất, schedule không xáo trộn, stakeholder không phải họp lại, ai cũng thở phào. Vấn đề tới sau go-live, khi vendor ra standard feature thì tổ chức lại phải chạy một mini-project, evaluate, retire, replace, test, retrain, cái custom build với tâm thế tạm thời giờ đã thành production, và cắt nó đi tốn gần bằng lúc build. Một tổ chức trong bài chọn đường này nhưng khác ở chỗ trước khi team implementation giải tán, họ đã lên sẵn post-go-live roadmap để retire custom và chuyển sang standard, funding được duyệt ngay, ownership được giao rõ, nên chuyện chuyển đổi sau này là chủ động chứ không phải chữa cháy.
Đường thứ hai là dừng hẳn để đợi standard, quyết định khó nói nhất trong phòng họp, mấy tháng công sức coi như write-off, timeline dời vài tuần, sponsor hỏi vậy team làm gì mấy tháng qua. Nhưng khi phần trùng giữa custom và standard lớn, đây thường lại là quyết định khôn nhất về dài hạn, chi phí hôm nay có khi chỉ bằng chi phí maintain 3-5 năm, chưa kể giảm technical debt và rủi ro upgrade. Tác giả có một câu mình rất tâm đắc: câu hỏi không phải là đã bỏ bao nhiêu tiền, mà là nếu biết những gì mình biết hôm nay, mình có làm cái custom đó không.
Đường thứ ba là hybrid, làm tối thiểu rồi hoãn phần còn lại, và đây là đường dễ bị bỏ qua nhất. Thay vì chọn trắng đen thì hỏi một câu khác, minimum capability nào đủ để business vận hành lúc go-live, team chỉ build đúng những gì user cần cho ngày đầu tiên, phần còn lại để sau, tới lúc vendor ra standard thì chuyển dễ hơn nhiều vì cái interim solution vốn được thiết kế với tâm thế nó sẽ biến mất. Không phải dự án nào cũng hợp hybrid, nhưng mình thấy nhiều team bỏ qua lựa chọn này chỉ vì chưa ai nghĩ tới.
thứ quan trọng hơn cả quyết định#
Ba tổ chức trong bài chọn ba con đường khác nhau, nhưng có chung một điểm là không ai phản ứng bốc đồng, họ dừng lại, đánh giá, quyết dựa trên dữ liệu, không để áp lực schedule ép mình vào ngõ cụt. Mình từng viết về nợ quyết định, thứ nguy hiểm hơn technical debt, mà quyết vội cũng là một kiểu nợ khác, giống bốc thuốc không bắt mạch, triệu chứng hết mà bệnh vẫn còn, và trong ERP bệnh không chữa kịp thì vài năm sau nằm luôn trong danh sách dự án thất bại.
Nên nếu sáng mai vendor của bạn publish roadmap mới, câu hỏi thật không phải bạn sẽ chọn đường nào, mà là governance model của bạn có đủ nhanh để phản ứng không. Steering committee có ai lo theo dõi vendor roadmap không, có process escalation khi phát hiện standard feature trùng với customization đang build không, hay mọi thứ trông vào việc PM thấy thì báo? Những tổ chức qua được mấy khúc cua kiểu này không phải vì đoán giỏi, mà vì họ có cơ chế để biết và có kỷ luật để làm. Bạn đã có cơ chế đó chưa?
