OLB #05 — IT Operating Model: Công nghệ vận hành thế nào để tạo ra giá trị cho ngân hàng?

[GIẢ LẬP · PHỤC VỤ NGHIÊN CỨU & ĐÀO TẠO]

Trong bốn bài đầu của Odin Lab Bank, chúng ta đã đi từ chiến lược đến kiến trúc doanh nghiệp, từ năng lực nghiệp vụ đến cơ chế phân công trách nhiệm và quản trị. Nhưng một ngân hàng không tạo ra giá trị chỉ bằng những bản thiết kế tốt. Giá trị chỉ xuất hiện khi chiến lược được chuyển thành những dịch vụ vận hành ổn định mỗi ngày, khi công nghệ có thể thay đổi đủ nhanh mà vẫn an toàn, và khi mỗi sự cố hay điểm yếu đều trở thành đầu vào cho một vòng cải tiến mới.

Đó là vai trò của mô hình vận hành công nghệ thông tin.

Trong OLB, mô hình này không được hiểu đơn giản là sơ đồ tổ chức của khối công nghệ, cũng không phải tập hợp các quy trình kỹ thuật. Nó là cách con người, quy trình, công nghệ, dữ liệu và cơ chế quản trị phối hợp với nhau để biến nhu cầu của ngân hàng thành dịch vụ thực tế, có thể đo lường, kiểm soát và phục hồi.

1. Bắt đầu từ giá trị, không bắt đầu từ hạ tầng

Cách tiếp cận truyền thống thường nhìn công nghệ từ bên trong: máy chủ, mạng, cơ sở dữ liệu, ứng dụng hay các nhóm kỹ thuật. OLB đi theo chiều ngược lại. Điểm xuất phát là khách hàng và dịch vụ ngân hàng mà họ sử dụng.

Một dịch vụ thanh toán số, chẳng hạn, không tồn tại nhờ một hệ thống đơn lẻ. Phía sau trải nghiệm tưởng như rất đơn giản của khách hàng là nhiều năng lực nghiệp vụ, ứng dụng, dịch vụ công nghệ, dữ liệu, nền tảng và hạ tầng cùng phối hợp. Vì vậy, điều quan trọng không chỉ là từng thành phần có hoạt động hay không, mà là toàn bộ chuỗi có tạo ra kết quả mà khách hàng và ngân hàng cần hay không.

OLB mô tả mạch giá trị theo hướng: Chiến lược và nhu cầu → Năng lực nghiệp vụ → Dịch vụ ngân hàng → Công nghệ vận hành → Giá trị cho khách hàng và ngân hàng.

2. Sáu trụ cột của mô hình vận hành công nghệ OLB

Trụ cột thứ nhất là đồng hành với nghiệp vụ. Công nghệ phải hiểu mục tiêu kinh doanh, nhu cầu khách hàng và mức độ quan trọng của từng dịch vụ. Khi nguồn lực luôn hữu hạn, khả năng lựa chọn đúng việc cần ưu tiên quan trọng không kém năng lực triển khai.

Trụ cột thứ hai là quản trị công nghệ. Quyền quyết định, trách nhiệm, nguyên tắc kiến trúc, tiêu chuẩn kỹ thuật và giới hạn chấp nhận rủi ro phải đủ rõ để tổ chức có thể hành động nhanh mà không mất kiểm soát. Quản trị tốt không làm công nghệ chậm đi; ngược lại, nó giảm thời gian tranh luận và xử lý lại vì các nguyên tắc đã được xác lập từ trước.

Trụ cột thứ ba là xây dựng và thay đổi. Nhu cầu được chuyển thành thiết kế, phát triển, kiểm thử, triển khai và đưa vào vận hành theo một dòng chảy có kiểm soát. Tự động hóa có thể giúp dòng chảy này nhanh hơn, nhưng chỉ thực sự có giá trị khi trách nhiệm, tiêu chuẩn và kiểm soát đã được thiết kế rõ.

Trụ cột thứ tư là vận hành ổn định. Trọng tâm không dừng ở việc theo dõi từng thiết bị hay ứng dụng mà phải nhìn được ảnh hưởng tới dịch vụ ngân hàng. Giám sát, quản lý sự cố, năng lực hệ thống, cấu hình và chất lượng dịch vụ cần được kết nối để trả lời một câu hỏi chung: dịch vụ mà khách hàng đang sử dụng có thực sự hoạt động tốt hay không?

Trụ cột thứ năm là an toàn và kiểm soát. Rủi ro và an toàn thông tin không nên xuất hiện như một bước kiểm tra ở cuối quá trình. Chúng cần được đưa vào từ thiết kế, phát triển, thay đổi, vận hành cho tới phục hồi. Khi kiểm soát được tích hợp ngay từ đầu, tổ chức vừa giảm rủi ro vừa giảm chi phí sửa chữa về sau.

Trụ cột cuối cùng là phục hồi và cải tiến. Một hệ thống tốt không phải là hệ thống được giả định sẽ không bao giờ thất bại. Nó là hệ thống có khả năng phát hiện sớm, ứng phó có tổ chức, phục hồi trong phạm vi chấp nhận được và học từ những gì đã xảy ra. Mỗi sự cố, cuộc diễn tập hay kết quả đánh giá đều phải quay trở lại vòng cải tiến.

