Những sai lầm phổ biến khi triển khai chuyển đổi số

Vì vậy, phần lớn thất bại không bắt nguồn từ việc công nghệ không đủ hiện đại. Nguyên nhân thường nằm ở sự thiếu liên kết giữa chiến lược, con người, quy trình, dữ liệu và năng lực thực thi. Một hệ thống có thể được cài đặt đúng kỹ thuật nhưng vẫn không tạo ra kết quả nếu nhân viên không sử dụng, dữ liệu không đáng tin cậy hoặc quy trình cũ không được thay đổi.

Nhận diện đúng các sai lầm khi triển khai chuyển đổi số giúp doanh nghiệp tránh đầu tư dàn trải, giảm xung đột nội bộ và tập trung nguồn lực vào những thay đổi có khả năng tạo ra giá trị đo lường được.

Nhầm lẫn chuyển đổi số với đầu tư công nghệ

Sai lầm phổ biến nhất là xem chuyển đổi số như một dự án mua sắm công nghệ. Doanh nghiệp bắt đầu bằng câu hỏi “nên mua hệ thống nào” thay vì “vấn đề kinh doanh nào cần được giải quyết”.

Cách tiếp cận này khiến công nghệ trở thành mục tiêu, trong khi công nghệ chỉ nên là phương tiện. Một nền tảng quản trị khách hàng không tự động giúp tăng doanh thu. Hệ thống hoạch định nguồn lực không tự động làm giảm chi phí. Công cụ phân tích dữ liệu cũng không cải thiện chất lượng quyết định nếu dữ liệu đầu vào thiếu chính xác hoặc người quản lý vẫn ra quyết định theo thói quen.

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

1.    Doanh nghiệp lựa chọn công nghệ trước khi xác định vấn đề

2.    Các phòng ban cố gắng điều chỉnh nhu cầu theo tính năng của hệ thống

3.    Quy trình cũ được đưa nguyên trạng lên phần mềm

4.    Người dùng thấy hệ thống phức tạp nhưng không tạo thêm giá trị

5.    Tỷ lệ sử dụng giảm sau giai đoạn triển khai ban đầu

Điểm cần phân biệt là số hóa, ứng dụng công nghệ và chuyển đổi số không hoàn toàn giống nhau. Chuyển tài liệu giấy thành tệp điện tử là số hóa dữ liệu. Dùng phần mềm để xử lý một quy trình là số hóa hoạt động. Chuyển đổi số chỉ thực sự xảy ra khi doanh nghiệp thay đổi cách vận hành hoặc mô hình tạo giá trị nhờ công nghệ và dữ liệu.

Doanh nghiệp nên bắt đầu bằng một bài toán cụ thể như rút ngắn thời gian xử lý đơn hàng, giảm sai lệch tồn kho, nâng tỷ lệ khách hàng quay lại hoặc cải thiện độ chính xác của dự báo. Sau đó mới xác định quy trình, dữ liệu và công nghệ cần thiết để giải quyết bài toán đó.

Không gắn chuyển đổi số với chiến lược kinh doanh

Một chương trình chuyển đổi số dễ mất phương hướng khi không có mối liên hệ rõ ràng với mục tiêu kinh doanh. Doanh nghiệp có thể triển khai nhiều sáng kiến cùng lúc nhưng không giải thích được sáng kiến nào giúp tăng doanh thu, giảm chi phí, kiểm soát rủi ro hay nâng cao trải nghiệm khách hàng.

Khi thiếu định hướng chiến lược, danh mục dự án thường được hình thành từ đề xuất riêng lẻ của từng phòng ban. Bộ phận kinh doanh muốn triển khai hệ thống quản trị khách hàng, bộ phận vận hành muốn tự động hóa, bộ phận nhân sự muốn xây dựng cổng thông tin nội bộ, còn bộ phận công nghệ muốn nâng cấp hạ tầng. Mỗi đề xuất có thể hợp lý, nhưng tổng thể lại thiếu thứ tự ưu tiên và không tạo thành một kiến trúc thống nhất.

Hậu quả thường gồm:

·         Ngân sách bị chia nhỏ cho quá nhiều dự án

