Những sai lầm chiến lược công nghệ thường gặp

Vì vậy, một chiến lược có thể lựa chọn đúng công nghệ nhưng vẫn thất bại nếu công nghệ đó giải quyết sai nhu cầu, xuất hiện sai thời điểm hoặc phụ thuộc vào những năng lực mà tổ chức chưa có. Institute for Manufacturing thuộc University of Cambridge cũng đặt trọng tâm của technology roadmapping vào việc liên kết đầu ra của phát triển công nghệ với nhu cầu chiến lược về sản phẩm, dịch vụ và hiệu năng hệ thống.

Các sai lầm chiến lược công nghệ thường không tồn tại độc lập. Chọn giải pháp quá sớm có thể kéo theo đánh giá sai ưu tiên; đánh giá sai ưu tiên tạo ra roadmap thiếu logic; roadmap thiếu logic lại làm chi phí, phụ thuộc kỹ thuật và áp lực nguồn lực tăng lên. Do đó, vấn đề cần kiểm tra không chỉ là “công nghệ nào tốt”, mà là chuỗi quyết định từ nhu cầu đến đầu tư có nhất quán và khả thi hay không.

Bắt đầu từ công nghệ thay vì nhu cầu kinh doanh

Một sai lầm phổ biến là xây dựng chiến lược từ câu hỏi “nên triển khai công nghệ nào?” trước khi xác định tổ chức đang cần thay đổi kết quả kinh doanh nào.

Cách tiếp cận này dễ xuất hiện khi AI, cloud, tự động hóa hoặc một nền tảng mới trở thành xu hướng. Đội ngũ nhanh chóng hình thành danh sách giải pháp rồi mới tìm bài toán để biện minh cho khoản đầu tư. Khi đó, công nghệ trở thành mục tiêu thay vì phương tiện.

Một nhu cầu chiến lược nên được làm rõ theo chuỗi:

Mục tiêu kinh doanh → vấn đề hoặc khoảng cách năng lực → năng lực cần tạo ra → yêu cầu công nghệ → phương án đầu tư

Nếu đảo chuỗi thành “công nghệ → ứng dụng tiềm năng → lợi ích kỳ vọng”, tổ chức rất dễ tối ưu tính năng trong khi chưa chứng minh được giá trị cần tạo.

Ví dụ, mục tiêu “ứng dụng AI vào chăm sóc khách hàng” vẫn thiên về giải pháp. Một mục tiêu hữu ích hơn là xác định doanh nghiệp cần giảm thời gian phản hồi, tăng tỷ lệ xử lý ngay lần đầu hay giảm khối lượng tác vụ thủ công. Chỉ khi kết quả cần cải thiện đã rõ mới có cơ sở quyết định AI, cải tiến quy trình, nâng chất lượng dữ liệu hay một thay đổi khác mới là phương án thích hợp.

ISO/IEC 38500:2024 về quản trị công nghệ thông tin cũng đặt việc sử dụng IT trong phạm vi quản trị tổ chức, thay vì xem công nghệ là một miền quyết định tách biệt. Điều này phản ánh nguyên tắc quan trọng: quyết định công nghệ phải phục vụ hướng đi và nhu cầu của tổ chức.

Sai lầm vì thế không nằm ở việc quan tâm đến công nghệ mới. Nó nằm ở việc để khả năng của công nghệ định nghĩa nhu cầu thay cho nhu cầu định nghĩa yêu cầu công nghệ.

Hoạch định khi chưa hiểu năng lực và kiến trúc hiện tại

Một chiến lược có thể mô tả trạng thái tương lai rất hấp dẫn nhưng vẫn thiếu khả thi nếu không xác định chính xác điểm xuất phát.

Điểm xuất phát không chỉ gồm danh sách phần mềm và hạ tầng. Nó còn bao gồm kiến trúc, dữ liệu, tích hợp, quy trình, kỹ năng, nhà cung cấp, hợp đồng, mức độ phụ thuộc, an toàn thông tin và năng lực vận hành.

Nếu bỏ qua baseline này, ba loại sai lệch thường xuất hiện.