3. Từ dịch vụ ngân hàng đến công nghệ vận hành

Để mô hình không dừng ở lý thuyết, OLB sử dụng một chuỗi truy vết xuyên suốt. Nhu cầu của khách hàng hình thành dịch vụ ngân hàng; dịch vụ đòi hỏi các năng lực nghiệp vụ; năng lực được hỗ trợ bởi ứng dụng; ứng dụng sử dụng các dịch vụ công nghệ; và phía dưới là nền tảng, dữ liệu cùng hạ tầng.

Trong ví dụ thanh toán số của OLB, khách hàng chỉ nhìn thấy một giao dịch được thực hiện nhanh chóng và tin cậy. Nhưng để tạo ra kết quả đó, ngân hàng phải phối hợp xử lý giao dịch, quản lý tài khoản, kiểm soát gian lận, đối soát, thanh toán bù trừ, các ứng dụng nghiệp vụ, kết nối tích hợp và nhiều dịch vụ nền tảng.

Điều quan trọng là mỗi lớp đều phải có người chịu trách nhiệm rõ ràng. Chủ dịch vụ nghiệp vụ quan tâm tới kết quả đầu cuối; chủ năng lực chịu trách nhiệm phát triển năng lực; chủ ứng dụng chịu trách nhiệm vòng đời ứng dụng; chủ dịch vụ công nghệ và chủ nền tảng chịu trách nhiệm về chất lượng, khả năng cung cấp và môi trường vận hành. Khi trách nhiệm được nối theo cùng một chuỗi giá trị, công nghệ không còn là một “hộp đen” phía sau nghiệp vụ.

4. Xây dựng, vận hành và kiểm soát phải cùng một nhịp

Nhiều tổ chức gặp khó khăn khi ba thế giới xây dựng, vận hành và kiểm soát tách rời nhau. Nhóm phát triển tập trung vào tốc độ; nhóm vận hành tiếp nhận hệ thống sau khi triển khai; còn các chức năng rủi ro, an toàn và tuân thủ kiểm tra ở một thời điểm khác. Khoảng cách giữa ba nhóm thường tạo ra chi phí chuyển giao, xung đột ưu tiên và những điểm mù về trách nhiệm.

OLB lựa chọn cách tiếp cận khác: trách nhiệm đối với dịch vụ phải tồn tại trong toàn bộ vòng đời. Người xây dựng cần hiểu điều kiện vận hành; người vận hành cần tham gia đủ sớm để chuẩn bị năng lực; yêu cầu kiểm soát phải được đưa vào thiết kế thay vì bổ sung sau cùng. Khi đó, tốc độ và kiểm soát không còn là hai mục tiêu đối lập.

5. Từ dự án sang trách nhiệm dài hạn với dịch vụ

Dự án có thời điểm bắt đầu và kết thúc, nhưng một dịch vụ ngân hàng có thể tồn tại và thay đổi trong nhiều năm. Vì vậy, OLB vẫn sử dụng dự án cho các chương trình thay đổi lớn, nhưng không để trách nhiệm đối với dịch vụ kết thúc cùng dự án.

Tư duy theo sản phẩm và dịch vụ giúp duy trì một chủ thể chịu trách nhiệm lâu dài đối với chất lượng, chi phí, rủi ro, khả năng thay đổi và khả năng phục hồi. Đây là nền tảng để tránh tình trạng “hoàn thành triển khai” nhưng chưa thực sự hoàn thành trách nhiệm vận hành.

6. Tự động hóa chỉ có giá trị sau khi đã chuẩn hóa

Tự động hóa là một năng lực quan trọng của vận hành hiện đại, từ kiểm thử, triển khai, cấu hình, giám sát đến điều phối phục hồi. Tuy nhiên, OLB không xem tự động hóa là điểm xuất phát.

Nguyên tắc được sử dụng là: Chuẩn hóa → Kiểm soát → Tự động hóa → Đo lường → Cải tiến.

Nếu quy trình chưa rõ, quyền quyết định chưa rõ hoặc kiểm soát chưa được thiết kế, tự động hóa có thể chỉ làm cho một cách làm chưa tốt diễn ra nhanh hơn. Giá trị thực sự xuất hiện khi tự động hóa làm giảm thao tác thủ công, tăng tính nhất quán và đồng thời tạo ra bằng chứng tốt hơn cho quản trị.

7. Bằng chứng phải được sinh ra từ chính hoạt động vận hành

Một mô hình vận hành trưởng thành không chỉ tạo ra dịch vụ; nó còn tạo ra bằng chứng. Nhật ký thay đổi, kết quả triển khai, cấu hình chuẩn, sự kiện giám sát, hồ sơ sự cố, kết quả kiểm tra kiểm soát, kết quả diễn tập và quyết định quản trị đều giúp tổ chức hiểu điều gì đã xảy ra và tại sao.