·         Các hệ thống không kết nối được với nhau

·         Nhiều sáng kiến cạnh tranh cùng một nguồn lực

·         Không xác định được dự án nào tạo ra giá trị cao nhất

·         Ban lãnh đạo khó quyết định nên tiếp tục, điều chỉnh hay dừng đầu tư

Một chiến lược chuyển đổi số hiệu quả phải trả lời được bốn câu hỏi:

1.    Doanh nghiệp đang cần cải thiện kết quả kinh doanh nào

2.    Năng lực vận hành nào phải thay đổi để tạo ra kết quả đó

3.    Dữ liệu và công nghệ nào hỗ trợ năng lực mới

4.    Giá trị được đo bằng chỉ số nào

Ví dụ, mục tiêu “nâng cao trải nghiệm khách hàng” còn quá rộng. Mục tiêu cần được chuyển thành kết quả có thể theo dõi như giảm thời gian phản hồi, tăng tỷ lệ giải quyết yêu cầu ngay lần đầu hoặc giảm số bước khách hàng phải thực hiện.

Chỉ số phải phản ánh kết quả kinh doanh, không chỉ phản ánh tiến độ kỹ thuật. Việc cài đặt xong hệ thống, hoàn thành tích hợp hay đào tạo đủ số buổi chỉ cho thấy dự án đã triển khai hoạt động. Chúng chưa chứng minh doanh nghiệp đã tạo ra giá trị.

Triển khai quá nhiều sáng kiến cùng lúc

Chuyển đổi số thường tạo ra tâm lý phải thay đổi nhanh trên toàn doanh nghiệp. Tuy nhiên, triển khai đồng thời quá nhiều dự án có thể khiến tổ chức vượt quá khả năng hấp thụ thay đổi.

Mỗi sáng kiến đều cần người phụ trách, chuyên gia nghiệp vụ, dữ liệu, ngân sách, năng lực công nghệ và thời gian của người dùng. Khi nhiều dự án cùng yêu cầu một nhóm nhân sự chủ chốt, tiến độ sẽ chậm lại và chất lượng quyết định giảm xuống. Nhân viên cũng phải thích nghi với nhiều quy trình và công cụ mới trong thời gian ngắn.

Vấn đề không nằm ở tham vọng lớn mà ở việc thiếu trình tự triển khai. Một danh mục chuyển đổi số cần được ưu tiên dựa trên ít nhất bốn yếu tố:

·         Giá trị kinh doanh dự kiến

·         Mức độ cấp thiết của vấn đề

·         Khả năng thực hiện

·         Quan hệ phụ thuộc giữa các sáng kiến

Một dự án phân tích nâng cao khó tạo ra kết quả nếu dữ liệu nền chưa được chuẩn hóa. Tự động hóa một quy trình chưa ổn định có thể khiến sai sót xảy ra nhanh hơn. Triển khai nhiều ứng dụng phục vụ khách hàng trước khi thống nhất hồ sơ khách hàng có thể làm dữ liệu phân mảnh hơn.

Thay vì triển khai dàn trải, doanh nghiệp nên chọn một số trường hợp sử dụng có giá trị cao, phạm vi đủ hẹp và kết quả có thể đo lường. Sau khi chứng minh được hiệu quả, mô hình mới được mở rộng sang đơn vị hoặc quy trình khác.

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

Chuyển đổi số khó thành công nếu được giao hoàn toàn cho bộ phận công nghệ thông tin. Bộ phận công nghệ có thể xây dựng nền tảng và bảo đảm hệ thống vận hành, nhưng không thể tự quyết định cách doanh nghiệp bán hàng, chăm sóc khách hàng, quản lý tồn kho hoặc đánh giá hiệu suất.

Lãnh đạo phải tham gia vì chuyển đổi số thường đòi hỏi những quyết định vượt qua ranh giới phòng ban. Chẳng hạn, việc xây dựng một nguồn dữ liệu khách hàng thống nhất có thể yêu cầu thay đổi quyền sở hữu dữ liệu, quy trình nhập liệu và cách chia sẻ thông tin giữa kinh doanh, marketing và chăm sóc khách hàng.