Thứ nhất, tổ chức có thể lên kế hoạch xây một năng lực mới trên nền tảng chưa đáp ứng điều kiện tiên quyết. Một sáng kiến phân tích dữ liệu nâng cao chẳng hạn sẽ khó tạo giá trị nếu dữ liệu nguồn thiếu nhất quán, quyền sở hữu dữ liệu chưa rõ hoặc các hệ thống cốt lõi chưa thể tích hợp ổn định.

Thứ hai, chi phí chuyển đổi dễ bị đánh giá thấp. Chi phí thực tế không chỉ là giấy phép hoặc triển khai giải pháp mới mà còn có di chuyển dữ liệu, tích hợp, kiểm thử, thay đổi quy trình, đào tạo, xử lý hệ thống cũ và vận hành song song trong giai đoạn chuyển tiếp.

Thứ ba, tổ chức dễ tạo thêm technical debt. Một giải pháp giải quyết được nhu cầu trước mắt nhưng không phù hợp với kiến trúc mục tiêu có thể tạo thêm giao diện tích hợp, dữ liệu trùng lặp và phụ thuộc riêng biệt phải xử lý về sau.

Vì vậy, trước khi hoạch định trạng thái đích cần phân biệt ít nhất ba loại khoảng cách:

·         Khoảng cách giữa năng lực hiện tại và năng lực kinh doanh cần có

·         Khoảng cách giữa kiến trúc hiện tại và kiến trúc cần thiết

·         Khoảng cách giữa năng lực thực thi hiện tại và năng lực cần để chuyển đổi

Đánh giá hiện trạng không nhằm mô tả toàn bộ hệ thống thật chi tiết. Giá trị của nó là phát hiện những ràng buộc có thể thay đổi thứ tự, chi phí hoặc tính khả thi của lựa chọn chiến lược.

Chọn công nghệ theo tính năng, xu hướng hoặc mức độ mới

Một công nghệ có nhiều chức năng hơn không đồng nghĩa với một lựa chọn chiến lược tốt hơn.

Nếu đánh giá chủ yếu qua demo, bảng tính năng hoặc mức độ phổ biến, tổ chức có thể bỏ qua những yếu tố quyết định hiệu quả trong toàn bộ vòng đời. Một lựa chọn hợp lý phải được xem xét đồng thời qua giá trị, khả năng tích hợp, tổng chi phí sở hữu, khả năng mở rộng, rủi ro, năng lực vận hành và mức độ phụ thuộc vào nhà cung cấp.

Chỉ nhìn chi phí mua mà bỏ qua tổng chi phí sở hữu

Hai giải pháp có giá mua tương đương vẫn có thể tạo ra cấu trúc chi phí rất khác nhau. Các khoản cần tính đến có thể gồm triển khai, tích hợp, dữ liệu, hạ tầng, đào tạo, hỗ trợ, nâng cấp, vận hành và chi phí chuyển đổi khi muốn rời khỏi nền tảng.

Do đó, so sánh chỉ bằng CAPEX hoặc phí thuê bao ban đầu dễ làm sai thứ tự ưu tiên.

Bỏ qua khả năng tích hợp và phụ thuộc

Một hệ thống hoạt động tốt khi đứng riêng chưa chắc hoạt động tốt trong kiến trúc doanh nghiệp.

Nếu phải tạo nhiều tích hợp tùy biến, phụ thuộc vào định dạng độc quyền hoặc không có đường thoát dữ liệu rõ ràng, chi phí thay đổi trong tương lai có thể tăng đáng kể. Vendor lock-in không phải lúc nào cũng cần tránh tuyệt đối; vấn đề là tổ chức phải biết đang đánh đổi điều gì để nhận được tốc độ, chức năng hoặc mức đơn giản nào.

Đánh giá rủi ro quá muộn

Bảo mật, quyền riêng tư, yêu cầu pháp lý và khả năng phục hồi không nên chỉ xuất hiện ở bước phê duyệt cuối.

NIST Cybersecurity Framework 2.0 đưa “Govern” thành một chức năng riêng và yêu cầu quyết định quản trị rủi ro phải hiểu bối cảnh tổ chức, sứ mệnh, kỳ vọng của các bên liên quan cùng nghĩa vụ pháp lý và hợp đồng. Với hoạch định công nghệ, điều đó có nghĩa rủi ro phải tham gia vào tiêu chí lựa chọn ngay từ đầu.

