Các sai lầm khiến dự án chuyển đổi số thất bại

Vì tác động đồng thời đến chiến lược, công nghệ, con người và mô hình quản trị, chuyển đổi số có tỷ lệ thất bại tương đối cao. Nghiên cứu của BCG cho thấy chỉ khoảng 30% chương trình chuyển đổi số đạt hoặc vượt mục tiêu và tạo ra thay đổi bền vững. Một nghiên cứu khác của BCG về các chương trình công nghệ quy mô lớn cho thấy hơn hai phần ba dự án không được kỳ vọng hoàn thành đồng thời đúng thời gian, ngân sách và phạm vi đã xác định.

Điều quan trọng là “thất bại” không phải lúc nào cũng đồng nghĩa với hệ thống ngừng hoạt động. Một dự án vẫn có thể nghiệm thu kỹ thuật nhưng thất bại về kinh doanh khi nhân viên không sử dụng, quy trình không cải thiện, dữ liệu không đáng tin cậy hoặc lợi ích tạo ra thấp hơn chi phí đầu tư.

Không xác định rõ vấn đề kinh doanh cần giải quyết

Sai lầm nền tảng nhất là bắt đầu dự án bằng câu hỏi “nên triển khai công nghệ nào?” thay vì “vấn đề kinh doanh nào cần được giải quyết?”.

Khi mục tiêu chỉ được mô tả bằng những cụm từ chung như “hiện đại hóa”, “ứng dụng AI”, “xây dựng doanh nghiệp số” hoặc “nâng cao trải nghiệm khách hàng”, đội dự án không có cơ sở để:

·         Ưu tiên phạm vi đầu tư

·         Lựa chọn giải pháp phù hợp

·         Đánh giá tính khả thi

·         Đo lường giá trị tạo ra

·         Quyết định hạng mục nào nên dừng

Một dự án quản trị quan hệ khách hàng, chẳng hạn, có thể được nghiệm thu đầy đủ về chức năng nhưng vẫn không tạo ra kết quả nếu doanh nghiệp chưa xác định rõ cần giảm thời gian phản hồi, tăng tỷ lệ chuyển đổi, hạn chế khách hàng rời bỏ hay chuẩn hóa hoạt động bán hàng.

Cơ chế thất bại thường diễn ra theo chuỗi:

Mục tiêu mơ hồ → yêu cầu thay đổi liên tục → phạm vi mở rộng → chi phí tăng → tiến độ kéo dài → lợi ích không thể chứng minh.

McKinsey xác định việc thiếu sự rõ ràng hoặc thiếu đồng thuận về chiến lược số là một trong những nguyên nhân phổ biến khiến chương trình chuyển đổi bị đình trệ.

Trước khi phê duyệt dự án, tổ chức cần chuyển mục tiêu chiến lược thành một tập hợp kết quả có thể kiểm chứng, chẳng hạn:

·         Rút ngắn thời gian xử lý đơn hàng từ 24 giờ xuống 8 giờ

·         Giảm tỷ lệ nhập liệu thủ công

·         Tăng tỷ lệ hồ sơ được xử lý ngay từ lần đầu

·         Giảm thời gian lập báo cáo quản trị

·         Tăng tỷ lệ người dùng hoàn thành giao dịch trên kênh số

·         Giảm chi phí vận hành trên mỗi giao dịch

Công nghệ chỉ nên được lựa chọn sau khi tổ chức đã xác định rõ kết quả cần đạt, nhóm người hưởng lợi và chỉ số dùng để đo lường.

Xem chuyển đổi số như một dự án công nghệ thông tin

Một sai lầm phổ biến khác là giao toàn bộ trách nhiệm cho bộ phận công nghệ thông tin. Cách tiếp cận này khiến dự án tập trung vào hệ thống, tích hợp và tính năng, trong khi những yếu tố quyết định giá trị lại nằm ở quy trình, chính sách, trách nhiệm và hành vi của các đơn vị nghiệp vụ.