Cam kết của lãnh đạo không chỉ thể hiện qua việc phê duyệt ngân sách hoặc phát biểu tại lễ khởi động. Cam kết thực chất bao gồm:

·         Xác định mục tiêu và thứ tự ưu tiên

·         Chỉ định người chịu trách nhiệm về kết quả kinh doanh

·         Giải quyết xung đột giữa các phòng ban

·         Phân bổ nhân sự có năng lực cho dự án

·         Theo dõi giá trị sau khi hệ thống được đưa vào sử dụng

·         Chấp nhận điều chỉnh quy trình và cơ chế quản trị

Nếu lãnh đạo chỉ quan tâm đến ngày hoàn thành, dự án dễ tối ưu cho việc bàn giao hệ thống thay vì tối ưu cho hiệu quả vận hành. Một dự án có thể hoàn thành đúng hạn nhưng vẫn thất bại nếu người dùng không thay đổi hành vi hoặc chỉ số kinh doanh không cải thiện.

Không xác định rõ quyền sở hữu và trách nhiệm

Nhiều chương trình chuyển đổi số có ban chỉ đạo, ban dự án và nhiều nhóm tham gia nhưng không có một cá nhân chịu trách nhiệm cuối cùng về kết quả. Khi vấn đề phát sinh, bộ phận nghiệp vụ cho rằng đó là lỗi công nghệ, còn bộ phận công nghệ cho rằng yêu cầu nghiệp vụ chưa rõ ràng.

Đây là khác biệt giữa trách nhiệm triển khai và trách nhiệm tạo giá trị. Nhà cung cấp có thể chịu trách nhiệm cấu hình hệ thống. Bộ phận công nghệ chịu trách nhiệm tích hợp và vận hành. Tuy nhiên, chủ sở hữu nghiệp vụ phải chịu trách nhiệm về việc quy trình mới có tạo ra kết quả hay không.

Mỗi sáng kiến cần xác định rõ:

·         Người bảo trợ ở cấp lãnh đạo

·         Chủ sở hữu kết quả kinh doanh

·         Chủ sở hữu quy trình

·         Chủ sở hữu dữ liệu

·         Nhóm công nghệ phụ trách triển khai

·         Người dùng chịu trách nhiệm kiểm thử và tiếp nhận

Trách nhiệm cũng phải gắn với quyền ra quyết định. Một chủ sở hữu quy trình không thể chịu trách nhiệm nếu không có quyền điều chỉnh quy trình hoặc yêu cầu các đơn vị liên quan tuân thủ tiêu chuẩn chung.

Bỏ qua yếu tố con người và quản trị thay đổi

Công nghệ có thể được triển khai theo kế hoạch, nhưng hành vi con người không tự động thay đổi theo ngày vận hành chính thức. Nhân viên có thể tiếp tục dùng bảng tính, trao đổi qua ứng dụng cá nhân hoặc lưu dữ liệu ngoài hệ thống vì cách làm cũ quen thuộc và nhanh hơn trong ngắn hạn.

Sự phản kháng không nhất thiết xuất phát từ thái độ tiêu cực. Nhân viên có thể lo ngại mất quyền kiểm soát, mất việc, bị giám sát chặt hơn hoặc phải thực hiện nhiều thao tác hơn. Một số người phản đối vì hệ thống mới thực sự chưa phù hợp với công việc.

Sai lầm của doanh nghiệp là xem đào tạo sử dụng phần mềm như toàn bộ hoạt động quản trị thay đổi. Đào tạo chỉ trả lời câu hỏi “sử dụng công cụ như thế nào”. Quản trị thay đổi còn phải giải quyết:

·         Vì sao tổ chức cần thay đổi

·         Công việc của từng nhóm sẽ thay đổi ra sao

·         Lợi ích và bất tiện đối với người sử dụng

·         Hành vi nào được kỳ vọng

·         Khó khăn được hỗ trợ theo cơ chế nào

·         Kết quả sử dụng được đo lường ra sao