Một phương án có ROI dự kiến cao nhưng tạo ra mức rủi ro vượt khả năng chấp nhận của tổ chức không phải lựa chọn tối ưu chỉ vì lợi ích tài chính lớn hơn.

Biến roadmap thành danh sách dự án thay vì chuỗi phụ thuộc

Một roadmap chứa đầy dự án, mốc thời gian và màu trạng thái vẫn có thể không phải là một lộ trình chiến lược.

Roadmap chỉ có giá trị khi thể hiện được quan hệ giữa mục tiêu, năng lực, công nghệ và thời gian. Institute for Manufacturing của University of Cambridge coi roadmapping là kỹ thuật hoạch định giúp tạo sự rõ ràng cho vấn đề phức tạp và tạo sự đồng thuận về mục tiêu; technology roadmap đặc biệt phải liên kết phát triển công nghệ với nhu cầu chiến lược.

Sai lầm thường gặp là đưa hàng loạt sáng kiến lên trục thời gian nhưng không thể trả lời vì sao dự án B phải diễn ra sau dự án A.

Một roadmap khả thi cần nhận diện ít nhất bốn loại phụ thuộc:

·         Phụ thuộc năng lực: Một năng lực nền phải có trước khi năng lực cao hơn vận hành được

·         Phụ thuộc dữ liệu: Chất lượng, quyền sở hữu hoặc luồng dữ liệu phải được xử lý trước ứng dụng phía sau

·         Phụ thuộc kiến trúc: Nền tảng, API hoặc hạ tầng phải sẵn sàng trước hệ thống sử dụng chúng

·         Phụ thuộc nguồn lực: Cùng một đội ngũ không thể thực thi đồng thời số lượng chương trình vượt quá năng lực thực tế

Ví dụ, doanh nghiệp có thể muốn triển khai AI dự báo, tự động hóa quyết định và dashboard quản trị trong cùng năm. Nhưng nếu cả ba phụ thuộc vào một chương trình chuẩn hóa dữ liệu chưa hoàn thành, xếp chúng thành ba dự án song song chỉ tạo cảm giác tiến độ chứ không làm lộ trình khả thi hơn.

Roadmap vì vậy phải thể hiện logic enable → build → scale, không chỉ “Q1 → Q2 → Q3”.

Khi một sáng kiến bị lùi, tổ chức cũng cần biết những hạng mục nào phía sau bị ảnh hưởng. Nếu roadmap không thể trả lời câu hỏi đó, nó đang hoạt động giống lịch dự án hơn là công cụ hoạch định chiến lược.

Đánh giá thấp năng lực thực thi và quản trị thay đổi

Một chiến lược công nghệ không thể khả thi nếu giả định tổ chức có nguồn lực vô hạn hoặc mọi thay đổi kỹ thuật sẽ tự động được người dùng tiếp nhận.

Khoảng cách giữa chiến lược và thực thi là rủi ro có thể quan sát được ở cấp tổ chức. Nghiên cứu PMI công bố năm 2025 trên hơn 5.800 người tham gia cho thấy 35% lãnh đạo được khảo sát coi sự tách rời giữa hoạch định và thực thi là rào cản lớn nhất đối với quá trình tái tạo tổ chức. Theo định nghĩa thành công dựa trên giá trị của nghiên cứu này, 13% dự án thất bại và 37% chỉ mang lại một phần kết quả kỳ vọng. Các con số này không riêng cho dự án công nghệ, nhưng cho thấy một kế hoạch tốt trên giấy chưa bảo đảm giá trị nếu năng lực thực thi không tương ứng.

Trong hoạch định công nghệ, năng lực thực thi cần được kiểm tra trên nhiều lớp:

·         Đủ người có kỹ năng cần thiết hay không

·         Đội ngũ vận hành có thể tiếp nhận thêm hệ thống hay không

·         Các đơn vị nghiệp vụ có đủ thời gian tham gia thiết kế và thay đổi quy trình hay không

·         Dữ liệu và kiến trúc nền đã đủ trưởng thành hay chưa

·         Cơ chế ra quyết định có xử lý được xung đột ưu tiên hay không

