Những sai lầm triển khai công nghệ doanh nghiệp thường gặp

Vì vậy, một hệ thống có thể hoạt động đúng về kỹ thuật nhưng dự án vẫn không đạt mục tiêu kinh doanh. Ngược lại, một giải pháp không có đầy đủ mọi tính năng vẫn có thể mang lại giá trị nếu phù hợp với quy trình, được tích hợp đúng, có dữ liệu đáng tin cậy và được người dùng thực sự sử dụng.

Cách đánh giá triển khai vì thế cần vượt khỏi tiêu chí “đã go-live hay chưa”. Các chỉ số như tỷ lệ người dùng thực tế, tỷ lệ giao dịch hoàn thành trên hệ thống, thời gian xử lý quy trình, lỗi dữ liệu, lỗi tích hợp, số ticket hỗ trợ, chênh lệch ngân sách và thời gian tạo ra giá trị mới phản ánh tốt hơn trạng thái của dự án.

Xem triển khai công nghệ như một dự án IT thay vì một thay đổi kinh doanh

Sai lầm nền tảng là bắt đầu bằng câu hỏi “nên mua phần mềm nào?” trước khi xác định doanh nghiệp muốn thay đổi kết quả kinh doanh nào.

Khi dự án được đóng khung chủ yếu dưới góc độ kỹ thuật, đội triển khai thường tập trung vào cấu hình tính năng, migration dữ liệu và ngày go-live. Trong khi đó, những câu hỏi quyết định giá trị lại chưa được làm rõ: quy trình nào phải thay đổi, điểm nghẽn nào cần loại bỏ, ai chịu trách nhiệm cho kết quả và hành vi nào của người dùng phải khác sau triển khai.

Hệ quả thường thấy là hệ thống chạy được nhưng cách làm việc cũ vẫn tồn tại. Nhân viên tiếp tục dùng bảng tính ngoài hệ thống, nhập dữ liệu đối phó hoặc duy trì những bước thủ công vốn là nguyên nhân doanh nghiệp đầu tư công nghệ để loại bỏ.

Một dự án nên bắt đầu bằng chuỗi logic:

Mục tiêu kinh doanh → thay đổi quy trình → năng lực cần có → yêu cầu công nghệ → chỉ số kết quả

Chẳng hạn, nếu mục tiêu là rút ngắn thời gian xử lý đơn hàng, việc nghiệm thu không nên chỉ xác nhận rằng module quản lý đơn hàng hoạt động. Doanh nghiệp còn phải đo thời gian chu trình trước và sau triển khai, tỷ lệ thao tác ngoài hệ thống, lỗi đơn hàng và những bước phê duyệt còn gây tắc nghẽn.

Điều này không có nghĩa bộ phận IT giữ vai trò thứ yếu. IT vẫn chịu trách nhiệm quan trọng về kiến trúc, tích hợp, bảo mật và khả năng vận hành. Nhưng quyền sở hữu kết quả kinh doanh cần thuộc về đơn vị nghiệp vụ có khả năng thay đổi quy trình và hành vi sử dụng.

Lựa chọn giải pháp theo danh sách tính năng thay vì mức độ phù hợp

Danh sách tính năng dài dễ tạo cảm giác một sản phẩm “mạnh hơn”, nhưng số lượng chức năng không cho biết giải pháp có phù hợp với kiến trúc, quy trình và năng lực vận hành của doanh nghiệp hay không.

Sai lầm thường xuất hiện khi quá trình lựa chọn chú trọng demo nhưng xem nhẹ các câu hỏi khó hơn: hệ thống phải trao đổi dữ liệu với những nền tảng nào, quy trình nào được hỗ trợ nguyên bản, phần nào phải tùy chỉnh, mô hình phân quyền có đáp ứng yêu cầu hay không và doanh nghiệp có đủ năng lực duy trì những tùy chỉnh đó trong nhiều năm hay không.

