Quy trình xây dựng chiến lược công nghệ từng bước

Một quy trình xây dựng chiến lược công nghệ có thể tổ chức thành sáu bước liên kết:

1.    Xác lập mục tiêu kinh doanh và định hướng công nghệ

2.    Đánh giá hiện trạng công nghệ và năng lực hiện có

3.    Xác định trạng thái công nghệ đích

4.    Phân tích khoảng cách và hình thành các sáng kiến

5.    Xây dựng lộ trình và ưu tiên đầu tư

6.    Thiết lập quản trị, KPI và chu kỳ cập nhật chiến lược

Logic này tương đồng với cách các framework kiến trúc và quản trị công nghệ xử lý quá trình chuyển đổi từ trạng thái hiện tại sang trạng thái mục tiêu. TOGAF sử dụng các lớp Architecture Vision, Baseline/Target Architecture, Gap Analysis, Opportunities & Solutions và Migration Planning; ISO/IEC 38500:2024 đặt việc sử dụng công nghệ hiện tại và tương lai trong phạm vi quản trị của tổ chức. Vì vậy, chiến lược chỉ hoàn chỉnh khi kết nối được business objective → capability → technology → initiative → investment → measurable outcome.

Xác lập mục tiêu kinh doanh và định hướng công nghệ

Điểm xuất phát phải là vấn đề kinh doanh cần giải quyết, không phải một công nghệ đang thịnh hành. Một doanh nghiệp muốn rút ngắn thời gian đưa sản phẩm ra thị trường sẽ có chiến lược công nghệ khác doanh nghiệp đang ưu tiên giảm chi phí vận hành, mở rộng quốc tế hoặc kiểm soát rủi ro dữ liệu.

Ở bước này cần làm rõ ba lớp thông tin.

Mục tiêu kinh doanh cần công nghệ hỗ trợ

Các mục tiêu nên đủ cụ thể để sau này có thể kiểm tra mức đóng góp của đầu tư công nghệ, chẳng hạn:

·         Giảm thời gian xử lý đơn hàng

·         Tăng khả năng tự phục vụ của khách hàng

·         Mở rộng một nền tảng sang nhiều thị trường

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

·         Tăng mức tự động hóa của một quy trình

·         Cải thiện khả năng phục hồi của hệ thống trọng yếu

Một mục tiêu như “ứng dụng AI” chưa phải mục tiêu chiến lược. AI là một lựa chọn công nghệ; mục tiêu phải mô tả kết quả doanh nghiệp cần đạt.

Năng lực nào phải được tạo mới hoặc nâng cấp

Sau mục tiêu là năng lực. Ví dụ, muốn cá nhân hóa trải nghiệm khách hàng có thể cần năng lực thu thập dữ liệu thống nhất, nhận diện khách hàng, phân tích hành vi và kích hoạt quyết định theo thời gian phù hợp.

Phân tách mục tiêu khỏi năng lực tránh tình trạng doanh nghiệp đi thẳng từ “muốn tăng trưởng” sang “mua một nền tảng mới” mà chưa chứng minh nền tảng đó giải quyết khoảng trống nào.

Nguyên tắc định hướng cho các quyết định công nghệ

Doanh nghiệp cũng cần thống nhất một số nguyên tắc như ưu tiên cloud hay hybrid, mua hay tự phát triển, chuẩn hóa hay cho phép từng đơn vị tự chủ, API-first hay tích hợp điểm-điểm, ưu tiên nền tảng dùng chung hay ứng dụng chuyên biệt.

Nguyên tắc không phải quyết định kỹ thuật chi tiết. Chúng tạo giới hạn nhất quán để nhiều quyết định đầu tư sau đó không đi theo các hướng đối nghịch.

Đánh giá hiện trạng công nghệ và năng lực hiện có

Không thể xây dựng trạng thái tương lai nếu chưa biết rõ điểm xuất phát. Đánh giá hiện trạng cần nhìn rộng hơn danh mục phần mềm và hạ tầng.

Ít nhất nên xem xét các lớp sau:

·         Kiến trúc ứng dụng

·         Dữ liệu và luồng dữ liệu

·         Hạ tầng và nền tảng

·         Tích hợp giữa các hệ thống

·         An toàn thông tin và khả năng phục hồi

·         Quy trình phát triển, triển khai và vận hành

·         Nhân lực và năng lực chuyên môn

·         Nhà cung cấp và các phụ thuộc bên ngoài

·         Chi phí vận hành và đầu tư

·         Technical debt và các hệ thống sắp hết vòng đời

