Cách đánh giá hiện trạng công nghệ doanh nghiệp

Điểm quan trọng là tách hiện trạng khỏi giải pháp tương lai. Trong giai đoạn đánh giá, câu hỏi chính chưa phải “nên mua công nghệ gì”, mà là “năng lực hiện tại đang ở đâu, bằng chứng nào cho thấy điều đó và khoảng cách nào thực sự cần xử lý”. Nếu doanh nghiệp chuyển quá sớm sang lựa chọn nền tảng hoặc nhà cung cấp, kế hoạch công nghệ dễ được xây dựng trên giả định thay vì dữ liệu.

Bắt đầu bằng bản đồ hệ thống và mức độ phụ thuộc nghiệp vụ

Bước đầu tiên là xác định đầy đủ những thành phần công nghệ đang thực sự tham gia vào hoạt động doanh nghiệp. Phạm vi không nên chỉ gồm máy chủ, phần mềm hoặc thiết bị mà bộ phận CNTT trực tiếp quản lý. SaaS do phòng ban tự mua, bảng tính quan trọng, tích hợp thủ công, tài khoản cloud, công cụ nội bộ và hệ thống cũ vẫn tham gia vận hành đều có thể tạo ra phụ thuộc công nghệ.

Một danh mục tối thiểu nên ghi nhận:

·         Tên hệ thống hoặc dịch vụ

·         Chủ sở hữu nghiệp vụ và đơn vị vận hành

·         Quy trình kinh doanh được hỗ trợ

·         Nhóm người dùng và quy mô sử dụng

·         Hạ tầng hoặc nền tảng triển khai

·         Các hệ thống phụ thuộc và luồng tích hợp chính

·         Dữ liệu quan trọng được xử lý

·         Nhà cung cấp, hợp đồng và thời điểm gia hạn

·         Tình trạng hỗ trợ kỹ thuật hoặc vòng đời

·         Mức độ quan trọng đối với hoạt động kinh doanh

Danh mục này chỉ có giá trị khi thể hiện được quan hệ phụ thuộc. Hai ứng dụng có thể hoạt động bình thường khi xem riêng lẻ nhưng một API, quy trình đồng bộ dữ liệu hoặc tác vụ thủ công giữa chúng lại là điểm yếu của toàn quy trình.

Do đó, với từng quy trình trọng yếu, doanh nghiệp nên truy ngược từ nghiệp vụ sang công nghệ: quy trình cần hệ thống nào, hệ thống cần dữ liệu nào, dữ liệu đến từ đâu và thành phần nào có thể làm toàn chuỗi ngừng hoạt động nếu xảy ra sự cố.

Mức hoàn thiện của baseline cũng cần được đo. Có thể theo dõi tỷ lệ tài sản đã xác định chủ sở hữu, tỷ lệ hệ thống đã lập bản đồ phụ thuộc, tỷ lệ ứng dụng có thông tin vòng đời và tỷ lệ hệ thống quan trọng đã có dữ liệu vận hành. Một danh mục dài nhưng thiếu các trường này chưa đủ làm nền cho hoạch định.

Đánh giá hệ thống bằng mức đáp ứng nghiệp vụ và sức khỏe kỹ thuật

Số lượng hệ thống không cho biết công nghệ hiện tại tốt hay xấu. Mỗi hệ thống cần được xem xét đồng thời từ hai phía: giá trị đối với nghiệp vụ và sức khỏe kỹ thuật.

Kiểm tra mức đáp ứng nghiệp vụ

Với mỗi hệ thống quan trọng, cần xác định nó đang hỗ trợ quy trình đến mức nào. Các câu hỏi có giá trị hơn việc hỏi chung chung người dùng có “hài lòng” hay không gồm:

·         Công việc nào vẫn phải nhập lại dữ liệu hoặc xử lý thủ công

·         Bước nào thường xuyên phải đi vòng qua hệ thống

·         Yêu cầu nghiệp vụ quan trọng nào chưa được hỗ trợ

·         Thời gian xử lý có đáp ứng nhu cầu vận hành không

·         Có nhiều công cụ cùng thực hiện một chức năng hay không

·         Dữ liệu đầu ra có đủ chính xác và kịp thời để ra quyết định không