Khi bằng chứng được thu thập có hệ thống, quản trị rủi ro và kiểm toán không còn phụ thuộc quá nhiều vào việc tổng hợp thủ công sau sự kiện. Dữ liệu vận hành trở thành nguyên liệu cho quyết định.

8. Vòng tạo giá trị và kiểm soát

OLB coi vận hành công nghệ là một vòng lặp liên tục. Dữ liệu từ vận hành được thu thập và phân tích để nhận diện vấn đề. Rủi ro và hiệu quả kiểm soát được đánh giá trên cơ sở bằng chứng. Người có thẩm quyền đưa ra quyết định, nguồn lực được huy động để thực hiện, kết quả tiếp tục được đo lường và bài học quay trở lại hệ thống.

Chu trình đó có thể tóm tắt thành: Dữ liệu vận hành → Phân tích → Đánh giá rủi ro và kiểm soát → Quyết định → Hành động → Đo lường và bằng chứng → Cải tiến liên tục.

Đây cũng là nơi tư tưởng của Odin Lab trở nên rõ nhất: quản trị không dừng ở việc nhận diện rủi ro. Rủi ro phải dẫn tới kiểm soát; kiểm soát phải tạo ra bằng chứng; bằng chứng phải hỗ trợ quyết định; và quyết định phải tạo ra hành động có thể đo lường.

9. Đo những gì thực sự quan trọng

Một chỉ số kỹ thuật riêng lẻ hiếm khi phản ánh đầy đủ chất lượng của một dịch vụ ngân hàng. Vì vậy, OLB nhìn hiệu quả công nghệ theo nhiều chiều: giá trị tạo ra cho khách hàng và nghiệp vụ; tốc độ đưa thay đổi vào sử dụng; độ ổn định của dịch vụ; mức độ rủi ro và hiệu quả kiểm soát; khả năng phục hồi; cùng chất lượng bằng chứng phục vụ quản trị.

Mục tiêu không phải tạo thêm thật nhiều bảng điều khiển, mà là giúp người ra quyết định nhìn thấy mối quan hệ giữa hiệu quả, rủi ro, kiểm soát và khả năng phục hồi.

10. Khi công nghệ trở thành một năng lực tạo giá trị

Mô hình vận hành tốt không được đo bằng số lượng quy trình, cuộc họp hay báo cáo. Nó được thể hiện qua khả năng đưa thay đổi vào sử dụng nhanh hơn, vận hành ổn định hơn, kiểm soát rủi ro tốt hơn, phục hồi tốt hơn và sử dụng nguồn lực hiệu quả hơn.

Khi đó, công nghệ không chỉ là nơi cung cấp hạ tầng hay xử lý yêu cầu. Nó trở thành một năng lực của ngân hàng, kết nối trực tiếp chiến lược với trải nghiệm khách hàng và kết quả kinh doanh.

Có thể tóm gọn định hướng của OLB bằng một chuỗi: Giá trị → Dòng công việc → Ổn định → Kiểm soát → Phục hồi → Cải tiến.

11. Liên kết với chuỗi Odin Lab Bank

OLB #05 tiếp nối trực tiếp OLB #04 — Organization Structure & Governance, nơi trách nhiệm và quyền quyết định đã được xác lập. Nó cũng kế thừa nền tảng từ OLB #03 — Business Architecture & Capability Map, OLB #02 — Enterprise Architecture và OLB #01 — Mission, Vision & Strategy.

Bước tiếp theo sẽ đi sâu hơn vào lớp ứng dụng: OLB #06 — Application Architecture: Từ năng lực nghiệp vụ đến hệ sinh thái ứng dụng ngân hàng. Khi đó, chúng ta sẽ xem cách một ngân hàng giả lập tổ chức danh mục ứng dụng, ranh giới chức năng, tích hợp và phụ thuộc để vừa hỗ trợ thay đổi vừa kiểm soát độ phức tạp và rủi ro.

Tài liệu tham chiếu

Mô hình OLB được tổng hợp và phát triển theo phương pháp riêng của Odin Lab, có tham khảo các khung công khai về quản trị và quản lý công nghệ, quản lý dịch vụ, kiến trúc doanh nghiệp, an toàn thông tin và khả năng liên tục hoạt động như COBIT, ITIL, TOGAF, NIST Cybersecurity Framework 2.0 và ISO 22301. Việc tham chiếu không hàm ý OLB được chứng nhận hay tuân thủ đầy đủ bất kỳ khuôn khổ nào.

---

ODIN LAB BANK · OLB #05 — IT OPERATING MODEL
Chiến lược → Năng lực → Trách nhiệm → Vận hành công nghệ → Giá trị
TURN RISK INTO VALUE

OLB là ngân hàng giả lập được xây dựng từ các mô hình kiến trúc và nghiệp vụ phổ biến trong ngành ngân hàng. Tên hệ thống, kiến trúc, dữ liệu, chỉ tiêu và tình huống được thiết kế riêng cho mục đích nghiên cứu và đào tạo; không mô phỏng một tổ chức cụ thể. Third-party trademarks remain the property of their respective owners; references are illustrative.