Một inventory cho biết doanh nghiệp “đang có gì”, nhưng assessment phải trả lời thêm “những gì đang có đáp ứng mục tiêu đến đâu”.

Đánh giá theo năng lực thay vì chỉ theo hệ thống

Hai doanh nghiệp có thể sử dụng cùng một nền tảng nhưng năng lực thực tế rất khác nhau do chất lượng dữ liệu, mức tích hợp, quy trình vận hành và kỹ năng đội ngũ khác nhau.

Vì vậy, từng năng lực nên có ít nhất:

Mức hiện tại → vấn đề → tác động → nguyên nhân → mức cần đạt

Chẳng hạn, nếu dữ liệu khách hàng nằm trên năm hệ thống không có định danh thống nhất, vấn đề chiến lược không phải “có năm hệ thống”, mà là doanh nghiệp chưa hình thành được năng lực tạo một góc nhìn nhất quán về khách hàng.

Tách triệu chứng khỏi nguyên nhân

“Ứng dụng chậm”, “chi phí cloud cao” hay “báo cáo mất nhiều ngày” chỉ là triệu chứng. Nguyên nhân có thể nằm ở kiến trúc, dữ liệu, mô hình vận hành hoặc cách phân bổ nguồn lực.

Nếu chẩn đoán sai nguyên nhân, roadmap sẽ chứa các dự án xử lý triệu chứng và technical debt tiếp tục tích tụ.

Xác định trạng thái công nghệ đích

Trạng thái đích mô tả doanh nghiệp cần có những năng lực và đặc điểm công nghệ nào để thực hiện chiến lược kinh doanh trong khoảng thời gian xác định.

Đây không nhất thiết là một kiến trúc kỹ thuật hoàn chỉnh đến cấp sản phẩm. Ở cấp chiến lược, target state cần đủ chi tiết để xác định hướng đầu tư nhưng vẫn để lại không gian cho thiết kế giải pháp ở giai đoạn triển khai.

Xác định năng lực đích trước sản phẩm đích

Nếu mục tiêu là tăng tốc phát hành sản phẩm, trạng thái đích có thể yêu cầu:

·         Kiến trúc giảm phụ thuộc giữa các thành phần

·         Quy trình CI/CD được chuẩn hóa

·         Testing tự động ở các lớp quan trọng

·         Observability tập trung

·         Môi trường triển khai được tự động hóa

·         Quyền tự chủ cao hơn cho các product team

Chỉ sau khi yêu cầu năng lực được làm rõ mới nên xác định nền tảng hoặc sản phẩm cụ thể.

Mô tả target state trên nhiều lớp

Một target state thực tế thường bao gồm:

Business capability: doanh nghiệp cần làm được gì

Data: dữ liệu nào phải thống nhất, quản trị hoặc có thể khai thác

Application: ứng dụng nào giữ lại, hợp nhất, thay thế hoặc xây mới

Technology platform: hạ tầng và nền tảng cần cung cấp khả năng gì

Security: mô hình kiểm soát, danh tính, bảo vệ và phục hồi cần đạt mức nào

Operating model: đội ngũ nào sở hữu, phát triển và vận hành từng năng lực

Cách tiếp cận này ngăn việc “kiến trúc tương lai” trở thành một sơ đồ kỹ thuật tách rời cách doanh nghiệp thực sự vận hành.

Phân tích khoảng cách và hình thành các sáng kiến công nghệ

Khi baseline và target state đã rõ, khoảng cách giữa hai trạng thái trở thành nguồn hình thành sáng kiến.

TOGAF sử dụng gap analysis giữa kiến trúc hiện tại và kiến trúc đích trước khi chuyển sang Opportunities & Solutions và Migration Planning. Điểm quan trọng của logic này là dự án xuất hiện sau khoảng cách, không phải dự án được chọn trước rồi mới tìm lý do chiến lược để biện minh.

Một gap có thể thuộc nhiều loại:

·         Thiếu một năng lực hoàn toàn mới

·         Năng lực hiện tại chưa đạt mức yêu cầu

·         Hệ thống dư thừa cần loại bỏ

·         Công nghệ cũ phải được thay thế

·         Dữ liệu chưa đủ chất lượng

·         Tích hợp gây phụ thuộc quá lớn

·         Kiểm soát an toàn chưa đạt yêu cầu

·         Nhân lực hoặc operating model chưa đáp ứng target state

Chuyển từng gap thành phương án can thiệp