Bộ phận công nghệ có thể xây dựng một nền tảng đúng yêu cầu kỹ thuật, nhưng không thể tự quyết định:

·         Quy trình nghiệp vụ nào phải được thay đổi

·         Công đoạn nào cần loại bỏ

·         Quyền ra quyết định phải được phân bổ lại như thế nào

·         Chỉ tiêu của nhân viên cần điều chỉnh ra sao

·         Đơn vị nào chịu trách nhiệm về dữ liệu

·         Trải nghiệm khách hàng mục tiêu là gì

Nếu lãnh đạo nghiệp vụ chỉ xuất hiện trong các buổi phê duyệt, còn đội công nghệ phải tự diễn giải nhu cầu, hệ thống được tạo ra thường chỉ số hóa cách làm cũ.

Hệ quả là doanh nghiệp có thêm phần mềm nhưng không có năng lực vận hành mới. Nhân viên nhập dữ liệu vào hệ thống rồi tiếp tục xử lý bằng bảng tính, email hoặc giấy tờ. Khách hàng có thêm kênh số nhưng vẫn phải thực hiện lại các bước ngoại tuyến.

Chuyển đổi số cần được quản trị như một chương trình thay đổi kinh doanh có cấu phần công nghệ, không phải một dự án công nghệ có thêm yêu cầu nghiệp vụ. Người chịu trách nhiệm cuối cùng phải là lãnh đạo có quyền điều phối ngân sách, quy trình, nhân sự và các đơn vị liên quan.

Thiếu cam kết thực chất từ lãnh đạo

Nhiều lãnh đạo tuyên bố ủng hộ chuyển đổi số nhưng không tham gia vào những quyết định khó khăn của chương trình. Họ phê duyệt ngân sách nhưng không giải quyết xung đột giữa các phòng ban, không điều chỉnh cơ chế đánh giá và không chịu trách nhiệm về kết quả sử dụng.

Cam kết lãnh đạo chỉ có ý nghĩa khi được thể hiện qua hành động:

·         Đặt ra ưu tiên rõ ràng

·         Phân bổ đủ nguồn lực

·         Quyết định khi các đơn vị xung đột lợi ích

·         Theo dõi kết quả kinh doanh thay vì chỉ theo dõi tiến độ kỹ thuật

·         Yêu cầu quản lý cấp trung thay đổi cách vận hành

·         Trực tiếp truyền đạt lý do và mức độ cấp thiết của thay đổi

Khi thiếu nhà bảo trợ có thẩm quyền, các đơn vị thường tối ưu lợi ích riêng. Phòng bán hàng muốn giữ quy trình linh hoạt, tài chính muốn tăng kiểm soát, vận hành muốn giảm gián đoạn, còn công nghệ muốn hạn chế tùy chỉnh. Không ai có đủ quyền để đưa ra quyết định chung, khiến dự án liên tục trì hoãn hoặc thỏa hiệp bằng một thiết kế phức tạp.

Dữ liệu của Prosci cho thấy các dự án có nhà bảo trợ cực kỳ hiệu quả đạt mục tiêu với tỷ lệ 79%, so với 27% ở nhóm có nhà bảo trợ cực kỳ kém hiệu quả.

Tuy nhiên, sự hiện diện thường xuyên của lãnh đạo không thể bù đắp cho chiến lược sai hoặc giải pháp kém phù hợp. Vai trò của lãnh đạo là tạo định hướng, tháo gỡ rào cản và buộc tổ chức chịu trách nhiệm, không phải can thiệp vào mọi quyết định kỹ thuật.

Số hóa quy trình kém hiệu quả thay vì tái thiết quy trình

Tự động hóa một quy trình không hợp lý chỉ làm cho sai sót xảy ra nhanh hơn và trên quy mô lớn hơn.

Trước khi triển khai hệ thống, doanh nghiệp thường yêu cầu nhà cung cấp mô phỏng toàn bộ quy trình hiện tại. Các bước phê duyệt, biểu mẫu, trường dữ liệu và ngoại lệ được đưa nguyên trạng vào phần mềm vì tổ chức lo ngại thay đổi sẽ gây xáo trộn.