Những biểu hiện này chỉ ra khoảng cách chức năng. Ví dụ, một ERP vẫn chạy ổn định về kỹ thuật nhưng nhân viên phải xuất dữ liệu sang bảng tính để lập kế hoạch hàng ngày thì vấn đề nằm ở mức đáp ứng nghiệp vụ chứ chưa chắc ở độ ổn định của hạ tầng.

Kiểm tra sức khỏe kỹ thuật

Sức khỏe kỹ thuật cần được đánh giá bằng dữ liệu vận hành thay vì các nhãn như “ổn định”, “cũ” hoặc “chậm”. Tùy đặc điểm hệ thống, doanh nghiệp có thể sử dụng:

·         Availability hoặc thời gian gián đoạn

·         Số sự cố theo kỳ

·         Mean Time to Repair/Restore đối với sự cố

·         Thời gian phản hồi của các giao dịch quan trọng

·         Mức sử dụng CPU, bộ nhớ, lưu trữ hoặc tài nguyên cloud

·         Tỷ lệ lỗi của giao dịch hoặc tích hợp

·         Khối lượng thay đổi thất bại

·         Số phiên bản đã hết hoặc sắp hết hỗ trợ

·         Số thành phần phụ thuộc vào công nghệ khó duy trì

·         Kết quả kiểm tra sao lưu, khôi phục và khả năng đáp ứng RTO/RPO đối với hệ thống cần phục hồi

Không có một ngưỡng “tốt” hoặc “xấu” duy nhất cho mọi hệ thống. Một ứng dụng nội bộ ít quan trọng và hệ thống xử lý giao dịch cốt lõi không thể dùng cùng tiêu chuẩn availability, thời gian phục hồi hay mức đầu tư dự phòng. Ngưỡng đánh giá phải gắn với criticality, cam kết dịch vụ và mức tổn thất mà nghiệp vụ có thể chấp nhận.

Kết hợp hai chiều này giúp tránh một sai lầm phổ biến: coi công nghệ cũ là vấn đề chỉ vì tuổi đời. Một hệ thống lâu năm nhưng đáp ứng nghiệp vụ, được hỗ trợ, vận hành ổn định và có chi phí hợp lý có thể chưa phải ưu tiên thay thế. Ngược lại, một nền tảng mới nhưng gây nhiều lỗi, thiếu tích hợp hoặc không được người dùng chấp nhận vẫn là điểm yếu.

Đo năng lực công nghệ thay vì chỉ kiểm kê công cụ

Hiện trạng công nghệ còn phụ thuộc vào khả năng của tổ chức trong việc vận hành và thay đổi hệ thống. Hai doanh nghiệp có thể sử dụng cùng nền tảng nhưng có mức sẵn sàng hoàn toàn khác nhau nếu một bên phụ thuộc vào một vài cá nhân còn bên kia có quy trình, kỹ năng và dữ liệu vận hành đầy đủ.

Năng lực con người

Doanh nghiệp nên lập bản đồ năng lực theo những công nghệ và hoạt động thực sự quan trọng, chẳng hạn kiến trúc, cloud, dữ liệu, tích hợp, bảo mật, quản trị ứng dụng, tự động hóa và hỗ trợ người dùng.

Cần phân biệt giữa “có người biết” và “có năng lực tổ chức”. Một năng lực trở nên mong manh khi kiến thức chỉ nằm ở một cá nhân, tài liệu thiếu, không có người thay thế hoặc phần lớn công việc phải chuyển cho nhà cung cấp mà doanh nghiệp không đủ khả năng kiểm soát.

Các chỉ số có thể theo dõi gồm tỷ lệ vai trò trọng yếu có người dự phòng, tỷ lệ hệ thống quan trọng có tài liệu vận hành cập nhật, khối lượng công việc thuê ngoài và số năng lực mà doanh nghiệp phụ thuộc vào một cá nhân hoặc một nhà cung cấp duy nhất.

Năng lực vận hành và thay đổi

Ngoài kỹ năng, cần xem công nghệ được quản trị như thế nào trong thực tế:

·         Sự cố được ghi nhận và phân tích nguyên nhân ra sao

·         Thay đổi hệ thống có được kiểm thử và kiểm soát hay không

·         Tài sản và cấu hình có được cập nhật không

·         Sao lưu có được kiểm tra khả năng phục hồi hay chỉ xác nhận đã chạy