Một khoảng cách không nhất thiết tương ứng với một dự án. Có thể có nhiều cách xử lý:

·         Thay thế hệ thống

·         Nâng cấp nền tảng hiện tại

·         Tái kiến trúc

·         Mua dịch vụ bên ngoài

·         Chuẩn hóa quy trình

·         Đào tạo hoặc tuyển thêm năng lực

·         Ngừng một ứng dụng không còn tạo giá trị

·         Chấp nhận khoảng cách trong một thời gian nhất định

Đây là điểm cần xem xét trade-off. Một phương án tốt hơn về kiến trúc có thể đắt hơn, chậm hơn hoặc tạo rủi ro chuyển đổi lớn hơn; một giải pháp nhanh có thể làm tăng technical debt.

Vì vậy, lựa chọn sáng kiến phải dựa trên cả giá trị, chi phí, rủi ro, phụ thuộc và khả năng thực thi, không chỉ trên độ hấp dẫn của công nghệ.

Xây dựng lộ trình và ưu tiên đầu tư công nghệ

Danh sách sáng kiến chỉ cho biết doanh nghiệp có thể làm gì. Roadmap phải trả lời làm gì trước, làm gì sau và đầu tư bao nhiêu nguồn lực vào từng nhóm.

Thứ tự triển khai thường chịu ảnh hưởng bởi bốn yếu tố chính:

1.    Giá trị chiến lược

2.    Mức cấp thiết hoặc rủi ro nếu trì hoãn

3.    Sự phụ thuộc giữa các sáng kiến

4.    Năng lực tài chính và nguồn lực thực thi

Một dự án có giá trị cao chưa chắc được triển khai đầu tiên nếu nó phụ thuộc vào nền tảng dữ liệu hoặc hạ tầng chưa tồn tại.

Sử dụng mô hình chấm điểm thay cho xếp hạng cảm tính

Doanh nghiệp có thể tạo scorecard có trọng số, chẳng hạn:

Các tỷ trọng trên là ví dụ thiết kế, không phải benchmark áp dụng cho mọi doanh nghiệp. Điểm quan trọng là tiêu chí và trọng số phải được thống nhất trước khi chấm dự án, nếu không quá trình ưu tiên dễ bị chi phối bởi đơn vị có tiếng nói mạnh nhất.

Quản trị danh mục của PMI cũng đặt việc lựa chọn, ưu tiên, cân bằng và phân bổ nguồn lực vào mối quan hệ trực tiếp với mục tiêu chiến lược. Điều đó giải thích vì sao technology roadmap không nên tồn tại độc lập với investment portfolio.

Roadmap phải thể hiện sự phụ thuộc

Một roadmap hữu ích cần cho thấy:

·         Sáng kiến

·         Kết quả hoặc capability được tạo ra

·         Thời điểm hoặc giai đoạn

·         Dependency

·         Chủ sở hữu

·         Chi phí hoặc nguồn lực dự kiến

·         Rủi ro lớn

·         Điều kiện để bắt đầu

·         KPI hoặc outcome cần đạt

Các sáng kiến nền tảng có thể không tạo doanh thu trực tiếp nhưng vẫn phải được ưu tiên nếu những sáng kiến giá trị cao hơn không thể vận hành nếu thiếu chúng.

Thiết lập quản trị, KPI và chu kỳ cập nhật chiến lược

Chiến lược công nghệ không kết thúc khi roadmap được phê duyệt. Công nghệ, ngân sách, mục tiêu kinh doanh và rủi ro đều thay đổi; vì vậy roadmap cần được quản trị như một danh mục đầu tư có thể điều chỉnh.

ISO/IEC 38500:2024 đặt cả việc sử dụng công nghệ hiện tại và tương lai trong phạm vi governance của tổ chức. Điều này nhấn mạnh một điểm quan trọng: trách nhiệm đối với đầu tư công nghệ không chỉ nằm ở bộ phận IT mà còn thuộc cơ chế quản trị của tổ chức.

Gắn từng sáng kiến với outcome đo được

KPI nên phản ánh mục tiêu của sáng kiến thay vì chỉ đo việc dự án đã hoàn thành.

Ví dụ:

“Triển khai xong nền tảng” là output. “Thời gian phát hành giảm từ X xuống Y” mới là outcome có thể dùng để đánh giá giả thuyết chiến lược.

Thiết lập cơ chế quyết định

Governance cần làm rõ:

·         Ai sở hữu chiến lược công nghệ

·         Ai phê duyệt investment portfolio

·         Ai chịu trách nhiệm cho từng capability