Tùy chỉnh là một ví dụ điển hình. Một thay đổi nhỏ có thể giải quyết nhu cầu trước mắt nhưng đồng thời làm tăng khối lượng kiểm thử, phụ thuộc vào nhà cung cấp và độ phức tạp khi nâng cấp. Nhiều tùy chỉnh riêng lẻ tích tụ sẽ biến một sản phẩm tiêu chuẩn thành một hệ thống gần như riêng biệt.

Chi phí lựa chọn cũng không nên chỉ so sánh bằng giá license. Tổng chi phí sở hữu còn có thể gồm:

·         Chi phí triển khai và cấu hình

·         Chi phí tích hợp

·         Migration và làm sạch dữ liệu

·         Hạ tầng hoặc tài nguyên cloud

·         Kiểm thử và bảo mật

·         Đào tạo và hỗ trợ người dùng

·         Phí đối tác hoặc dịch vụ chuyên môn

·         Chi phí duy trì tùy chỉnh

·         Chi phí nâng cấp và vận hành dài hạn

Giải pháp phù hợp không nhất thiết là giải pháp có nhiều chức năng nhất. Đó là giải pháp đáp ứng đủ nhu cầu trọng yếu với mức phức tạp mà doanh nghiệp có khả năng quản trị.

Tự động hóa một quy trình chưa được làm rõ

Công nghệ không tự sửa một quy trình kém hiệu quả. Nếu logic nghiệp vụ ban đầu chứa phê duyệt dư thừa, trách nhiệm chồng chéo hoặc dữ liệu được nhập nhiều lần, số hóa nguyên trạng có thể chỉ làm những vấn đề đó diễn ra nhanh hơn.

Một biểu hiện phổ biến là đội dự án thu thập yêu cầu bằng cách hỏi người dùng “hệ thống mới phải làm giống hệ thống cũ như thế nào”. Cách tiếp cận này vô tình biến những giới hạn và thói quen lịch sử thành yêu cầu bắt buộc của giải pháp mới.

Trước khi cấu hình, cần phân biệt ba nhóm:

1.    Những bước thực sự tạo giá trị hoặc cần thiết cho kiểm soát

2.    Những bước tồn tại vì hạn chế của công nghệ cũ

3.    Những bước có thể loại bỏ, hợp nhất hoặc tự động hóa

Yêu cầu cũng cần được kiểm tra theo tình huống thực tế thay vì chỉ được ghi dưới dạng mong muốn chung. Một yêu cầu như “hệ thống phải hỗ trợ phê duyệt linh hoạt” chưa đủ để thiết kế. Cần biết ai phê duyệt, ngưỡng nào kích hoạt phê duyệt, trường hợp nào được ủy quyền, dữ liệu nào làm căn cứ và điều gì xảy ra khi yêu cầu bị từ chối.

Tuy nhiên, chuẩn hóa cũng có giới hạn. Không phải mọi khác biệt quy trình đều là lãng phí. Những khác biệt xuất phát từ yêu cầu pháp lý, kiểm soát rủi ro hoặc đặc thù tạo lợi thế kinh doanh có thể cần được bảo toàn.

Đánh giá thấp dữ liệu và tích hợp

Nhiều dự án dành phần lớn thời gian ban đầu cho giao diện và chức năng vì đây là những thứ dễ nhìn thấy. Nhưng khi triển khai thực tế, dữ liệu và tích hợp mới thường quyết định hệ thống có vận hành xuyên suốt hay không.

Dữ liệu cũ có thể chứa bản ghi trùng, mã không nhất quán, trường bắt buộc bị thiếu hoặc nhiều định nghĩa khác nhau cho cùng một thực thể. Chuyển nguyên trạng những dữ liệu này sang nền tảng mới không giải quyết vấn đề; nó đưa vấn đề cũ vào một kiến trúc mới.

Migration vì vậy phải bao gồm ít nhất việc xác định:

·         Dữ liệu nào thực sự cần chuyển

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

·         Quy tắc làm sạch và loại trùng

·         Cách ánh xạ trường dữ liệu cũ sang mô hình mới

·         Người chịu trách nhiệm xác nhận chất lượng dữ liệu

