Chuyên môn vẫn là nền tảng, nhưng trách nhiệm lớn hơn là lựa chọn đúng ưu tiên, phân bổ nguồn lực và theo đuổi đến cùng kết quả kinh doanh.
Một trưởng nhóm công nghệ có thể rất giỏi trong việc xử lý sự cố, tháo gỡ vướng mắc và đưa dự án về đích. Đội ngũ tin tưởng vì khi gặp việc khó, đã có người giải quyết. Nhưng khi phạm vi quản lý mở rộng, nếu mọi quyết định vẫn phải chờ người đứng đầu, cách làm ấy sẽ giới hạn khả năng phát triển của cả đội.
Ở vị trí CIO, nhiều vấn đề không có đủ dữ kiện để đưa ra một đáp án chắc chắn. Doanh nghiệp cần tăng trưởng, ngân sách có hạn, nhưng hệ thống vẫn phải phục vụ khách hàng mỗi ngày. Người lãnh đạo phải lựa chọn trong những điều kiện đó và chịu trách nhiệm về ảnh hưởng của lựa chọn đó đối với toàn bộ tổ chức.
Theo tôi, tư duy hệ thống bắt đầu từ việc nhìn thấy mối liên hệ giữa công nghệ với kinh doanh, dữ liệu, con người và rủi ro. Khi xem xét một sáng kiến, tôi thường đặt ra 4 câu hỏi.
Doanh nghiệp thực sự cần giải quyết vấn đề gì
“Ứng dụng trí tuệ nhân tạo”, “chuyển lên đám mây” hay “thay hệ thống” mới chỉ mô tả việc định làm. Trước khi bàn giải pháp, cần xác định khách hàng đang gặp trở ngại gì, hoạt động nào đang chậm, chi phí nào đang tăng và kết quả nào cần cải thiện.
Cùng là đầu tư điện toán đám mây, doanh nghiệp muốn rút ngắn thời gian ra mắt sản phẩm sẽ có cách ưu tiên khác với doanh nghiệp chủ yếu cần mở rộng năng lực xử lý. Mục tiêu càng rõ ràng, việc lựa chọn kiến trúc và phân bổ ngân sách càng có cơ sở.
Với công cụ AI hỗ trợ nhân viên, câu hỏi cũng phải đi xa hơn khả năng tạo ra một câu trả lời. Thời gian tiết kiệm được sẽ giúp xử lý thêm bao nhiêu công việc? Nhân viên có cần kiểm tra kỹ hơn không? Ai chịu trách nhiệm về chất lượng cuối cùng? Chỉ khi làm rõ những điều này, doanh nghiệp mới có thể đánh giá hiệu quả thực tế.
Chọn phương án nào và chấp nhận đánh đổi điều gì
Một phương án phù hợp phải xét cả năng lực hiện tại lẫn khả năng duy trì lâu dài. Mua giải pháp có thể rút ngắn thời gian triển khai, nhưng đi kèm với chi phí tích hợp và sự phụ thuộc vào nhà cung cấp. Tự phát triển giúp chủ động hơn ở những năng lực tạo khác biệt, song đòi hỏi đội ngũ đủ sức nâng cấp, bảo trì và vận hành trong nhiều năm.
Tương tự, một thử nghiệm hẹp có thể giúp kiểm chứng nhu cầu nhanh chóng. Nhưng nếu nhiều sáng kiến cùng vướng vào dữ liệu phân mảnh hoặc quy trình thiếu thống nhất, doanh nghiệp cần xây dựng một nền tảng chung. Khi thay hệ thống, việc lựa chọn thay từng phần hay toàn bộ còn phụ thuộc vào khả năng tách các chức năng và mức độ rủi ro trong quá trình chuyển đổi.
Điều CIO cần trình bày rõ là vì sao lựa chọn này phù hợp vào thời điểm này, doanh nghiệp chấp nhận điều gì và giới hạn chấp nhận ở đâu. Nếu chi phí vận hành vượt dự kiến hoặc đội ngũ không đủ khả năng tiếp quản, phương án cần được xem xét lại. Sự nhất quán nằm ở mục tiêu kinh doanh; cách thực hiện cần thích ứng với bằng chứng mới.
Ai chịu trách nhiệm đưa quyết định thành kết quả
Một dự án có thể hoàn thành đúng tiến độ nhưng chưa tạo ra lợi ích như mong đợi. Phần mềm đã hoạt động, song nhân viên vẫn dùng cách cũ; báo cáo đã có, song người quản lý vẫn chưa thay đổi cách ra quyết định. Vì vậy, trách nhiệm phải tiếp tục sau ngày đưa hệ thống vào vận hành.
Ngay từ đầu, cần xác định lãnh đạo nghiệp vụ chịu trách nhiệm về kết quả và việc thay đổi quy trình. CIO cùng đội ngũ công nghệ chịu trách nhiệm về giải pháp, khả năng tích hợp và chất lượng vận hành. Hai bên thống nhất về hiện trạng ban đầu, các chỉ số cần cải thiện, thời điểm đánh giá và người tiếp quản lâu dài.
Chẳng hạn, nếu mục tiêu là rút ngắn thời gian xử lý hồ sơ, cần đo lường toàn bộ quá trình, kể cả kiểm tra và sửa sai. Một công đoạn chạy nhanh hơn nhưng làm tăng công việc ở công đoạn sau chưa chắc đã giúp doanh nghiệp hiệu quả hơn.
Trình bày để ban điều hành có thể quyết định
Khi làm việc với Tổng giám đốc (CEO) và Giám đốc tài chính (CFO), CIO cần chuyển các lựa chọn kỹ thuật thành các hệ quả kinh doanh dễ đánh giá. Chi tiết kiến trúc vẫn quan trọng, nhất là khi ảnh hưởng đến rủi ro hoặc khả năng mở rộng, nhưng cần được giải thích trong mối liên hệ với quyết định đang xin phê duyệt.
Một trang đề xuất nên làm rõ vấn đề, đưa ra 2 hoặc 3 phương án khả thi, lợi ích kỳ vọng, tổng chi phí và các rủi ro chính. Chi phí phải tính cả chi phí tích hợp, chuyển đổi, đào tạo và vận hành. Cuối cùng là phương án kiến nghị, thời điểm có thể đánh giá kết quả và những giả định còn cần được kiểm chứng.
Tài chính cần thấy hiệu quả sử dụng vốn; kinh doanh cần biết khi nào phục vụ được khách hàng; vận hành cần biết hệ thống sẽ được bảo đảm ra sao. Một đề xuất có sức thuyết phục phải kết nối được những yêu cầu đó.
Khi phải vừa đổi mới vừa bảo vệ hoạt động hiện tại
Hãy đặt mình vào tình huống giả định: CEO muốn có kết quả AI trong 6 tháng, trong khi hệ thống ngân hàng lõi đang được nâng cấp và những nhân sự chủ chốt đã tập trung cho dự án này.
Dồn lực sang AI có thể khiến tiến độ hệ thống lõi bị ảnh hưởng. Việc hoãn toàn bộ AI lại làm chậm quá trình học hỏi của tổ chức. Tôi sẽ cân nhắc một phạm vi AI đủ hẹp, có giá trị rõ ràng và có thể triển khai bằng nguồn lực riêng, đồng thời vẫn giữ nguyên mức độ ưu tiên cho hệ thống lõi.
Ví dụ, có thể thử nghiệm trợ lý tra cứu cho một nhóm quy trình nội bộ đã được phê duyệt. Phạm vi dữ liệu và quyền truy cập phải được kiểm soát; nhân viên phải kiểm tra câu trả lời trước khi sử dụng. Đơn vị nghiệp vụ hưởng lợi cùng chịu trách nhiệm, bộ phận rủi ro và tuân thủ tham gia từ khâu thiết kế, còn tài chính thống nhất cách tính hiệu quả.
Cam kết với CEO có thể là bằng chứng ban đầu sau 90 ngày, và quyết định mở rộng, điều chỉnh hoặc dừng lại vào tháng thứ sáu. Nếu chưa bố trí được nhân sự riêng hoặc chưa đáp ứng được yêu cầu về dữ liệu, tôi sẽ thu hẹp thêm phạm vi. Một thử nghiệm nhỏ vẫn cần những điều kiện triển khai nghiêm túc.
Một góc nhìn từ hành trình đa đám mây của VIB
Hành trình đa đám mây của VIB là một ví dụ về một lựa chọn có đánh đổi. Năm 2021, ngân hàng đã đưa một số ứng dụng lên AWS và mở rộng hợp tác với Microsoft để triển khai Azure. Việc sử dụng nhiều nền tảng cho phép lựa chọn giải pháp phù hợp với từng nhu cầu, đồng thời làm tăng yêu cầu về quản trị và phối hợp vận hành. Trong chia sẻ công bố năm đó, tôi cũng đề cập đến những thách thức về tư duy, kỹ năng và sự kết nối giữa hệ thống cũ và hệ thống mới.
MyVIB 2.0 được đưa vào hoạt động trên Azure từ tháng 5/2022. Theo bài viết của Microsoft công bố vào tháng 4/2023, kiến trúc chia ứng dụng thành các dịch vụ nhỏ giúp đội ngũ có thể cập nhật nhiều lần trong ngày khi cần thiết. Thời gian chuẩn bị hạ tầng, trước đây kéo dài từ vài tháng đến khoảng một năm, được rút ngắn xuống còn tối đa 2 tuần trên đám mây. [2]
Dưới góc độ quản trị, tôi nhìn những kết quả này như một năng lực cần được chuyển hóa thành lợi ích kinh doanh. Khi thời gian chờ hạ tầng giảm, doanh nghiệp có thêm điều kiện để đưa các cải tiến đến khách hàng sớm hơn. Tuy nhiên, mức đóng góp thực tế còn phụ thuộc vào việc xác định đúng nhu cầu và tổ chức thực hiện. Tốc độ triển khai là một thước đo quan trọng, nhưng vẫn phải được đặt cạnh chất lượng dịch vụ và tổng chi phí.
Nếu bắt đầu lại tôi sẽ chú trọng điều gì hơn
Điều đầu tiên tôi sẽ làm rõ ngay từ đầu là cách đo lường giá trị cùng các đơn vị kinh doanh và tài chính. Với mỗi năng lực công nghệ mới, cần xác định hiện trạng để so sánh và xác định thời điểm kiểm chứng lợi ích. Chẳng hạn, việc rút ngắn thời gian chuẩn bị hạ tầng đã giúp sản phẩm ra mắt sớm hơn bao lâu, hay vẫn còn một điểm nghẽn nào khác trong quy trình?
Điều thứ hai là đưa kế hoạch làm chủ vận hành vào cùng quyết định đầu tư. Đào tạo cần gắn với những việc đội ngũ phải tự làm được: triển khai thay đổi, xử lý sự cố, kiểm soát chi phí và phối hợp với đối tác. Khi hệ thống phát triển, năng lực nội bộ cũng phải theo kịp. Đây là hai ưu tiên tôi muốn nhấn mạnh hơn nếu thiết kế lại hành trình từ đầu.
Năm câu hỏi trước một quyết định công nghệ
1. Doanh nghiệp đang cần cải thiện kết quả nào và đo lường bằng chỉ số nào?
2. Có những phương án khả thi nào, Mỗi phương án phải đánh đổi điều gì?
3. Ai chịu trách nhiệm về lợi ích kinh doanh và ai sẽ tiếp quản việc vận hành?
4. Khi nào cần đánh giá lại, và những điều kiện nào dẫn đến việc điều chỉnh hoặc dừng?
5. Ban điều hành cần biết những gì để đưa ra quyết định trên cơ sở rõ ràng?
Người lãnh đạo công nghệ có thể rèn luyện cách nghĩ này ngay trong công việc hiện tại. Lần tới khi báo cáo một vướng mắc, hãy mang theo các phương án và kiến nghị của mình. Khi giao việc, hãy trao cả phạm vi quyết định và tiêu chí kết quả để đội ngũ từng bước tự chủ. Dành thời gian trao đổi với các đơn vị nghiệp vụ về những khó khăn của họ cũng là một cách mở rộng góc nhìn rất thực tế.
Bước chuyển lên CIO được thể hiện qua những lựa chọn hằng ngày: ưu tiên việc nào, dành nguồn lực cho ai và theo dõi kết quả đến đâu. Trách nhiệm ấy đòi hỏi người lãnh đạo luôn nhìn công nghệ trong mối liên hệ với hoạt động của doanh nghiệp và giá trị thực sự mà khách hàng nhận được.
Bài viết chia sẻ từ anh Trần Nhất Minh, Deputy CEO cum CIO, VIB Bank