Cách làm này dẫn đến ba vấn đề:

·         Hệ thống bị tùy chỉnh quá mức

·         Quy trình số vẫn nhiều bước và khó sử dụng

·         Chi phí bảo trì, tích hợp và nâng cấp tăng cao

Một quy trình tồn tại lâu năm không có nghĩa là mọi bước trong đó đều tạo ra giá trị. Một số bước chỉ xuất hiện vì hạn chế của hệ thống cũ, thiếu dữ liệu hoặc cơ chế kiểm soát đã lỗi thời.

Trước khi số hóa, đội dự án cần phân tích:

·         Bước nào trực tiếp tạo giá trị

·         Bước nào chỉ chuyển tiếp thông tin

·         Dữ liệu nào đang bị nhập lại

·         Phê duyệt nào thực sự kiểm soát rủi ro

·         Trường hợp ngoại lệ nào xảy ra đủ thường xuyên để đưa vào hệ thống

·         Công việc nào có thể loại bỏ thay vì tự động hóa

Nguyên tắc cần tuân thủ là đơn giản hóa trước, chuẩn hóa sau đó và chỉ tự động hóa khi quy trình mục tiêu đã rõ ràng.

Không phải mọi quy trình đều cần thiết kế lại hoàn toàn. Với các quy trình chịu ràng buộc pháp lý hoặc kiểm soát rủi ro cao, một số bước bắt buộc phải được giữ lại. Vấn đề không nằm ở số lượng bước, mà ở việc mỗi bước có mục đích rõ ràng và tương xứng với rủi ro hay không.

Đầu tư dàn trải và cố gắng chuyển đổi mọi thứ cùng lúc

Chuyển đổi số thường thất bại khi tổ chức khởi động quá nhiều sáng kiến nhưng không đủ năng lực thực hiện đồng thời.

Danh mục dự án có thể bao gồm ERP, CRM, kho dữ liệu, ứng dụng khách hàng, tự động hóa, AI, nền tảng tích hợp và hạ tầng đám mây. Mỗi dự án đều có lý do riêng, nhưng tổng thể lại vượt quá khả năng cung cấp nhân sự, quản trị thay đổi và ra quyết định của tổ chức.

Đầu tư dàn trải tạo ra các hậu quả:

·         Nhân sự chủ chốt phải tham gia quá nhiều dự án

·         Các nhóm tranh chấp dữ liệu và nguồn lực

·         Hệ thống mới được xây dựng trên nền tảng chưa ổn định

·         Phụ thuộc giữa các dự án không được quản lý

·         Lợi ích bị chia nhỏ và khó quan sát

·         Ban lãnh đạo mất khả năng tập trung

Chuyển đổi quy mô lớn không nhất thiết phải được thực hiện bằng một lần triển khai lớn. Tổ chức nên xây dựng lộ trình theo các năng lực hoặc chuỗi giá trị có thể tạo kết quả độc lập.

Mỗi giai đoạn cần có:

·         Phạm vi đủ nhỏ để kiểm soát

·         Giá trị kinh doanh có thể đo lường

·         Người chịu trách nhiệm rõ ràng

·         Điều kiện dữ liệu và công nghệ đã sẵn sàng

·         Tiêu chí tiếp tục, điều chỉnh hoặc dừng

Thí điểm cũng không nên chỉ chứng minh rằng công nghệ hoạt động. Một thí điểm có giá trị phải kiểm chứng đồng thời tính hữu ích, mức độ chấp nhận của người dùng, khả năng vận hành và tiềm năng mở rộng.

Bỏ qua quản trị thay đổi và mức độ chấp nhận của người dùng

Một hệ thống chỉ tạo ra lợi ích khi người dùng áp dụng đúng và đủ. Vì vậy, nghiệm thu kỹ thuật không đồng nghĩa với chuyển đổi thành công.