·         Cách đối soát sau khi chuyển

Tích hợp cũng cần được xem như một luồng nghiệp vụ thay vì một kết nối API đơn lẻ. Một đơn hàng có thể đi qua CRM, hệ thống bán hàng, ERP, kho, thanh toán và nền tảng báo cáo. Chỉ một giao diện tích hợp thất bại cũng có thể khiến trạng thái giữa các hệ thống không còn nhất quán.

Doanh nghiệp vì thế cần kiểm thử cả trường hợp thành công lẫn lỗi: kết nối timeout, dữ liệu bị gửi hai lần, bản ghi thiếu trường, một hệ thống tạm ngừng hoặc giao dịch chỉ hoàn thành một phần.

Các KPI như tỷ lệ lỗi tích hợp, tỷ lệ bản ghi không đạt quy tắc chất lượng, số lỗi đối soát và thời gian xử lý lỗi có giá trị hơn nhận định chung rằng “dữ liệu đã được migrate thành công”.

Triển khai quá lớn trước khi kiểm chứng các giả định quan trọng

Áp lực tiến độ thường khiến doanh nghiệp muốn đưa toàn bộ phạm vi vào một lần triển khai. Cách “big bang” có thể phù hợp trong một số điều kiện, nhưng rủi ro tăng mạnh khi yêu cầu, dữ liệu, tích hợp hoặc hành vi người dùng vẫn chứa nhiều giả định chưa được kiểm chứng.

Pilot và rollout theo giai đoạn có giá trị vì chúng tạo vòng phản hồi trước khi lỗi được nhân rộng. Một nhóm người dùng hoặc đơn vị đại diện có thể bộc lộ những vấn đề mà tài liệu yêu cầu và môi trường kiểm thử không thể hiện được.

Điểm quan trọng là pilot phải đủ thực tế. Nếu chỉ chọn những trường hợp đơn giản nhất, kết quả tốt của pilot có thể tạo sự tự tin sai. Phạm vi thử nghiệm nên chứa những quy trình, dữ liệu và ngoại lệ có khả năng đại diện cho vận hành thật.

Kiểm thử cũng không chỉ là xác nhận chức năng. Cần phân biệt:

Kiểm thử chức năng

Xác nhận từng chức năng thực hiện đúng yêu cầu

Kiểm thử tích hợp

Xác nhận dữ liệu và giao dịch đi đúng giữa các hệ thống

Kiểm thử nghiệp vụ đầu-cuối

Xác nhận toàn bộ quy trình hoạt động từ điểm bắt đầu tới kết quả cuối cùng

Kiểm thử chấp nhận người dùng

Xác nhận người dùng có thể thực hiện công việc thực tế trong các điều kiện đã xác định

Kiểm thử tải, phục hồi và tình huống lỗi

Xác nhận hệ thống vẫn có hành vi chấp nhận được khi tải tăng hoặc thành phần phụ thuộc gặp sự cố

Không phải mọi dự án đều cần cùng một mức kiểm thử. Độ sâu phải tương xứng với mức độ quan trọng của quy trình, quy mô thay đổi và hậu quả khi hệ thống ngừng hoặc xử lý sai.

Đưa bảo mật và kiểm soát vào quá muộn

Bảo mật thường trở nên tốn kém hơn khi chỉ được kiểm tra gần ngày go-live. Khi đó kiến trúc, tích hợp, mô hình dữ liệu và phân quyền đã hình thành; một phát hiện nghiêm trọng có thể buộc đội dự án sửa lại những quyết định nền tảng.

Bảo mật cần xuất hiện ngay trong thiết kế dưới các câu hỏi cụ thể: ai được truy cập dữ liệu nào, quyền nào cần tách biệt, tài khoản đặc quyền được quản lý ra sao, dữ liệu nhạy cảm được bảo vệ ở đâu và hệ thống sẽ phát hiện hoặc phản ứng thế nào khi xảy ra sự cố.