Doanh nghiệp cần theo dõi mức độ chấp nhận bằng dữ liệu hành vi thay vì chỉ đếm số người đã tham gia đào tạo. Các chỉ số có thể gồm tỷ lệ người dùng hoạt động, tần suất sử dụng chức năng chính, tỷ lệ giao dịch được thực hiện hoàn toàn trên hệ thống và số trường hợp quay lại quy trình thủ công.

Một hệ thống có nhiều tài khoản được cấp nhưng ít giao dịch thực tế không thể được xem là đã được tiếp nhận thành công.

Không phát triển năng lực số cho đội ngũ

Chuyển đổi số không chỉ thay đổi công cụ mà còn làm thay đổi yêu cầu năng lực. Nhân viên cần biết đọc dữ liệu, sử dụng hệ thống, phối hợp liên chức năng và điều chỉnh công việc theo quy trình mới. Nhà quản lý cần biết đặt câu hỏi dựa trên dữ liệu và đánh giá hiệu quả bằng chỉ số.

Nếu chỉ đào tạo thao tác phần mềm, doanh nghiệp có thể tạo ra người dùng biết bấm nút nhưng không hiểu logic vận hành. Khi gặp tình huống ngoài kịch bản, họ quay lại cách làm cũ hoặc nhập dữ liệu đối phó.

Năng lực cần được phát triển theo vai trò:

Đối với nhân viên nghiệp vụ

Nhân viên cần hiểu quy trình đầu cuối, tiêu chuẩn dữ liệu, ý nghĩa của các trường thông tin và hậu quả của việc nhập sai dữ liệu.

Đối với nhà quản lý

Nhà quản lý cần biết sử dụng bảng điều khiển, diễn giải chỉ số, phát hiện sai lệch và đưa ra quyết định dựa trên dữ liệu thay vì chỉ yêu cầu báo cáo thủ công.

Đối với đội ngũ công nghệ

Nhân sự công nghệ cần hiểu mục tiêu nghiệp vụ, kiến trúc tích hợp, an toàn thông tin và cách quản lý sản phẩm số trong suốt vòng đời.

Đối với lãnh đạo

Lãnh đạo cần hiểu giới hạn của công nghệ, các rủi ro về dữ liệu và lý do phải thay đổi cơ chế quản trị chứ không chỉ thay đổi công cụ.

Phát triển năng lực số nên được xem là một chương trình liên tục. Năng lực phải được đánh giá thông qua khả năng thực hiện công việc trong môi trường mới, không chỉ thông qua chứng nhận hoàn thành khóa học.

Số hóa nguyên trạng một quy trình kém hiệu quả

Tự động hóa không sửa được một quy trình được thiết kế sai. Nếu quy trình có nhiều bước phê duyệt không cần thiết, trách nhiệm không rõ ràng hoặc dữ liệu bị nhập lặp lại, đưa quy trình đó lên phần mềm chỉ làm cho sự phức tạp trở nên cố định hơn.

Sai lầm này thường xuất hiện khi doanh nghiệp muốn hệ thống mới mô phỏng hoàn toàn cách làm hiện tại. Mục tiêu ngầm là giảm sự thay đổi đối với người dùng. Tuy nhiên, cách tiếp cận đó bỏ lỡ cơ hội loại bỏ các bước không tạo giá trị.

Trước khi số hóa, doanh nghiệp cần phân tích quy trình theo các câu hỏi:

·         Bước này tạo ra giá trị gì

·         Thông tin này đã tồn tại ở hệ thống khác chưa

·         Vì sao cần phê duyệt ở cấp này

·         Điều kiện nào có thể được kiểm tra tự động

·         Trường hợp ngoại lệ chiếm tỷ lệ bao nhiêu

·         Điểm chờ lớn nhất nằm ở đâu

·         Sai sót thường phát sinh tại bước nào

Quy trình mới cần được thiết kế theo hướng đơn giản hóa trước, tiêu chuẩn hóa sau và tự động hóa cuối cùng. Tuy nhiên, không nên loại bỏ mọi kiểm soát chỉ để giảm số bước. Những bước liên quan đến an toàn, tuân thủ, gian lận hoặc giá trị giao dịch lớn vẫn cần cơ chế kiểm soát phù hợp.