·         Khi nào một sáng kiến được tiếp tục, thay đổi hoặc dừng

·         Kiến trúc nào là bắt buộc và ngoại lệ được phê duyệt ra sao

·         KPI nào được xem xét ở từng cấp quản trị

Nếu không có quyền quyết định rõ ràng, roadmap dễ trở thành danh sách mong muốn trong khi các đơn vị vẫn đầu tư công nghệ độc lập.

Đánh giá lại thay vì khóa cứng roadmap

Chu kỳ review có thể theo quý, nửa năm hoặc theo chu kỳ hoạch định của doanh nghiệp. Tần suất cụ thể phụ thuộc tốc độ thay đổi của ngành và quy mô danh mục.

Mỗi lần review nên kiểm tra lại ba câu hỏi:

1.    Giả định kinh doanh ban đầu còn đúng không

2.    Các sáng kiến đang tạo ra outcome dự kiến không

3.    Thay đổi về công nghệ, rủi ro hoặc nguồn lực có làm thứ tự ưu tiên thay đổi không

Một chiến lược tốt vì vậy vừa tạo định hướng dài hạn vừa cho phép điều chỉnh con đường thực hiện khi dữ liệu mới xuất hiện.

Quy trình xây dựng chiến lược công nghệ có thể được hiểu như một chuỗi quyết định liên tục: mục tiêu kinh doanh → hiện trạng → trạng thái đích → khoảng cách → sáng kiến → roadmap và đầu tư → quản trị kết quả.

Điểm dễ sai nhất là bắt đầu bằng sản phẩm hoặc dự án. Khi công nghệ được chọn trước vấn đề, doanh nghiệp có thể hoàn thành nhiều dự án nhưng vẫn không tạo ra năng lực cần thiết. Ngược lại, khi mỗi khoản đầu tư có thể truy ngược về một capability gap và một mục tiêu kinh doanh, roadmap trở thành công cụ phân bổ nguồn lực chiến lược thay vì danh sách dự án IT.

Một chiến lược công nghệ cũng không cần dự đoán chính xác mọi công nghệ của vài năm tới. Nó cần xác định đủ rõ trạng thái đích, nguyên tắc lựa chọn, thứ tự ưu tiên và cơ chế điều chỉnh để doanh nghiệp biết đầu tư vào đâu, vì sao đầu tư và khi nào cần thay đổi quyết định.

Quy trình xây dựng chiến lược công nghệ thường mất bao lâu?

Không có một thời lượng chuẩn cho mọi tổ chức. Thời gian phụ thuộc quy mô doanh nghiệp, số lượng hệ thống, mức phân tán của dữ liệu, phạm vi chiến lược và chất lượng thông tin hiện trạng. Phạm vi càng rộng thì baseline assessment, target-state design và thống nhất investment portfolio càng cần nhiều vòng làm việc với các bên liên quan.

Ai nên tham gia xây dựng chiến lược công nghệ?

CIO hoặc CTO thường giữ vai trò quan trọng nhưng không nên xây dựng chiến lược một mình. Lãnh đạo kinh doanh xác lập outcome và ưu tiên; kiến trúc sư, đội dữ liệu, bảo mật và vận hành đánh giá khả năng kỹ thuật; tài chính hỗ trợ phân bổ vốn; các chủ sở hữu sản phẩm hoặc quy trình xác nhận giá trị thực tế. Thành phần cụ thể phụ thuộc operating model của tổ chức.

Chiến lược công nghệ khác roadmap công nghệ như thế nào?

Chiến lược xác định mục tiêu, năng lực đích, nguyên tắc và logic đầu tư. Roadmap chuyển chiến lược đó thành trình tự sáng kiến theo thời gian, dependency và nguồn lực. Có roadmap mà không có chiến lược dễ dẫn tới danh sách dự án; có chiến lược mà không có roadmap lại thiếu cơ chế chuyển định hướng thành thực thi.

Bao lâu nên cập nhật chiến lược công nghệ một lần?

Không nên chỉ cập nhật khi hết thời hạn của một kế hoạch nhiều năm. Doanh nghiệp có thể review định kỳ theo quý, nửa năm hoặc chu kỳ hoạch định riêng, đồng thời thực hiện review bất thường khi chiến lược kinh doanh, quy định, rủi ro, ngân sách hoặc điều kiện công nghệ thay đổi đáng kể. Mục tiêu của review không phải viết lại toàn bộ chiến lược mà là kiểm tra giả định và điều chỉnh danh mục đầu tư khi cần.