Người dùng có thể phản đối hoặc né tránh hệ thống mới vì nhiều nguyên nhân:

·         Không hiểu lý do phải thay đổi

·         Lo ngại mất quyền kiểm soát hoặc vị trí

·         Quy trình mới làm tăng khối lượng công việc

·         Giao diện không phù hợp với công việc thực tế

·         Không được đào tạo đủ

·         Chỉ tiêu hiệu suất vẫn khuyến khích cách làm cũ

·         Quản lý trực tiếp không sử dụng hoặc không yêu cầu sử dụng

Khi đó, nhân viên có thể đăng nhập để đáp ứng yêu cầu nhưng vẫn duy trì quy trình song song bên ngoài hệ thống. Dữ liệu trở nên thiếu đầy đủ, báo cáo không đáng tin cậy và lãnh đạo kết luận rằng công nghệ không hiệu quả.

Nghiên cứu của Prosci cho thấy 88% dự án có chương trình quản trị thay đổi xuất sắc đạt hoặc vượt mục tiêu, trong khi tỷ lệ này chỉ là 13% ở các dự án có năng lực quản trị thay đổi kém.

Đào tạo chỉ là một phần của quản trị thay đổi. Một chương trình đầy đủ phải xử lý cả:

·         Nhận thức về lý do thay đổi

·         Mức độ sẵn sàng của từng nhóm người dùng

·         Tác động đến vai trò và trách nhiệm

·         Cơ chế phản hồi

·         Hỗ trợ sau triển khai

·         Hành vi của quản lý cấp trung

·         Chỉ số về mức độ sử dụng và mức độ thành thạo

Các chỉ số cần theo dõi không nên dừng ở số tài khoản được tạo hoặc số người hoàn thành khóa học. Tổ chức cần quan sát tần suất sử dụng, tỷ lệ hoàn thành quy trình trên hệ thống, tỷ lệ quay lại cách làm cũ, thời gian xử lý và chất lượng dữ liệu sau khi áp dụng.

Đánh giá thấp chất lượng và quyền sở hữu dữ liệu

Dữ liệu thường được xem là vấn đề kỹ thuật, nhưng phần lớn vấn đề dữ liệu lại bắt nguồn từ quản trị.

Khi triển khai hệ thống, doanh nghiệp có thể phát hiện:

·         Một khách hàng có nhiều mã định danh

·         Các đơn vị sử dụng định nghĩa chỉ tiêu khác nhau

·         Dữ liệu thiếu hoặc không được cập nhật

·         Không rõ ai có quyền sửa dữ liệu

·         Không có đơn vị chịu trách nhiệm về chất lượng

·         Dữ liệu không thể liên kết giữa các hệ thống

Nếu dữ liệu đầu vào không đáng tin cậy, tự động hóa và phân tích chỉ khuếch đại sai lệch. Báo cáo có thể được tạo nhanh hơn nhưng không hỗ trợ quyết định tốt hơn. Mô hình AI có thể xử lý lượng dữ liệu lớn nhưng kết quả vẫn thiếu giá trị nếu dữ liệu không đại diện hoặc không nhất quán.

Một sai lầm khác là cố gắng “làm sạch toàn bộ dữ liệu” trước khi triển khai. Mục tiêu này thường quá rộng và kéo dài. Doanh nghiệp nên ưu tiên các miền dữ liệu trực tiếp ảnh hưởng đến quy trình và kết quả của từng giai đoạn chuyển đổi.

Mỗi miền dữ liệu quan trọng cần xác định rõ:

·         Chủ sở hữu nghiệp vụ

·         Người quản trị dữ liệu

·         Định nghĩa thống nhất

·         Quy tắc kiểm tra chất lượng

·         Quyền truy cập và thay đổi

·         Chu kỳ cập nhật

·         Cơ chế xử lý sai lệch

Công cụ quản lý dữ liệu có thể phát hiện vấn đề, nhưng không thể tự quyết định định nghĩa nào là đúng hoặc đơn vị nào phải chịu trách nhiệm.