·         Quyền truy cập có được rà soát định kỳ không

·         Hệ thống có monitoring và cảnh báo phù hợp với mức độ quan trọng không

·         Quy trình triển khai có phụ thuộc nhiều vào thao tác thủ công không

·         Dữ liệu về hiệu suất, sự cố và chi phí có đủ để quản lý hay không

Năng lực yếu thường làm tăng chi phí và rủi ro ngay cả khi bản thân nền tảng chưa lỗi thời. Vì vậy, hoạch định công nghệ không nên mặc định rằng mọi khoảng cách đều phải giải quyết bằng việc mua hoặc thay hệ thống; một phần khoảng cách có thể nằm ở quy trình vận hành, kỹ năng, tài liệu hoặc quản trị.

Tính chi phí công nghệ theo tổng chi phí sở hữu

Chi phí hiện trạng không nên được đánh giá chỉ bằng ngân sách CNTT hoặc phí bản quyền. Doanh nghiệp cần nhìn vào tổng chi phí sở hữu và vận hành của từng nhóm công nghệ để biết tiền đang được tiêu ở đâu và khoản nào không tương xứng với giá trị nhận được.

Các thành phần chi phí nên được tập hợp gồm:

·         Phí license và subscription

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

·         Bảo trì và hỗ trợ

·         Chi phí tích hợp

·         Nhân sự nội bộ dành cho vận hành

·         Dịch vụ thuê ngoài

·         Chi phí nâng cấp bắt buộc

·         Công sức xử lý thủ công do hạn chế của hệ thống

·         Chi phí phát sinh từ sự cố hoặc gián đoạn khi có thể lượng hóa

Phân bổ chi phí đến hệ thống và năng lực nghiệp vụ

Một con số tổng ngân sách không cho biết hệ thống nào đang tạo áp lực chi phí. Cần phân bổ chi phí xuống ứng dụng, nền tảng hoặc dịch vụ đủ chi tiết để so sánh giữa chi phí – mức sử dụng – mức quan trọng – giá trị nghiệp vụ.

Ví dụ, một ứng dụng có license lớn nhưng phục vụ quy trình cốt lõi và được sử dụng rộng rãi chưa chắc là vấn đề. Ngược lại, nhiều SaaS nhỏ có chức năng trùng nhau, tỷ lệ sử dụng thấp và hợp đồng được gia hạn tự động có thể tạo ra phần chi phí lãng phí đáng kể khi cộng lại.

Các chỉ số hữu ích có thể gồm chi phí trên người dùng hoạt động, tỷ lệ license được sử dụng, chi phí vận hành theo ứng dụng, biến động chi phí cloud theo kỳ và tỷ lệ ngân sách dành cho duy trì so với thay đổi. Các chỉ số này nên được so với baseline nội bộ và mục tiêu kinh doanh thay vì áp dụng một benchmark chung không phản ánh mô hình hoạt động của doanh nghiệp.

Chi phí cao chỉ trở thành vấn đề hoạch định khi xác định được nguyên nhân: dư thừa, kiến trúc phức tạp, tài nguyên không tối ưu, hợp đồng bất lợi, nhiều thao tác thủ công, công nghệ khó bảo trì hoặc năng lực nội bộ thiếu. Nếu không xác định nguyên nhân, mục tiêu “giảm chi phí CNTT” rất dễ dẫn tới cắt giảm nhầm các năng lực đang tạo giá trị.

Ghi nhận vấn đề tồn tại theo nguyên nhân, tác động và mức độ ưu tiên

Danh sách phàn nàn không phải là một bản đánh giá hiện trạng. Mỗi vấn đề cần được chuyển thành một statement có thể kiểm chứng, mô tả biểu hiện, nguyên nhân hoặc giả thuyết nguyên nhân, đối tượng bị ảnh hưởng và tác động.

Thay vì ghi “hệ thống chậm”, có thể xác định: thời gian phản hồi của giao dịch nào tăng, xảy ra vào thời điểm nào, bao nhiêu người dùng bị ảnh hưởng và nút thắt nằm ở ứng dụng, cơ sở dữ liệu, mạng hay hệ thống tích hợp.