Hiệu quả của quy trình nên được đo bằng thời gian xử lý đầu cuối, tỷ lệ xử lý đúng ngay lần đầu, số lần chuyển giao, tỷ lệ ngoại lệ và chi phí trên mỗi giao dịch.

Xem nhẹ chất lượng và quản trị dữ liệu

Dữ liệu là nền tảng của nhiều sáng kiến chuyển đổi số, nhưng doanh nghiệp thường chỉ chú ý đến ứng dụng hiển thị mà bỏ qua cách dữ liệu được tạo, chuẩn hóa, chia sẻ và bảo vệ.

Một báo cáo đẹp không có giá trị nếu các phòng ban sử dụng định nghĩa khác nhau cho cùng một chỉ số. Một mô hình dự báo không đáng tin cậy nếu dữ liệu lịch sử thiếu, trùng lặp hoặc không nhất quán. Tự động hóa cũng có thể đưa ra quyết định sai với tốc độ cao hơn nếu dữ liệu đầu vào sai.

Các vấn đề dữ liệu phổ biến gồm:

·         Không có chủ sở hữu dữ liệu

·         Một khách hàng có nhiều hồ sơ khác nhau

·         Mã sản phẩm không thống nhất giữa các hệ thống

·         Định nghĩa doanh thu, khách hàng mới hoặc đơn hàng hoàn tất khác nhau

·         Dữ liệu quan trọng được lưu trong tệp cá nhân

·         Không có quy tắc kiểm tra chất lượng

·         Quyền truy cập được cấp rộng hơn nhu cầu công việc

Quản trị dữ liệu không có nghĩa là tập trung mọi quyền kiểm soát vào một bộ phận. Mục tiêu là xác định rõ ai chịu trách nhiệm về định nghĩa, chất lượng, quyền truy cập và vòng đời của từng nhóm dữ liệu.

Doanh nghiệp có thể theo dõi chất lượng bằng các chỉ số như tỷ lệ trường bắt buộc được điền đầy đủ, tỷ lệ bản ghi trùng lặp, tỷ lệ dữ liệu hợp lệ, độ trễ cập nhật và số lượng vấn đề dữ liệu chưa được xử lý. Ngưỡng mục tiêu cần được xác định theo mức độ quan trọng của từng trường dữ liệu, thay vì áp dụng một tiêu chuẩn chung cho toàn bộ hệ thống.

Lựa chọn công nghệ không phù hợp với nhu cầu và năng lực

Một công nghệ nổi tiếng hoặc có nhiều tính năng chưa chắc phù hợp với doanh nghiệp. Sự phù hợp phụ thuộc vào quy mô, quy trình, năng lực vận hành, yêu cầu tích hợp, mức độ bảo mật và tổng chi phí trong suốt vòng đời.

Doanh nghiệp thường mắc hai cực đoan. Một là chọn giải pháp quá đơn giản, không đáp ứng khả năng mở rộng. Hai là chọn nền tảng quá phức tạp so với nhu cầu và năng lực quản trị hiện tại.

Đánh giá công nghệ không nên chỉ dựa trên danh sách tính năng. Cần xem xét:

·         Mức độ phù hợp với quy trình mục tiêu

·         Khả năng cấu hình mà không tùy chỉnh quá mức

·         Khả năng tích hợp với hệ thống hiện có

·         Khả năng mở rộng theo khối lượng giao dịch

·         Yêu cầu về an toàn và tuân thủ

·         Năng lực hỗ trợ của nhà cung cấp

·         Khả năng xuất và di chuyển dữ liệu

·         Chi phí triển khai, vận hành, nâng cấp và đào tạo

Tùy chỉnh sâu có thể giúp hệ thống đáp ứng cách làm hiện tại nhưng làm tăng chi phí bảo trì và khó nâng cấp. Ngược lại, áp dụng hoàn toàn quy trình chuẩn của phần mềm có thể không phù hợp với đặc thù tạo lợi thế cạnh tranh của doanh nghiệp.

Quyết định cần dựa trên việc phân loại quy trình. Với hoạt động hỗ trợ phổ biến, doanh nghiệp có thể ưu tiên quy trình chuẩn. Với hoạt động tạo khác biệt cạnh tranh, mức độ cấu hình hoặc phát triển riêng có thể cao hơn, nhưng phải được kiểm soát bằng nguyên tắc kiến trúc rõ ràng.