Chọn công nghệ trước khi xác định kiến trúc và năng lực cần thiết

Doanh nghiệp dễ bị thu hút bởi giải pháp đang phổ biến trên thị trường và bắt đầu bằng việc mua giấy phép. Sau đó, đội dự án mới tìm kiếm quy trình phù hợp để áp dụng công nghệ.

Cách tiếp cận này làm đảo ngược trình tự ra quyết định.

Một sản phẩm mạnh vẫn có thể trở thành lựa chọn sai khi:

·         Không phù hợp với quy mô tổ chức

·         Không tích hợp tốt với hệ thống hiện tại

·         Đòi hỏi năng lực vận hành mà doanh nghiệp chưa có

·         Chi phí tùy chỉnh và bảo trì quá lớn

·         Gây phụ thuộc quá mức vào nhà cung cấp

·         Không đáp ứng yêu cầu bảo mật hoặc quản trị dữ liệu

·         Không thể mở rộng theo lộ trình dài hạn

Đánh giá giải pháp không nên chỉ dựa trên số lượng tính năng. Tổ chức cần xem xét tổng chi phí sở hữu, độ phức tạp tích hợp, khả năng cấu hình, năng lực nội bộ cần bổ sung, tính di chuyển của dữ liệu và khả năng thay đổi trong tương lai.

Không phải doanh nghiệp nào cũng cần một kiến trúc hoàn toàn mới. Trong nhiều trường hợp, tái sử dụng có kiểm soát các hệ thống hiện có giúp giảm rủi ro. Tuy nhiên, việc giữ lại hệ thống cũ phải dựa trên đánh giá rõ ràng về khả năng tích hợp, chi phí vận hành và mức độ cản trở mục tiêu kinh doanh.

Tùy chỉnh hệ thống quá mức

Tùy chỉnh thường được sử dụng để giữ nguyên cách làm hiện tại. Mỗi phòng ban yêu cầu phần mềm phải phản ánh chính xác biểu mẫu, thuật ngữ, luồng phê duyệt và ngoại lệ riêng.

Ban đầu, các yêu cầu này có vẻ hợp lý. Nhưng khi tích lũy, chúng tạo ra một hệ thống khó kiểm thử, khó nâng cấp và phụ thuộc vào một nhóm chuyên gia nhỏ.

Tùy chỉnh quá mức thường gây:

·         Chi phí triển khai tăng

·         Thời gian kiểm thử kéo dài

·         Nhiều lỗi phát sinh khi nâng cấp

·         Khó áp dụng tính năng tiêu chuẩn mới

·         Phụ thuộc vào nhà triển khai

·         Quy trình giữa các đơn vị tiếp tục phân mảnh

Không phải mọi tùy chỉnh đều sai. Tùy chỉnh có thể cần thiết khi liên quan đến lợi thế cạnh tranh, yêu cầu pháp lý hoặc đặc thù vận hành không thể thay thế.

Trước mỗi yêu cầu tùy chỉnh, tổ chức nên kiểm tra:

1.    Yêu cầu này bảo vệ giá trị hoặc kiểm soát quan trọng nào?

2.    Có thể thay đổi quy trình để sử dụng chức năng tiêu chuẩn không?

3.    Lợi ích có lớn hơn chi phí bảo trì dài hạn không?

4.    Yêu cầu có phục vụ đa số người dùng hay chỉ một trường hợp hiếm?

5.    Ai sẽ chịu trách nhiệm khi hệ thống được nâng cấp?

Nguyên tắc mặc định nên là ưu tiên cấu hình và chuẩn hóa; chỉ tùy chỉnh khi có bằng chứng rõ ràng về giá trị.

Quản trị dự án theo tiến độ thay vì theo giá trị

Nhiều ban chỉ đạo nhận báo cáo định kỳ về tỷ lệ hoàn thành, số tính năng đã phát triển, số lỗi đã xử lý và tình trạng ngân sách. Những chỉ số này cần thiết nhưng không cho biết dự án có đang tạo ra giá trị hay không.