Một lỗi đặc biệt phổ biến là tính công suất theo số người mà không tính sự khan hiếm của năng lực chuyên biệt. Doanh nghiệp có thể có hàng chục nhân sự IT nhưng chỉ có một vài kiến trúc sư, chuyên gia dữ liệu hoặc chuyên gia an toàn thông tin cần cho nhiều chương trình cùng lúc. Chính điểm nghẽn này mới quyết định số sáng kiến có thể chạy song song.

Quản trị thay đổi cũng phải được coi là một phần của đầu tư công nghệ. Nếu người dùng không thay đổi hành vi, quy trình không được thiết kế lại hoặc KPI vẫn khuyến khích cách làm cũ, hệ thống mới có thể được triển khai về mặt kỹ thuật nhưng giá trị kinh doanh vẫn không xuất hiện.

Do đó, “có thể xây” và “có thể tạo giá trị trong tổ chức” là hai tiêu chuẩn khác nhau.

Đóng cứng chiến lược và thiếu cơ chế đo lường điều chỉnh

Chiến lược công nghệ có tính dài hạn nhưng không thể dựa trên giả định rằng nhu cầu, công nghệ, chi phí và rủi ro sẽ giữ nguyên trong suốt lộ trình.

Sai lầm thường xuất hiện ở hai cực. Một bên thay đổi ưu tiên liên tục theo xu hướng mới khiến roadmap mất ổn định. Bên còn lại coi roadmap đã được phê duyệt là kế hoạch cố định và tiếp tục đầu tư ngay cả khi những giả định ban đầu không còn đúng.

Cách phù hợp hơn là giữ ổn định hướng chiến lược nhưng kiểm tra định kỳ các giả định và quyết định đầu tư.

Mỗi sáng kiến quan trọng nên có tiêu chí đủ rõ để trả lời:

·         Giá trị kinh doanh nào phải xuất hiện

·         Chỉ số nào chứng minh giá trị đó

·         Điều kiện hoặc phụ thuộc nào phải hoàn thành trước giai đoạn tiếp theo

·         Mức chi phí và rủi ro nào còn được chấp nhận

·         Dấu hiệu nào buộc phải điều chỉnh, trì hoãn hoặc dừng đầu tư

Cơ chế này biến roadmap từ tài liệu dự báo thành công cụ ra quyết định.

Chẳng hạn, một chương trình không nên tự động chuyển từ thử nghiệm sang mở rộng chỉ vì đã đến mốc thời gian dự kiến. Quyết định mở rộng cần phụ thuộc vào bằng chứng: mức sử dụng thực tế, cải thiện KPI, khả năng vận hành, rủi ro, chi phí trên đơn vị giá trị hoặc các điều kiện thành công đã đặt ra từ trước.

ISO/IEC 38500:2024 nhấn mạnh việc quản trị cả việc sử dụng IT hiện tại và tương lai. Tinh thần này đặc biệt quan trọng với chiến lược công nghệ: phê duyệt đầu tư không kết thúc trách nhiệm quản trị; kết quả phải tiếp tục được theo dõi để điều chỉnh hướng đi.

Một roadmap tốt vì thế không phải roadmap “không thay đổi”. Đó là roadmap có nguyên tắc rõ ràng về điều gì được giữ ổn định, điều gì được phép thay đổi và bằng chứng nào kích hoạt thay đổi.

Những sai lầm nguy hiểm nhất trong chiến lược công nghệ thường không đến từ việc chọn một công nghệ hoàn toàn sai, mà từ việc phá vỡ logic giữa nhu cầu → năng lực → lựa chọn → phụ thuộc → nguồn lực → giá trị.

Khi nhu cầu kinh doanh chưa rõ, hiện trạng chưa được đánh giá, tiêu chí lựa chọn thiên về tính năng, roadmap không phản ánh phụ thuộc hoặc năng lực thực thi bị đánh giá quá cao, khoản đầu tư có thể hợp lý khi xét riêng từng dự án nhưng thiếu hợp lý khi nhìn ở cấp danh mục.

Muốn tránh đầu tư lệch nhu cầu và lộ trình thiếu khả thi, tổ chức cần kiểm tra chiến lược công nghệ bằng một nguyên tắc nhất quán: mỗi khoản đầu tư phải chứng minh được nó phục vụ mục tiêu nào, tạo năng lực nào, phụ thuộc điều gì, cần nguồn lực nào, tạo giá trị nào và trong điều kiện nào quyết định đó phải được xem xét lại.