Thiếu kiến trúc tích hợp tổng thể

Khi mỗi phòng ban lựa chọn một ứng dụng riêng, doanh nghiệp dễ hình thành các “ốc đảo công nghệ”. Mỗi hệ thống giải quyết được một nhu cầu cục bộ nhưng dữ liệu không lưu chuyển xuyên suốt.

Hậu quả là nhân viên phải nhập lại thông tin, đối chiếu nhiều báo cáo và sử dụng bảng tính để nối các khoảng trống giữa hệ thống. Khách hàng có thể phải cung cấp cùng một thông tin nhiều lần vì các bộ phận không nhìn thấy lịch sử tương tác đầy đủ.

Kiến trúc tích hợp cần làm rõ:

·         Hệ thống nào là nguồn dữ liệu chính

·         Dữ liệu nào được trao đổi giữa các hệ thống

·         Tần suất đồng bộ

·         Cách xử lý khi tích hợp thất bại

·         Quy tắc kiểm soát truy cập

·         Cơ chế theo dõi và truy vết giao dịch

·         Phương án thay thế một thành phần trong tương lai

Không phải mọi hệ thống đều cần kết nối trực tiếp với nhau. Kết nối điểm đến điểm có thể triển khai nhanh ở giai đoạn đầu nhưng trở nên khó kiểm soát khi số lượng hệ thống tăng. Kiến trúc phải cân bằng giữa tốc độ triển khai hiện tại và khả năng thay đổi trong tương lai.

Doanh nghiệp cũng cần tránh thiết kế kiến trúc quá phức tạp khi chưa có nhu cầu thực tế. Kiến trúc tốt không phải kiến trúc sử dụng nhiều công nghệ nhất mà là kiến trúc đáp ứng yêu cầu với mức phức tạp có thể quản lý.

Bỏ qua an toàn thông tin, quyền riêng tư và tính liên tục

Mở rộng kết nối, lưu trữ dữ liệu tập trung và đưa quy trình lên nền tảng số có thể làm tăng bề mặt rủi ro. Nếu an toàn thông tin chỉ được kiểm tra ở cuối dự án, việc sửa lỗi có thể tốn kém hoặc buộc doanh nghiệp thay đổi thiết kế.

Rủi ro không chỉ đến từ tấn công bên ngoài. Tài khoản được cấp quyền quá rộng, nhân viên chia sẻ mật khẩu, dữ liệu được tải xuống thiết bị cá nhân hoặc nhà cung cấp truy cập vượt quá phạm vi cần thiết đều có thể tạo ra sự cố.

An toàn cần được tích hợp ngay từ giai đoạn thiết kế thông qua:

·         Xác thực và phân quyền theo vai trò

·         Nguyên tắc cấp quyền tối thiểu

·         Mã hóa dữ liệu phù hợp

·         Ghi nhật ký và giám sát truy cập

·         Sao lưu và kiểm tra khả năng khôi phục

·         Quản lý lỗ hổng và bản vá

·         Đánh giá rủi ro nhà cung cấp

·         Kế hoạch ứng phó sự cố

Bên cạnh bảo mật, doanh nghiệp phải xem xét tính liên tục. Một quy trình số hóa hoàn toàn có thể dừng hoạt động nếu hệ thống hoặc đường truyền gặp sự cố. Vì vậy, mỗi dịch vụ quan trọng cần có mục tiêu khôi phục, phương án vận hành tạm thời và cơ chế kiểm thử định kỳ.

Mức kiểm soát phải tương xứng với mức độ quan trọng của dữ liệu và quy trình. Áp dụng kiểm soát quá nhẹ tạo ra rủi ro, nhưng áp dụng cùng một mức kiểm soát nghiêm ngặt cho mọi trường hợp có thể làm giảm trải nghiệm và hiệu suất.

Chạy thử hình thức rồi mở rộng quá sớm