NIST Cybersecurity Framework tổ chức quản trị rủi ro an ninh mạng quanh các chức năng Govern, Identify, Protect, Detect, Respond và Recover. Giá trị thực hành của cách nhìn này là không giới hạn bảo mật ở khâu “Protect”. Một hệ thống vẫn cần cơ chế quản trị, nhận diện tài sản và rủi ro, phát hiện bất thường, ứng phó và phục hồi.

Một lỗi phổ biến khác là cấp quyền theo sự tiện lợi ban đầu. Quyền rộng giúp quá trình thử nghiệm nhanh hơn nhưng dễ tồn tại sang môi trường vận hành nếu không có bước rà soát chính thức.

Trước go-live, doanh nghiệp cần xác minh quyền truy cập, tài khoản đặc quyền, nhật ký cần thiết, luồng dữ liệu nhạy cảm, cấu hình bảo mật và trách nhiệm xử lý sự cố. Với hệ thống có yêu cầu pháp lý hoặc tiêu chuẩn ngành, các kiểm soát tương ứng phải được đưa vào yêu cầu và tiêu chí nghiệm thu ngay từ đầu.

Coi đào tạo là đồng nghĩa với quản trị thay đổi

Một buổi hướng dẫn sử dụng có thể giúp nhân viên biết bấm nút nào, nhưng không giải quyết được câu hỏi tại sao họ phải thay đổi cách làm việc.

Kháng cự thường xuất hiện khi công nghệ làm thay đổi quyền quyết định, mức độ minh bạch, trách nhiệm hoặc khối lượng công việc giữa các nhóm. Ví dụ, hệ thống mới có thể yêu cầu dữ liệu phải được nhập tại nguồn thay vì cuối tháng. Về kỹ thuật đây là thay đổi nhỏ; về hành vi, một nhóm nhân viên phải thực hiện thêm công việc ngay lúc giao dịch phát sinh để những bộ phận phía sau nhận được dữ liệu tốt hơn.

Nếu lợi ích thuộc về toàn doanh nghiệp nhưng chi phí thay đổi tập trung vào một nhóm, chỉ yêu cầu nhóm đó “tuân thủ hệ thống mới” thường không đủ.

Quản trị thay đổi cần trả lời rõ:

·         Nhóm nào bị ảnh hưởng

·         Công việc cụ thể nào thay đổi

·         Ai có thể mất quyền kiểm soát hoặc phải nhận thêm trách nhiệm

·         Quản lý trực tiếp sẽ củng cố hành vi mới như thế nào

·         Người dùng nhận hỗ trợ ở đâu khi gặp vấn đề

·         Hành vi sử dụng nào sẽ được đo sau go-live

Tỷ lệ hoàn thành khóa đào tạo không phải bằng chứng đầy đủ cho adoption. Những chỉ số sát thực tế hơn gồm tỷ lệ người dùng hoạt động, tỷ lệ giao dịch thực hiện trên hệ thống, mức sử dụng chức năng trọng yếu, số bước vẫn xử lý ngoài hệ thống và lỗi phát sinh do cách sử dụng.

Nếu các chỉ số này thấp, nguyên nhân cũng không nhất thiết là “người dùng chống đối”. Thiết kế UX kém, quy trình phức tạp, dữ liệu không đáng tin cậy hoặc hiệu năng chậm đều có thể làm adoption giảm. Quản trị thay đổi phải phân biệt vấn đề hành vi với vấn đề của chính hệ thống.

Thiếu quyền sở hữu và cơ chế ra quyết định rõ ràng

Dự án công nghệ doanh nghiệp thường liên quan đến nhiều đơn vị, vì vậy câu hỏi “ai quyết định?” phải được giải quyết trước khi xuất hiện xung đột.

Nếu không có quyền sở hữu rõ ràng, một quyết định về dữ liệu có thể bị trì hoãn giữa IT và nghiệp vụ; một yêu cầu tùy chỉnh có thể được thêm vào mà không ai chịu trách nhiệm về chi phí dài hạn; hoặc hai bộ phận có thể yêu cầu hai cách vận hành trái ngược nhau.

