Dự án chuyển đổi số đúng tiến độ nhưng doanh nghiệp không thay đổi: Vì sao?

Bảng tiến độ xanh và công việc vẫn như cũ

Hệ thống đã cài đặt, người dùng đã được cấp tài khoản, biên bản nghiệm thu đã ký. Nhưng khi cần tổng hợp đơn hàng, nhân viên vẫn gửi bảng tính qua email và quản lý vẫn gọi điện để hỏi trạng thái. Khoảng cách này cho thấy dự án có thể hoàn thành sản phẩm kỹ thuật trong khi cách vận hành chưa chuyển sang trạng thái mong muốn.

Tiến độ là một phần quan trọng của quản lý dự án. Tuy nhiên, nếu mục tiêu đầu tư là giảm chờ đợi, tăng chất lượng hoặc cải thiện trải nghiệm khách hàng, việc bàn giao đúng ngày cần được nối với thay đổi công việc. Một lịch triển khai tốt không tự tạo quyền quyết định mới, dữ liệu đáng tin hay động lực sử dụng hệ thống.

Lãnh đạo cần xem lại câu hỏi đã dùng để định nghĩa thành công. Nếu chỉ hỏi phần mềm có đủ chức năng không, dự án sẽ ưu tiên chứng minh chức năng. Nếu hỏi quy trình nào sẽ thay đổi và ai chịu trách nhiệm cho kết quả đó, kế hoạch phải bao gồm nghiệp vụ, con người và vận hành. Đây là năng lực được phát triển trong chương trình quản lý dự án IT, với trách nhiệm vượt qua việc theo dõi lịch.

Phân biệt sản phẩm bàn giao, thay đổi và lợi ích

Sản phẩm bàn giao là thứ dự án tạo ra: hệ thống, cấu hình, dữ liệu đã chuyển, quy trình được phê duyệt hoặc tài liệu đào tạo. Thay đổi là việc những sản phẩm đó được sử dụng để làm công việc theo cách mới. Lợi ích là cải thiện có ý nghĩa với doanh nghiệp, được xác nhận qua phương pháp đo phù hợp.

Ba lớp này có quan hệ nhưng không đồng nhất. Có tài liệu quy trình chưa chứng minh nhân viên làm đúng quy trình; có người đăng nhập chưa chứng minh công việc được hoàn tất trên hệ thống. Khi báo cáo chỉ dừng ở lớp đầu, Ban điều hành thiếu thông tin để biết đầu tư đã đi vào hoạt động như thế nào.

APM đặt quản lý lợi ích trong mối liên hệ giữa đầu ra, kết quả và giá trị được thực hiện. Với doanh nghiệp, có thể áp dụng bằng một chuỗi đơn giản: sản phẩm nào tạo khả năng mới, hành vi hoặc quy trình nào phải đổi, chỉ số nào cho thấy cải thiện và ai xác nhận. Chuỗi cần có bằng chứng tại từng bước, thay vì một mũi tên suy đoán từ cài đặt phần mềm đến tiết kiệm.

Bốn điểm khiến thay đổi bị đứt đoạn

Điểm đầu là thiết kế giải pháp mà chưa thống nhất công việc mới. Hệ thống có thể cho phép phê duyệt trực tuyến, nhưng quy định nội bộ vẫn yêu cầu bản giấy. Nhân viên phải thực hiện cả hai cách, làm tăng công sức. Cần xác định quy tắc nào được thay thế, quy tắc nào còn cần và ai có quyền chốt điều chỉnh.

Điểm thứ hai là thiếu chủ kết quả nghiệp vụ. IT có thể giữ hệ thống hoạt động, nhưng không thể tự quyết thời hạn xử lý của phòng kinh doanh hoặc trách nhiệm cập nhật dữ liệu của chi nhánh. Nếu chủ quy trình không nhận trách nhiệm, những thay đổi này dễ bị xem là việc riêng của dự án.

Điểm thứ ba là đào tạo xa nhiệm vụ thật. Buổi giới thiệu menu không giúp người dùng xử lý đơn thiếu thông tin, khách hàng trùng hồ sơ hoặc yêu cầu bị trả lại. Người dùng cần thực hành cả luồng thường và ngoại lệ, biết nơi nhận hỗ trợ và được bố trí thời gian chuyển đổi.