Thử nghiệm giúp doanh nghiệp kiểm chứng giả định trước khi đầu tư lớn. Tuy nhiên, nhiều dự án thử nghiệm chỉ nhằm chứng minh rằng công nghệ có thể hoạt động, không chứng minh rằng giải pháp tạo ra giá trị trong điều kiện vận hành thực tế.

Một thử nghiệm hình thức thường có phạm vi thuận lợi, dữ liệu được làm sạch thủ công, người dùng được hỗ trợ sát sao và không phải xử lý đầy đủ các ngoại lệ. Kết quả tốt trong môi trường này chưa bảo đảm giải pháp có thể mở rộng.

Trước khi bắt đầu, thử nghiệm cần có:

·         Giả thuyết kinh doanh rõ ràng

·         Chỉ số nền để so sánh

·         Tiêu chí thành công

·         Nhóm người dùng đại diện

·         Các trường hợp ngoại lệ quan trọng

·         Thời hạn đánh giá

·         Điều kiện mở rộng, điều chỉnh hoặc dừng

Kết quả cần đánh giá cả giá trị và khả năng vận hành. Một giải pháp có thể tạo ra lợi ích nhưng chi phí hỗ trợ quá cao. Một công cụ có thể hiệu quả với nhóm nhỏ nhưng giảm hiệu suất khi số lượng giao dịch tăng.

Doanh nghiệp không nên mở rộng chỉ vì thử nghiệm nhận được phản hồi tích cực. Quyết định cần dựa trên dữ liệu sử dụng, tác động đến chỉ số kinh doanh, độ ổn định, chi phí và khả năng hỗ trợ ở quy mô lớn.

Đo lường tiến độ thay vì đo lường giá trị

Các chương trình chuyển đổi số thường báo cáo tỷ lệ hoàn thành, số chức năng đã phát triển, số người được đào tạo hoặc số hệ thống đã kết nối. Đây là chỉ số hoạt động, không phải chỉ số giá trị.

Việc tập trung vào tiến độ khiến nhóm dự án tối ưu cho bàn giao. Khi hệ thống đi vào vận hành, sự chú ý giảm xuống dù kết quả kinh doanh chưa xuất hiện.

Khung đo lường nên gồm nhiều tầng:

Chỉ số triển khai

Theo dõi tiến độ, ngân sách, chất lượng kỹ thuật và phạm vi công việc.

Chỉ số tiếp nhận

Theo dõi tỷ lệ người dùng hoạt động, tần suất sử dụng, mức độ hoàn thành quy trình số và tỷ lệ quay lại cách làm thủ công.

Chỉ số vận hành

Theo dõi thời gian xử lý, tỷ lệ sai sót, năng suất, chi phí giao dịch và số lượng ngoại lệ.

Chỉ số kinh doanh

Theo dõi doanh thu, biên lợi nhuận, tỷ lệ giữ chân khách hàng, mức độ hài lòng hoặc rủi ro được giảm.

Các tầng chỉ số có quan hệ nhân quả. Hệ thống phải được triển khai ổn định, người dùng phải tiếp nhận, quy trình phải cải thiện thì kết quả kinh doanh mới có khả năng xuất hiện. Tuy nhiên, mối quan hệ này không tự động đúng trong mọi trường hợp. Các yếu tố thị trường, chính sách giá hoặc mùa vụ cũng có thể ảnh hưởng đến kết quả.

Vì vậy, doanh nghiệp cần thiết lập số liệu nền trước khi triển khai và theo dõi xu hướng trong một khoảng thời gian phù hợp. Không có số liệu nền, doanh nghiệp khó chứng minh thay đổi là kết quả của sáng kiến số hay chỉ là biến động thông thường.

Không quản lý chuyển đổi số như một năng lực liên tục

Một sai lầm khác là xem chuyển đổi số như dự án có ngày bắt đầu và ngày kết thúc cố định. Cách nhìn này phù hợp với việc triển khai một hệ thống, nhưng không phù hợp với quá trình thay đổi năng lực của tổ chức.

Sau khi vận hành, nhu cầu người dùng tiếp tục thay đổi, dữ liệu phát sinh vấn đề mới, quy trình xuất hiện ngoại lệ và công nghệ cần được nâng cấp. Nếu nhóm dự án giải tán ngay sau bàn giao, doanh nghiệp thiếu cơ chế cải tiến và dễ quay lại trạng thái cũ.