Một chương trình có thể hoàn thành 90% kế hoạch nhưng chưa kiểm chứng được:

·         Người dùng có chấp nhận quy trình mới không

·         Thời gian xử lý có giảm không

·         Chi phí vận hành có thay đổi không

·         Chất lượng quyết định có được cải thiện không

·         Khách hàng có nhận được trải nghiệm tốt hơn không

Khi nhóm dự án bị đánh giá chủ yếu bằng việc hoàn thành phạm vi, họ có động lực bàn giao tính năng thay vì giải quyết vấn đề. Những yêu cầu ít giá trị vẫn được thực hiện vì đã nằm trong kế hoạch, trong khi các vấn đề phát sinh từ thực tế sử dụng không được ưu tiên.

Quản trị theo giá trị yêu cầu liên kết bốn lớp chỉ số:

·         Chỉ số bàn giao: tiến độ, ngân sách, chất lượng kỹ thuật

·         Chỉ số sử dụng: tỷ lệ áp dụng, tần suất sử dụng, mức độ hoàn thành trên hệ thống

·         Chỉ số vận hành: thời gian chu kỳ, tỷ lệ lỗi, năng suất, chi phí

·         Chỉ số kinh doanh: doanh thu, lợi nhuận, khả năng giữ chân khách hàng hoặc mức độ phục vụ

Giá trị chuyển đổi thường xuất hiện sau khi hệ thống được đưa vào vận hành. Vì vậy, trách nhiệm của đội dự án không nên kết thúc ngay khi nghiệm thu.

Dự toán thiếu thực tế và bỏ qua chi phí sau triển khai

Ngân sách chuyển đổi số thường tập trung vào giấy phép và chi phí triển khai ban đầu nhưng bỏ sót:

·         Làm sạch và chuyển đổi dữ liệu

·         Tích hợp hệ thống

·         Kiểm thử

·         Đào tạo

·         Quản trị thay đổi

·         An toàn thông tin

·         Hỗ trợ sau triển khai

·         Vận hành hạ tầng

·         Nâng cấp và mở rộng

·         Chi phí cơ hội của nhân sự nghiệp vụ

McKinsey cho biết 70% chương trình chuyển đổi số trong lĩnh vực ngân hàng vượt ngân sách ban đầu và 7% có chi phí cuối cùng cao hơn gấp đôi dự toán. Nguồn này cũng lưu ý rằng ngân sách ban đầu thường không phản ánh đầy đủ độ phức tạp và các nguồn lực cần thiết.

Con số trên không nên được áp dụng như một tỷ lệ chung cho mọi ngành. Tuy nhiên, nó minh họa rủi ro của việc lập ngân sách dựa trên chi phí mua giải pháp thay vì tổng chi phí tạo ra và duy trì năng lực mới.

Dự toán cần được xây dựng theo toàn bộ vòng đời, đồng thời có khoản dự phòng gắn với các rủi ro đã nhận diện. Khi phạm vi thay đổi, tổ chức phải đánh giá lại lợi ích kỳ vọng thay vì chỉ tăng ngân sách để bảo vệ kế hoạch cũ.

Mở rộng quá sớm từ một thử nghiệm thành công

Một mô hình thử nghiệm có thể hoạt động tốt trong một đơn vị nhỏ nhưng thất bại khi triển khai toàn doanh nghiệp.

Thử nghiệm thường được thực hiện trong điều kiện thuận lợi:

·         Có đội ngũ hỗ trợ trực tiếp

·         Người dùng được lựa chọn kỹ

·         Dữ liệu tương đối sạch

·         Số lượng giao dịch thấp

·         Phạm vi tích hợp hạn chế

·         Ngoại lệ được xử lý thủ công

Khi mở rộng, hệ thống phải phục vụ nhiều nhóm người dùng, quy trình và mức chất lượng dữ liệu khác nhau. Những vấn đề chưa xuất hiện trong giai đoạn thử nghiệm bắt đầu trở thành điểm nghẽn.