Thay vì ghi “dữ liệu kém”, cần xác định trường dữ liệu nào sai hoặc thiếu, dữ liệu được tạo ở đâu, có bao nhiêu nguồn cùng duy trì một thực thể và hậu quả đối với báo cáo hoặc quy trình nghiệp vụ là gì.

Một issue register nên tối thiểu ghi nhận:

·         Vấn đề hoặc khoảng cách

·         Hệ thống và quy trình bị ảnh hưởng

·         Bằng chứng quan sát được

·         Nguyên nhân đã xác nhận hoặc giả thuyết cần kiểm chứng

·         Tần suất xảy ra

·         Mức độ tác động

·         Phạm vi người dùng hoặc nghiệp vụ liên quan

·         Phụ thuộc khiến vấn đề khó xử lý

·         Biện pháp kiểm soát hiện có

Cần tách triệu chứng khỏi nguyên nhân. Nhiều sự cố tích hợp có thể cùng bắt nguồn từ dữ liệu chủ không nhất quán; nhiều yêu cầu hỗ trợ có thể đến từ một workflow thiết kế không phù hợp. Nếu doanh nghiệp ưu tiên từng triệu chứng riêng lẻ, roadmap sau đó dễ chứa nhiều dự án nhỏ nhưng không loại bỏ nguyên nhân gốc.

Mức ưu tiên cũng không nên dựa vào người phản ánh lớn tiếng nhất. Có thể chấm từng vấn đề theo các yếu tố như tác động kinh doanh, rủi ro, số người bị ảnh hưởng, tần suất, mức độ khẩn cấp và mức phụ thuộc. Thang điểm 1–5 có thể được sử dụng nếu doanh nghiệp định nghĩa rõ ý nghĩa của từng mức và áp dụng nhất quán.

Tổng hợp hiện trạng thành khoảng cách phục vụ hoạch định

Đầu ra cuối cùng của đánh giá không nên dừng ở các bảng kiểm kê riêng biệt. Doanh nghiệp cần tổng hợp chúng thành một baseline cho thấy năng lực nào đang đủ, năng lực nào đang yếu và khoảng cách nào cần được đưa vào hoạch định.

Mỗi hệ thống hoặc năng lực quan trọng có thể được đánh giá trên một scorecard gồm:

Nếu sử dụng điểm số, thang điểm chỉ có ý nghĩa khi tiêu chí được định nghĩa trước. Chẳng hạn, mức 1–5 của “sức khỏe kỹ thuật” phải gắn với dữ liệu như sự cố, khả năng hỗ trợ, hiệu năng, khả năng phục hồi và mức phức tạp bảo trì; không nên chấm theo cảm nhận chung của người đánh giá.

Sau đó, doanh nghiệp có thể phân biệt ba trạng thái:

·         Giữ và quản lý khi năng lực hiện tại đáp ứng nhu cầu, rủi ro và chi phí nằm trong giới hạn chấp nhận

·         Cải thiện khi nền tảng cơ bản vẫn phù hợp nhưng tồn tại khoảng cách về hiệu năng, tích hợp, vận hành, kỹ năng hoặc chi phí

·         Cần xem xét thay đổi lớn khi khoảng cách mang tính cấu trúc, công nghệ không còn đáp ứng yêu cầu quan trọng hoặc rủi ro không thể xử lý hợp lý trên nền tảng hiện tại

Đây chưa phải quyết định đầu tư. Nó là cơ sở để bước hoạch định sau đó xác định mục tiêu, phương án và thứ tự ưu tiên mà không phải bắt đầu từ giả định.

Một đánh giá hiện trạng công nghệ có giá trị phải trả lời được bốn vấn đề: doanh nghiệp đang có gì, công nghệ đó đang hoạt động và phục vụ nghiệp vụ như thế nào, tổ chức có đủ năng lực và chi phí để duy trì nó hay không, và những khoảng cách nào cần xử lý trước khi tiến tới trạng thái mục tiêu.

Khi các kết luận được gắn với dữ liệu vận hành, chi phí, phụ thuộc nghiệp vụ và bằng chứng về vấn đề thực tế, doanh nghiệp có thể phân biệt rõ giữa hệ thống chỉ “cũ”, hệ thống thực sự tạo rủi ro và năng lực cần được cải thiện. Nhờ đó, hoạch định công nghệ bắt đầu từ một baseline có thể kiểm chứng thay vì từ danh sách công nghệ muốn mua.