Điểm thứ tư là bàn giao không có giai đoạn ổn định. Khi đội dự án rời đi ngay sau go-live, lỗi quy trình, dữ liệu và quyền truy cập có thể không có người xử lý. Cách tổ chức hỗ trợ trong chương trình quản lý dịch vụ IT giúp nối bàn giao dự án với khả năng duy trì công việc mới.

Chẩn đoán bằng bằng chứng công việc

Đừng bắt đầu bằng kết luận nhân viên chống đối. Quan sát một giao dịch từ khi tiếp nhận đến khi hoàn tất, ghi nơi dữ liệu được tạo, chuyển, sửa và phê duyệt. Tìm các bước vẫn chạy ngoài hệ thống và hỏi lý do. Một bảng tính có thể là công cụ bổ trợ hợp lý hoặc dấu hiệu chức năng, dữ liệu hay quyền chưa đáp ứng.

Phỏng vấn người thực hiện, quản lý trực tiếp và người nhận đầu ra. So sánh lời mô tả với hồ sơ và thao tác thực tế. Nếu người dùng nói hệ thống chậm, cần xác định chậm ở thời gian phản hồi, thao tác nhập liệu hay chờ người phê duyệt; mỗi nguyên nhân đòi hỏi cách xử lý khác nhau.

Kết quả chẩn đoán nên tạo danh sách điều kiện chưa đủ, không chỉ danh sách lỗi phần mềm. Mỗi điều kiện cần chủ xử lý, hành động và bằng chứng hoàn thành. Điều này giúp Ban điều hành quyết định đúng việc cần tháo gỡ thay vì yêu cầu nhà cung cấp thêm chức năng cho mọi vấn đề.

Khôi phục trách nhiệm cho thay đổi nghiệp vụ

Nhà bảo trợ cần xác nhận lại lý do đầu tư và kết quả ưu tiên. Chủ quy trình nhận trách nhiệm cho cách vận hành mới, còn quản lý dự án phối hợp các đầu việc để tạo điều kiện. IT, nhân sự, tài chính và các đơn vị liên quan tham gia theo quyền chuyên môn của mình; không nên gom mọi trách nhiệm vào một chức danh chung.

Thiết lập kế hoạch phục hồi theo phạm vi nhỏ có thể kiểm chứng. Chọn một luồng công việc, thống nhất quy tắc, sửa dữ liệu và quyền, đào tạo theo nhiệm vụ rồi theo dõi. Chỉ mở rộng khi thấy luồng mới hoạt động và đội hỗ trợ có khả năng duy trì. Tránh tái khởi động bằng một kế hoạch lớn thiếu điều kiện đầu vào.

Các thay đổi về chỉ tiêu hoặc cơ chế quản lý cần được lãnh đạo nghiệp vụ chốt. Nếu nhân viên vẫn bị đánh giá theo cách cũ, hệ thống mới khó trở thành công cụ làm việc chính. Tư duy của chương trình chuyển đổi số giúp kết nối công nghệ với quy trình và hành vi trong tổ chức.

Đo kết quả sau go-live mà không suy diễn

Chọn chỉ số theo vấn đề ban đầu, có đường cơ sở và phạm vi đo. Với xử lý đơn hàng, có thể xem thời gian từ nhận yêu cầu hợp lệ đến xác nhận, tỷ lệ phải làm lại và số trường hợp quá hạn. Tỷ lệ sử dụng hệ thống là tín hiệu về chuyển đổi công việc, nhưng cần đối chiếu với chất lượng và kết quả.

Ghi rõ nguồn dữ liệu, thời gian quan sát và những thay đổi khác có thể ảnh hưởng. Nếu khối lượng hoặc độ khó giao dịch thay đổi, không nên so sánh các con số tổng mà không giải thích. Người chủ lợi ích cùng bộ phận liên quan cần xác nhận cách tính và ý nghĩa kết quả.