Trước khi nhân rộng, đội dự án cần kiểm chứng:

·         Khả năng chịu tải

·         Mức độ chuẩn hóa quy trình

·         Năng lực hỗ trợ người dùng

·         Mô hình vận hành

·         Bảo mật và phân quyền

·         Khả năng giám sát

·         Chi phí trên mỗi đơn vị mở rộng

·         Khả năng xử lý ngoại lệ

Một thử nghiệm thành công chỉ chứng minh giải pháp có tiềm năng. Nó chưa chứng minh tổ chức đã sẵn sàng vận hành giải pháp ở quy mô lớn.

Không xây dựng năng lực nội bộ

Phụ thuộc hoàn toàn vào nhà cung cấp có thể giúp dự án khởi động nhanh nhưng làm giảm khả năng duy trì kết quả.

Sau khi nhà triển khai rút đi, doanh nghiệp có thể thiếu người hiểu:

·         Kiến trúc hệ thống

·         Quy tắc dữ liệu

·         Logic cấu hình

·         Cách đánh giá yêu cầu thay đổi

·         Quy trình vận hành và xử lý sự cố

·         Cách đo lường lợi ích

Khi đó, mỗi thay đổi nhỏ đều cần thuê bên ngoài. Chi phí tăng, tốc độ phản ứng chậm và tri thức về hệ thống không được tích lũy trong tổ chức.

McKinsey xác định việc đầu tư không đủ cho xây dựng năng lực là một trong những yếu tố góp phần làm các chương trình chuyển đổi thất bại.

Xây dựng năng lực nội bộ không có nghĩa là doanh nghiệp phải tự thực hiện mọi việc. Mô hình phù hợp thường là kết hợp chuyên môn bên ngoài với đội ngũ nội bộ chịu trách nhiệm về kiến trúc, sản phẩm, dữ liệu, quy trình và giá trị kinh doanh.

Việc chuyển giao tri thức phải diễn ra xuyên suốt dự án, không nên được dồn vào một vài buổi đào tạo trước khi nghiệm thu.

Không quản lý sự phụ thuộc giữa chiến lược, dữ liệu, công nghệ và con người

Các sai lầm khi chuyển đổi số hiếm khi tồn tại độc lập. Chúng thường khuếch đại lẫn nhau.

Ví dụ:

·         Mục tiêu không rõ khiến tổ chức chọn sai công nghệ

·         Chọn sai công nghệ dẫn đến tùy chỉnh quá mức

·         Tùy chỉnh quá mức làm ngân sách và tiến độ vượt kiểm soát

·         Tiến độ kéo dài làm người dùng mất niềm tin

·         Người dùng không áp dụng khiến dữ liệu thiếu chính xác

·         Dữ liệu kém làm lợi ích kinh doanh không thể chứng minh

Vì vậy, khắc phục một vấn đề riêng lẻ có thể không cứu được dự án. Đào tạo thêm sẽ không hiệu quả nếu quy trình mới bất hợp lý. Thay nhà cung cấp cũng không giải quyết được vấn đề nếu quyền quyết định vẫn phân tán. Mua công cụ dữ liệu mới không tạo ra chất lượng dữ liệu nếu không xác định chủ sở hữu.

Ban chỉ đạo cần nhìn dự án như một hệ thống gồm các yếu tố phụ thuộc:

·         Chiến lược và giá trị

·         Quy trình vận hành

·         Dữ liệu

·         Kiến trúc công nghệ

·         Con người và năng lực

·         Cơ chế quản trị

·         Quản trị thay đổi

·         Đo lường lợi ích

Một thay đổi ở bất kỳ yếu tố nào đều có thể làm thay đổi tính khả thi của những yếu tố còn lại.

Dấu hiệu cho thấy dự án đang có nguy cơ thất bại

Không cần đợi đến khi dự án trễ hạn nghiêm trọng mới kết luận rằng chương trình gặp vấn đề. Một số tín hiệu có thể xuất hiện sớm:

·         Các lãnh đạo mô tả mục tiêu dự án theo những cách khác nhau

·         Báo cáo tập trung vào tiến độ nhưng không có chỉ số giá trị

·         Nhân sự nghiệp vụ liên tục vắng mặt trong các quyết định quan trọng

·         Yêu cầu tùy chỉnh tăng nhanh

·         Phạm vi thay đổi nhưng lợi ích kỳ vọng không được tính lại

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

·         Người dùng chỉ được tham gia ở giai đoạn kiểm thử cuối

·         Đội dự án duy trì nhiều quy trình thủ công ngoài hệ thống

·         Không có kế hoạch hỗ trợ và vận hành sau nghiệm thu

·         Mọi vấn đề đều được quy về thiếu tính năng

·         Dự án thí điểm thành công nhưng chưa có mô hình nhân rộng

·         Nhà cung cấp nắm giữ phần lớn tri thức quan trọng

Một tín hiệu riêng lẻ chưa đủ chứng minh dự án sẽ thất bại. Tuy nhiên, khi nhiều dấu hiệu cùng xuất hiện, tổ chức cần đánh giá lại toàn bộ giả định, phạm vi và mô hình quản trị thay vì chỉ thúc ép đội dự án tăng tốc.

Nguyên tắc giúp tránh các sai lầm khi chuyển đổi số

Để giảm rủi ro, tổ chức cần thiết lập một số nguyên tắc ngay từ đầu:

1.    Bắt đầu bằng vấn đề và kết quả kinh doanh, không bắt đầu bằng sản phẩm công nghệ

2.    Giao trách nhiệm cho lãnh đạo nghiệp vụ có đủ thẩm quyền

3.    Đơn giản hóa và chuẩn hóa quy trình trước khi tự động hóa

4.    Chia chương trình thành các giai đoạn tạo được giá trị độc lập

5.    Quản trị dữ liệu như một tài sản có chủ sở hữu

6.    Đưa người dùng tham gia từ khâu thiết kế, không chỉ ở giai đoạn đào tạo

7.    Đo đồng thời tiến độ, mức độ sử dụng, hiệu quả vận hành và kết quả kinh doanh

8.    Ưu tiên cấu hình tiêu chuẩn, kiểm soát chặt yêu cầu tùy chỉnh

9.    Lập ngân sách theo toàn bộ vòng đời của năng lực số

10.  Xây dựng năng lực nội bộ song song với triển khai

11.  Chỉ mở rộng sau khi mô hình vận hành đã được kiểm chứng

12.  Duy trì cơ chế dừng hoặc điều chỉnh sáng kiến không còn tạo giá trị

Không có một mô hình triển khai duy nhất phù hợp với mọi doanh nghiệp. Tốc độ, phạm vi và mức đầu tư phải phụ thuộc vào chiến lược, năng lực hiện tại, mức độ sẵn sàng của dữ liệu và khả năng hấp thụ thay đổi của tổ chức.

Phần lớn dự án chuyển đổi số không thất bại vì công nghệ hoàn toàn không hoạt động. Chúng thất bại vì tổ chức triển khai công nghệ mà chưa làm rõ giá trị, chưa thay đổi quy trình, chưa phân định trách nhiệm và chưa tạo điều kiện để con người áp dụng cách làm mới.

Do đó, câu hỏi quan trọng nhất không phải là doanh nghiệp đã mua công nghệ nào, mà là công nghệ đó đã thay đổi được kết quả kinh doanh, hành vi vận hành và trải nghiệm của khách hàng hay chưa.

Một chương trình chuyển đổi số có cơ hội thành công cao hơn khi được quản trị như một hệ thống thay đổi toàn diện: chiến lược định hướng đầu tư, quy trình tạo ra phương thức vận hành mới, dữ liệu hỗ trợ quyết định, công nghệ cung cấp năng lực và con người biến năng lực đó thành kết quả thực tế.