Governance hiệu quả cần phân biệt ít nhất ba loại trách nhiệm:

Business owner chịu trách nhiệm về kết quả nghiệp vụ và quyết định ưu tiên

Technology owner chịu trách nhiệm về kiến trúc, khả năng vận hành và các ràng buộc kỹ thuật

Process/data owner chịu trách nhiệm về quy trình, định nghĩa dữ liệu và các quyết định trong phạm vi chuyên môn

Ranh giới này không loại bỏ nhu cầu phối hợp. Nó làm rõ ai có quyền đưa ra quyết định cuối cùng khi lợi ích giữa các bên xung đột.

Một cơ chế quản trị tốt cũng cần kiểm soát thay đổi phạm vi. Mỗi yêu cầu bổ sung nên được đánh giá ít nhất về giá trị, chi phí, tác động kiến trúc, tác động kiểm thử và chi phí vận hành dài hạn. Nếu mọi yêu cầu đều được xem là “bắt buộc”, phạm vi sẽ mở rộng nhanh hơn khả năng kiểm soát của dự án.

Xem go-live là điểm kết thúc của triển khai

Go-live chỉ chứng minh hệ thống đã chuyển sang trạng thái vận hành. Nó chưa chứng minh công nghệ đã tạo ra kết quả mong muốn.

Trong những tuần đầu, người dùng vẫn đang hình thành thói quen, dữ liệu mới bắt đầu tích lũy và những ngoại lệ thực tế mới xuất hiện. Nếu đội dự án giải tán quá sớm, các workaround có thể hình thành trước khi doanh nghiệp kịp xử lý nguyên nhân.

Giai đoạn sau go-live cần có cơ chế ổn định vận hành và theo dõi các KPI đã xác định từ đầu. Tùy mục tiêu dự án, những chỉ số phù hợp có thể gồm:

·         Adoption rate

·         Tỷ lệ giao dịch hoàn thành trong hệ thống

·         Thời gian chu trình của quy trình

·         Tỷ lệ lỗi hoặc phải làm lại

·         Số lượng và mức độ nghiêm trọng của ticket

·         Chất lượng dữ liệu

·         Tỷ lệ lỗi tích hợp

·         Hiệu năng và mức độ sẵn sàng

·         Chênh lệch ngân sách

·         Time-to-value

Không có một ngưỡng chung phù hợp cho mọi doanh nghiệp. Baseline trước triển khai, mục tiêu kinh doanh và mức độ quan trọng của quy trình mới là căn cứ để đặt target.

Nếu một KPI không cải thiện, việc đầu tiên không phải mặc định kết luận rằng công nghệ thất bại. Doanh nghiệp cần xác định nguyên nhân nằm ở giải pháp, dữ liệu, quy trình, mức sử dụng hay giả định kinh doanh ban đầu. Cách phân tích này biến giai đoạn hậu triển khai thành quá trình cải tiến có kiểm soát thay vì chuỗi xử lý sự cố rời rạc.

Các sai lầm triển khai công nghệ doanh nghiệp có quan hệ với nhau nhiều hơn vẻ bề ngoài. Chọn sai giải pháp có thể tạo ra tùy chỉnh; tùy chỉnh làm tích hợp và kiểm thử phức tạp hơn; dữ liệu yếu làm người dùng mất niềm tin; adoption thấp lại khiến doanh nghiệp không tạo được dữ liệu đủ tốt để đo kết quả.

Vì vậy, kiểm soát rủi ro hiệu quả cần bắt đầu từ trước khi chọn công nghệ và kéo dài sau go-live. Mục tiêu kinh doanh phải dẫn dắt yêu cầu; quy trình và dữ liệu phải được làm rõ trước khi cấu hình; tích hợp, bảo mật và kiểm thử phải được thiết kế từ sớm; quản trị thay đổi phải tập trung vào hành vi thực tế; còn thành công phải được đánh giá bằng kết quả vận hành thay vì chỉ bằng việc hệ thống đã được đưa vào sử dụng.