Tách năng lực được giải phóng khỏi tiền tiết kiệm. Công việc nhanh hơn có thể giúp xử lý thêm yêu cầu hoặc giảm áp lực, nhưng không mặc nhiên làm giảm chi phí. Lợi ích tài chính chỉ nên được ghi nhận khi có cơ chế thực hiện và bằng chứng phù hợp. Báo cáo trung thực giúp lãnh đạo chọn bước tiếp theo dựa trên giá trị thực.

Tình huống giả định: Quy trình đặt hàng vẫn dùng email

Một doanh nghiệp giả định triển khai hệ thống quản lý đơn hàng đúng lịch. Nhân viên nhập dữ liệu cuối ngày nhưng vẫn xin phê duyệt qua email vì hạn mức và người thay thế chưa được thiết lập. Quản lý tiếp tục dùng bảng tính để tổng hợp, khiến hệ thống trở thành nơi lưu dữ liệu sau sự kiện.

Đội dự án ban đầu đề xuất thêm báo cáo. Sau khi quan sát giao dịch, họ nhận ra điểm nghẽn nằm ở quy tắc phê duyệt và trách nhiệm cập nhật. Nhà bảo trợ yêu cầu chủ quy trình chốt hạn mức, người thay thế, điều kiện yêu cầu hợp lệ và cách xử lý ngoại lệ. IT cấu hình theo các quyết định đã được phê duyệt.

Nhóm thí điểm thực hành trên giao dịch điển hình, được hỗ trợ và ghi nhận lỗi. Doanh nghiệp theo dõi luồng công việc mới trước khi quyết định mở rộng. Kết quả kỳ vọng là dữ liệu được tạo trong quá trình xử lý và quản lý có thể sử dụng trạng thái đáng tin; chưa tuyên bố lợi ích cho đến khi có bằng chứng đối chiếu.

Đưa báo cáo dự án về đúng quyết định

Một báo cáo hữu ích cần trình bày ba phần: sản phẩm đã bàn giao, mức độ sẵn sàng của cách vận hành mới và lợi ích đang được kiểm chứng. Các vấn đề cần quyết định phải ghi phương án, tác động, người chốt và thời điểm cần chốt. Ban điều hành không nên nhận một danh sách màu xanh che khuất những điều kiện chưa đáp ứng.

Quản lý dự án cần có quyền báo cáo khác biệt giữa hoàn thành kỹ thuật và sẵn sàng nghiệp vụ. Năng lực phối hợp và trình bày quyết định trong chương trình lãnh đạo IT hỗ trợ trao đổi với chủ nghiệp vụ mà vẫn giữ rõ trách nhiệm của từng bên. Khi phạm vi lợi ích thay đổi, phải cập nhật căn cứ đầu tư và kế hoạch tương ứng.

• Sản phẩm đã được chấp nhận theo tiêu chí nào?
• Người thực hiện có đủ dữ liệu, quyền và hướng dẫn cho công việc mới chưa?
• Chủ quy trình có nhận trách nhiệm duy trì và xử lý ngoại lệ không?
• Chỉ số kết quả có đường cơ sở và người xác nhận không?
• Các điều kiện còn thiếu có chủ xử lý và mốc kiểm tra không?

Dự án đúng tiến độ tạo nền tảng cần thiết, nhưng thay đổi doanh nghiệp còn phụ thuộc vào việc nền tảng đó được sử dụng trong công việc. Bước nên làm ngay là kiểm tra một luồng nghiệp vụ, nối sản phẩm bàn giao với trách nhiệm và bằng chứng kết quả, rồi quyết định những điều kiện cần hoàn thiện trước khi tiếp tục mở rộng.

Bài viết liên quan

• Chuyển mục tiêu chuyển đổi số thành phạm vi, sản phẩm bàn giao và kết quả dự án.
• Xây dựng Project Charter cho dự án chuyển đổi số: Những nội dung không thể bỏ qua.
• Đánh giá hiện trạng quy trình AS-IS và thiết kế quy trình TO-BE trước khi triển khai giải pháp.
• Quản lý yêu cầu nghiệp vụ: Làm thế nào để IT hiểu đúng vấn đề của các phòng ban?

Nguồn tham khảo

1. APM – Benefits management and project success
2. APM – Change management and organisational change
3. APM – What is governance?