INFOCHIEF ACADEMY · COBIT 5 KNOWLEDGE SERIES
Ứng dụng BAI trong quản lý chương trình, dự án và thay đổi hệ thống.
BAI đặt chương trình, dự án và thay đổi trong cùng dòng kết quả. Yêu cầu có thể kiểm chứng, cách làm việc mới và điều kiện tiếp nhận giúp sản phẩm được đưa vào sử dụng với khả năng duy trì rõ ràng.
Biên soạn: Infochief Academy · Chuyên đề: Quản trị IT theo COBIT 5
Biên bản bàn giao có đủ chữ ký, nhưng ngày đầu vận hành vẫn đầy những câu hỏi chưa được trả lời. Ai xử lý dữ liệu thiếu? Người dùng liên hệ đâu khi thao tác bị dừng? Nhóm vận hành có được quyền phục hồi phiên bản trước hay phải chờ dự án xác nhận?
Những khoảng trống này cho thấy quản lý thay đổi hệ thống không kết thúc ở việc xây đúng chức năng. BAI trong COBIT 5 giúp nhìn chương trình, dự án, giải pháp và chuyển giao như những công việc liên quan. Mục tiêu là đưa thay đổi vào sử dụng có kiểm soát, với người nhận, điều kiện và năng lực duy trì rõ ràng.
Chương trình và dự án cần cùng nhìn về kết quả
BAI là Build, Acquire and Implement: xây dựng, mua sắm và triển khai. Trong COBIT 5, BAI01 là Manage Programmes and Projects, quản lý chương trình và dự án. Khi áp dụng phiên bản này, cần giữ đúng phạm vi quy trình, thay vì dùng cách tách mã hoặc tên của phiên bản khác.
Một chương trình có thể gồm nhiều dự án và hoạt động để tạo một kết quả chung. Nếu các dự án đều hoàn thành riêng lẻ nhưng thiếu kết nối, lợi ích vẫn có thể không xuất hiện. Việc quản lý cần nhìn các phụ thuộc, nguồn lực dùng chung và thay đổi nghiệp vụ ngoài sản phẩm công nghệ.
Ví dụ giả định: chương trình cải thiện tiếp nhận khách hàng có dự án ứng dụng, công việc chuẩn hóa dữ liệu và thay đổi cách phân công hồ sơ. Dự án ứng dụng không thể tự bảo đảm kết quả nếu hai phần còn lại chưa được thực hiện. Kế hoạch tổng thể phải xác định điểm giao nhận và người sở hữu từng điều kiện.
Người quản lý cần thiết lập cách theo dõi kết quả mong đợi song song với tiến độ sản phẩm. Khi một giả định lợi ích không còn đúng, vấn đề phải được đưa về người có quyền lựa chọn. Không nên tiếp tục tăng tốc dự án chỉ vì nó đã được khởi động, trong khi mục tiêu chung đã thay đổi.
Đội ngũ có thể tham khảo chương trình Quản lý Dự án IT để củng cố năng lực tổ chức công việc này. Trong doanh nghiệp, cần giữ vai trò chủ nghiệp vụ và người tiếp nhận dịch vụ ngay từ đầu, để kết quả không bị giao toàn bộ cho nhóm triển khai.
Yêu cầu phải mô tả cả tình huống không thuận lợi
BAI02 liên quan xác định yêu cầu, còn BAI03 liên quan xác định và xây dựng giải pháp. Sự nối liền giữa hai nội dung giúp tránh việc nhóm kỹ thuật xây theo mô tả chức năng nhưng bỏ sót điều kiện sử dụng. Người sử dụng cần giải thích công việc, dữ liệu, quyền và tình huống ngoại lệ, không chỉ các màn hình mong muốn.
Một yêu cầu như “tự động chuyển hồ sơ” phải được làm rõ: chuyển khi đủ điều kiện nào, ai xử lý nếu thiếu thông tin và hệ thống ghi nhận gì khi chuyển thất bại. Những câu hỏi đó tạo căn cứ kiểm thử và tổ chức vận hành. Nếu chưa được trả lời, nhóm có thể xây một luồng chạy tốt trong điều kiện lý tưởng nhưng không đủ để dùng.
Năng lực và khả năng sẵn sàng cũng cần được xem trong thiết kế. BAI04 về availability và capacity nhắc doanh nghiệp kiểm tra giải pháp có đáp ứng điều kiện sử dụng dự kiến hay không. Đây không chỉ là chọn cấu hình lớn hơn; cần hiểu tải, các điểm phụ thuộc và cách phục vụ khi một thành phần không hoạt động.
Việc lựa chọn xây, mua hoặc kết hợp cần phản ánh khả năng quản lý về sau. Một giải pháp triển khai nhanh nhưng khó bảo trì hoặc thiếu hỗ trợ có thể tạo chi phí và rủi ro trong vận hành. Những điều kiện này nên được đưa vào đánh giá trước khi tổ chức cam kết với phương án.
Thay đổi tổ chức và thay đổi kỹ thuật là hai luồng
Trong COBIT 5, BAI05 là quản lý việc tạo điều kiện cho thay đổi tổ chức, còn BAI06 là quản lý các thay đổi. Phân biệt này giúp nhìn rõ một hệ thống mới cần cả thay đổi cách làm việc lẫn kiểm soát triển khai kỹ thuật. Hai luồng hỗ trợ nhau nhưng không thể thay thế nhau.
Thay đổi tổ chức cần làm rõ hành vi và trách nhiệm mới. Ai nhập dữ liệu, ai xác nhận, ai xử lý ngoại lệ và người quản lý nghiệp vụ theo dõi điều gì? Một buổi hướng dẫn sử dụng chưa chắc đủ nếu cơ chế phân công hoặc đánh giá vẫn khuyến khích cách làm cũ.
Thay đổi kỹ thuật cần đánh giá tác động, chuẩn bị bằng chứng, xác định thẩm quyền và kiểm soát việc thực hiện. Phương án phục hồi phải tương thích với dữ liệu và trạng thái sau chuyển đổi, không chỉ là khôi phục phiên bản ứng dụng. Các điều kiện đó ảnh hưởng trực tiếp tới lựa chọn thời điểm và phạm vi triển khai.
| Luồng chuẩn bị đề xuất | Câu hỏi cần trả lời | Người cần tham gia |
|---|---|---|
| Cách làm việc mới | Trách nhiệm và thao tác nào thay đổi? | Chủ nghiệp vụ và người sử dụng |
| Thay đổi kỹ thuật | Tác động, kiểm thử và phục hồi ra sao? | Kỹ thuật, vận hành và người có quyền |
| Tiếp nhận dịch vụ | Cần gì để duy trì và hỗ trợ? | Chủ dịch vụ, hỗ trợ và nhà cung cấp |
| Kiểm chứng kết quả | Cách làm mới có tạo kết quả dự kiến? | Chủ lợi ích và nhóm phân tích |
Bảng là công cụ tổ chức đề xuất, không phải ma trận trách nhiệm mặc định của COBIT 5. Với mỗi luồng, cần ghi sản phẩm bàn giao và người xác nhận. Nếu một người ký thay nhiều nội dung, vẫn phải làm rõ họ có đủ thẩm quyền và căn cứ cho từng phần.
Năng lực tổ chức trách nhiệm và theo dõi hoạt động có thể được phát triển qua chương trình Trưởng Phòng IT – IT Manager. Khi áp dụng, đừng để nhóm IT phải tự thiết kế trách nhiệm nghiệp vụ mà chưa được người sở hữu quy trình thống nhất.
Tiếp nhận là một điều kiện triển khai
BAI07 liên quan chấp nhận thay đổi và chuyển giao. Phần việc này cần được chuẩn bị trước ngày triển khai, vì người vận hành phải biết họ tiếp nhận cái gì, dựa trên bằng chứng nào và với những thiếu hụt còn lại nào. Biên bản có chữ ký nhưng không có khả năng hỗ trợ chỉ tạo sự chắc chắn trên giấy.
Điều kiện tiếp nhận nên phản ánh mức quan trọng của dịch vụ. Có thể bao gồm kiểm thử nghiệp vụ, thông tin giám sát, hướng dẫn xử lý, quyền cần thiết, cơ chế hỗ trợ và phương án phục hồi. Không nên dùng một danh sách chung mà không kiểm tra những tình huống đặc thù của dữ liệu hoặc hoạt động kinh doanh.
BAI08 về kiến thức, BAI09 về tài sản và BAI10 về cấu hình giúp giữ những thông tin cần để quản lý giải pháp sau thay đổi. Nếu phiên bản thực tế không khớp hồ sơ, nhóm vận hành sẽ khó xác định tác động khi có lỗi. Nếu kiến thức chỉ ở một chuyên gia dự án, khả năng hỗ trợ sẽ yếu khi người đó không còn tham gia.
Đội ngũ cần củng cố việc vận hành, kiểm tra và duy trì thông tin hệ thống có thể tham khảo chương trình Quản trị Vận hành IT. Trong chuyển giao, năng lực cá nhân cần đi cùng tài liệu, quyền và cơ chế phối hợp để không phụ thuộc vào một người biết toàn bộ hệ thống.
Một lần triển khai được chia lại phạm vi
Tình huống giả định: doanh nghiệp chuẩn bị đưa ứng dụng tiếp nhận hồ sơ vào sử dụng. Kiểm thử chức năng cơ bản đã đạt, nhưng người dùng chưa thống nhất cách xử lý hồ sơ thiếu và nhóm hỗ trợ chưa có quyền tra cứu diễn biến. Giữ lịch triển khai toàn bộ sẽ đưa những khoảng trống tổ chức vào môi trường thực.
Nhóm quản lý tách các vấn đề thay vì coi tất cả là lỗi phần mềm. Phần chức năng được xác nhận theo bằng chứng kiểm thử; trách nhiệm xử lý hồ sơ cần chủ nghiệp vụ quyết định; quyền hỗ trợ cần được thiết kế và kiểm tra. Ba nội dung có người sở hữu và thời điểm hoàn tất khác nhau.
Người có thẩm quyền có thể chọn triển khai phạm vi hẹp để kiểm chứng luồng đã sẵn sàng, đồng thời hoàn thiện các điều kiện còn lại. Quyết định phải ghi nhóm sử dụng, loại hồ sơ, cách hỗ trợ và ngưỡng dừng. Không nên gọi đây là thử nghiệm nếu phạm vi thực tế đã ảnh hưởng toàn bộ doanh nghiệp mà chưa có kiểm soát tương ứng.
Sau triển khai hẹp, nhóm theo dõi cả khả năng hoàn tất công việc và diễn biến hỗ trợ. Những phản hồi giúp xác định cần sửa chức năng, hướng dẫn hay phân công. Chỉ khi các điều kiện được xác nhận mới xem xét mở rộng; mục tiêu là giảm sự không chắc chắn trước khi tăng tác động.
Tình huống cho thấy BAI không bảo đảm thành công bằng một phương pháp dự án duy nhất. Agile, Waterfall hoặc Hybrid có thể tổ chức công việc theo hoàn cảnh, nhưng vẫn cần yêu cầu rõ, kiểm soát thay đổi, khả năng tiếp nhận và cơ chế kiểm chứng kết quả. Phương pháp không thay thế trách nhiệm của các bên.
Đóng dự án nhưng giữ đường nối tới lợi ích
Khi sản phẩm đã được tiếp nhận, dự án có thể hoàn tất theo điều kiện đã thống nhất. Tuy nhiên, việc kiểm chứng lợi ích cần tiếp tục ở người sở hữu kết quả nghiệp vụ và cơ chế quản lý phù hợp. Đừng kéo dài dự án vô hạn để giữ mọi trách nhiệm, cũng đừng đóng dự án rồi để mục tiêu kinh doanh mất người theo dõi.
Cuộc bàn giao nên xác nhận các việc còn lại, người thực hiện, nguồn lực và đường chuyển cấp. Một thiếu hụt được chấp nhận phải có căn cứ và thời điểm xem lại. Nếu thông tin này không được nối tới vận hành, ngoại lệ tạm thời sẽ dễ trở thành cách làm thường xuyên mà không ai quyết định.
Chương trình COBIT 5 Foundation là hướng tham khảo để đặt các nội dung BAI trong mô hình quản trị và quản lý chung. Doanh nghiệp có thể bắt đầu bằng việc rà một dự án sắp bàn giao: yêu cầu có thể kiểm chứng, người dùng có thể làm việc và vận hành có thể duy trì hay chưa?
Chất lượng của thay đổi được thể hiện rõ nhất ở thời điểm người nhận có thể sử dụng sản phẩm mà không phải đoán trách nhiệm. Khi dự án bàn giao được cả giải pháp, kiến thức, điều kiện và đường xử lý ngoại lệ, ngày triển khai mới trở thành điểm bắt đầu của một dịch vụ có thể duy trì.