Chuyển đổi số cần được quản lý theo vòng lặp:

1.    Xác định vấn đề và kết quả mong muốn

2.    Thiết kế thay đổi

3.    Triển khai trong phạm vi kiểm soát

4.    Đo lường mức độ tiếp nhận và giá trị

5.    Điều chỉnh dựa trên dữ liệu

6.    Chuẩn hóa và mở rộng

7.    Tiếp tục cải tiến

Cách tiếp cận này không có nghĩa là dự án phải kéo dài vô hạn. Từng sáng kiến vẫn cần mục tiêu, ngân sách và mốc hoàn thành rõ ràng. Điểm khác biệt là doanh nghiệp duy trì năng lực quản trị sản phẩm, dữ liệu, kiến trúc và thay đổi sau khi dự án kết thúc.

Cách hạn chế sai lầm khi triển khai chuyển đổi số

Không có một lộ trình duy nhất phù hợp với mọi doanh nghiệp. Tuy nhiên, một số nguyên tắc giúp giảm đáng kể rủi ro thực thi.

Bắt đầu từ giá trị kinh doanh

Mỗi sáng kiến phải gắn với một vấn đề cụ thể, một nhóm người dùng và một kết quả có thể đo lường. Không nên bắt đầu từ danh sách công nghệ đang thịnh hành.

Thiết kế lại quy trình trước khi tự động hóa

Loại bỏ bước thừa, làm rõ trách nhiệm và chuẩn hóa dữ liệu trước khi đưa quy trình lên hệ thống.

Ưu tiên theo giá trị và khả năng thực hiện

Chọn số lượng sáng kiến phù hợp với năng lực hấp thụ của tổ chức. Giải quyết các điều kiện nền tảng trước khi triển khai các ứng dụng phụ thuộc.

Giao trách nhiệm cho chủ sở hữu nghiệp vụ

Bộ phận công nghệ không nên là đơn vị duy nhất chịu trách nhiệm. Mỗi sáng kiến phải có người chịu trách nhiệm về kết quả vận hành hoặc kinh doanh.

Đưa người dùng tham gia từ sớm

Người dùng cần tham gia xác định yêu cầu, thiết kế quy trình, kiểm thử và đánh giá kết quả. Điều này giúp phát hiện sớm khoảng cách giữa thiết kế và công việc thực tế.

Đo lường cả tiếp nhận lẫn giá trị

Không chỉ theo dõi việc hệ thống đã được triển khai. Cần đo hành vi sử dụng, hiệu quả quy trình và kết quả kinh doanh.

Xem dữ liệu và an toàn là nền tảng

Chất lượng dữ liệu, quyền sở hữu, phân quyền và khả năng khôi phục phải được thiết kế ngay từ đầu.

Mở rộng dựa trên bằng chứng

Chỉ nhân rộng khi thử nghiệm đã chứng minh được giá trị, khả năng vận hành và điều kiện cần thiết để áp dụng ở quy mô lớn.

Những sai lầm khi triển khai chuyển đổi số thường không tồn tại riêng lẻ. Chiến lược thiếu rõ ràng dẫn đến đầu tư dàn trải; trách nhiệm không rõ khiến quy trình không được thay đổi; quản trị thay đổi yếu làm tỷ lệ sử dụng thấp; dữ liệu kém làm hệ thống mất độ tin cậy.

Do đó, doanh nghiệp không nên đánh giá chuyển đổi số bằng số lượng phần mềm đã mua hoặc số quy trình đã đưa lên trực tuyến. Thước đo quan trọng hơn là tổ chức có vận hành tốt hơn, ra quyết định chính xác hơn và tạo ra giá trị bền vững hơn hay không.

Chuyển đổi số thành công đòi hỏi sự đồng bộ giữa chiến lược, lãnh đạo, con người, quy trình, dữ liệu, công nghệ và cơ chế đo lường. Công nghệ chỉ phát huy giá trị khi các thành phần này cùng thay đổi theo một mục tiêu chung.