Lựa chọn quy trình ưu tiên khi doanh nghiệp bắt đầu triển khai COBIT 5.

Chọn vấn đề trước khi chọn tên quy trình

Một điểm khởi đầu tốt là vấn đề mà các bên cùng nhận thấy, có tác động rõ và có người sở hữu. Chẳng hạn, dự án liên tục thay ưu tiên, dịch vụ thường gián đoạn hoặc báo cáo đầu tư không chứng minh được lợi ích. Cách chọn này giúp chương trình có câu hỏi cần giải quyết thay vì chỉ có một khung cần triển khai.

Cần mô tả vấn đề bằng tác động và bằng chứng. “Quản trị chưa tốt” quá rộng để chọn quy trình. Nếu quyết định đầu tư thiếu người xác nhận lợi ích, cần ghi các trường hợp, cơ chế hiện tại và hệ quả. Nếu sự cố lặp, cần xem dữ liệu diễn biến và việc xử lý nguyên nhân, không chỉ đếm số ticket.

Người bảo trợ cần thống nhất kết quả mong đợi và phạm vi có thể điều chỉnh. Một vấn đề có tác động lớn nhưng không có quyền huy động nghiệp vụ sẽ khó trở thành phạm vi thử nghiệm hiệu quả. Cần giải quyết điều kiện tổ chức hoặc chọn phần có thể thực hiện, thay vì giao thêm trách nhiệm cho một nhóm không có quyền.

Chương trình COBIT 5 Foundation là hướng tham khảo để xây ngôn ngữ chung trước bước lựa chọn. Trong cuộc thảo luận thực tế, người hiểu nghiệp vụ và người nắm nguồn lực phải cùng tham gia, để các quy trình được chọn phục vụ vấn đề doanh nghiệp đang cần giải quyết.

Ánh xạ mục tiêu rồi kiểm tra cơ chế đóng góp

Từ vấn đề, doanh nghiệp xác định nhu cầu và mục tiêu liên quan, sau đó dùng Goals Cascade cùng hướng dẫn quy trình để tìm những nội dung có thể đóng góp. Ánh xạ là điểm bắt đầu cho phân tích, không phải quyết định tự động. Cần giải thích quy trình được chọn sẽ thay đổi công việc hoặc quyền ra sao.

Nếu vấn đề là dự án không tạo lợi ích, BAI01 có thể liên quan nhưng chưa chắc đủ. Cần xem cách chọn danh mục, trách nhiệm chủ lợi ích và cơ chế giám sát. Nếu danh mục thiếu ưu tiên hoặc chủ nghiệp vụ chưa nhận trách nhiệm, cải thiện quản lý tiến độ riêng lẻ sẽ không xử lý toàn bộ nguyên nhân.

Tương tự, lỗi dịch vụ tái diễn có thể cần DSS03 về quản lý vấn đề, nhưng cũng liên quan thông tin cấu hình, kiểm soát thay đổi hoặc nguồn lực. Nhóm cần phân biệt quy trình trực tiếp xử lý kết quả với quy trình tạo điều kiện. Việc chọn đúng phụ thuộc giúp tránh một cải tiến mạnh ở giữa nhưng yếu ở đầu vào.

Không cần đưa mọi quy trình có liên quan vào phạm vi đầu tiên. Có thể xác định nội dung tối thiểu ở các điểm giao nhận, rồi chọn một số quy trình trọng tâm để cải thiện sâu hơn. Điều kiện là không bỏ qua phụ thuộc thiết yếu khiến kết quả của phạm vi chính không thể xuất hiện.

So sánh bằng tác động, khoảng trống và khả năng thực hiện

Một quy trình quan trọng không luôn là quy trình cần cải thiện trước. Nếu năng lực hiện tại đã đáp ứng nhu cầu, nguồn lực có thể nên dành cho một khoảng trống khác. Ngược lại, một quy trình ít được chú ý nhưng đang làm quyết định thiếu căn cứ có thể cần ưu tiên cao hơn.

Nhóm nên xem mức tác động, khoảng trống đã quan sát, vai trò phụ thuộc và khả năng tổ chức cải tiến. Độ dễ làm chỉ là một yếu tố; chọn toàn những việc dễ có thể tạo kết quả ngắn hạn nhưng không chạm vấn đề chính. Chọn toàn những việc khó cũng có thể làm chương trình mất khả năng thực hiện.

Bảng là công cụ lựa chọn đề xuất, không phải mô hình chấm điểm chính thức của COBIT 5. Nếu sử dụng điểm, phải ghi căn cứ và xử lý tiêu chí không thể đánh đổi. Một yêu cầu quan trọng không nên bị loại chỉ vì tổng điểm thấp hơn khi cộng các yếu tố không tương đương.

Người quản lý có thể tham khảo chương trình Trưởng Phòng IT – IT Manager để củng cố năng lực điều phối kế hoạch. Trong lựa chọn, cần nhìn nguồn lực thực sự còn lại sau vận hành và các thay đổi đã cam kết, tránh tạo lịch cải tiến chỉ khả thi trên giấy.

Thử lựa chọn trong một tình huống dịch vụ

Tình huống giả định: doanh nghiệp thường gặp gián đoạn sau triển khai thay đổi. Nhóm IT đề nghị ưu tiên công cụ giám sát, nhóm vận hành muốn thêm kiểm thử, còn lãnh đạo muốn siết phê duyệt. Ba phương án có thể đều hữu ích, nhưng chưa thể quyết định trước khi biết điểm yếu thực tế.

Rà các trường hợp cho thấy đánh giá tác động thiếu thông tin phụ thuộc, người vận hành nhận thông báo muộn và các lỗi sau triển khai không được phân tích nhất quán. Phạm vi đầu tiên có thể tập trung vào BAI06 về thay đổi, nối với thông tin cấu hình cần thiết và DSS03 cho lỗi lặp. Cần bổ sung trách nhiệm và theo dõi phù hợp thay vì chỉ tạo thêm một chữ ký.

Nhóm không nhất thiết thiết kế lại toàn bộ hệ thống ngay. Có thể chọn một dịch vụ, thống nhất đầu vào đánh giá, thời điểm tham vấn và điều kiện triển khai. Với các sự cố liên quan, giữ thông tin để phân tích nguyên nhân và phản hồi vào quy trình thay đổi. Phạm vi nhỏ vẫn giữ đường nối giữa các công việc quan trọng.

Năng lực quản lý rủi ro giúp giải thích vì sao những điều kiện này cần ưu tiên. Chương trình Quản trị rủi ro IT là hướng tham khảo để phát triển cách trình tác động và lựa chọn. Trong tình huống, kiểm soát cần tương xứng với mức rủi ro của từng loại thay đổi.

Đặt mức mục tiêu phù hợp với nhu cầu

Sau khi chọn quy trình, cần xác định điều muốn cải thiện. “Đạt mức cao hơn” chưa đủ để tổ chức công việc. Mục tiêu nên gắn với kết quả và năng lực cần có, chẳng hạn đánh giá tác động dùng được thông tin đáng tin, người có quyền nhận được phương án hoặc đầu ra được giữ để truy lại.

Nếu sử dụng PAM để đánh giá năng lực, cần giữ phạm vi và tiêu chí rõ. Mức hiện tại phải được xác định bằng bằng chứng, còn mức mục tiêu phải có căn cứ nhu cầu. Không mặc định mọi quy trình cùng đạt một mức hoặc dùng số trung bình toàn tổ chức để che những thiếu hụt ở quy trình trọng yếu.

Kế hoạch cải tiến cần có người sở hữu, sản phẩm, nguồn lực và cách kiểm chứng sau một chu kỳ phù hợp. Việc sửa tài liệu là đầu ra; việc người thực hiện dùng được cách làm mới là kết quả cần quan sát. Giữ hai nội dung giúp chương trình không tuyên bố hoàn thành quá sớm.

Ở cấp lãnh đạo, cần thống nhất điều kiện điều chỉnh phạm vi. Nếu phát hiện phụ thuộc lớn hơn dự kiến hoặc ưu tiên doanh nghiệp đổi, nhóm trình phương án thu hẹp, thay thứ tự hoặc bổ sung nguồn lực. Không nên giữ danh sách ban đầu như một cam kết bất biến khi căn cứ lựa chọn đã thay đổi.

Mở rộng từ bằng chứng, không từ nhu cầu đủ danh mục

Kết thúc phạm vi đầu tiên, cần kiểm tra kết quả, việc sử dụng cách làm và chi phí duy trì. Nếu chỉ số tốt hơn nhưng phụ thuộc vào một nhóm hỗ trợ tạm thời, chưa thể kết luận cơ chế đã bền vững. Cần xác định điều kiện để chủ quy trình tiếp tục vận hành khi chương trình cải tiến chuyển sang nơi khác.

Những phát hiện giúp chọn phạm vi tiếp theo. Có thể mở rộng sang dịch vụ tương tự, xử lý một phụ thuộc mới hoặc cải thiện cơ chế giám sát ở cấp cao hơn. Việc mở rộng nên có lý do rõ, không thực hiện chỉ để tăng số quy trình được đánh dấu đã triển khai.

Người lãnh đạo công nghệ cần trình tiến triển bằng vấn đề đã được giải quyết và quyết định đã được cải thiện. Góc nhìn trong chương trình Lãnh đạo IT – CIO là hướng tham khảo để phát triển cách nối kết quả cải tiến với mục tiêu và nguồn lực doanh nghiệp.

Bước khởi đầu phù hợp là lấy một vấn đề có tác động, truy các công việc đang cản kết quả và chọn phạm vi đủ để kiểm chứng. COBIT 5 cung cấp bản đồ để phân tích, còn thứ tự cải tiến phải phản ánh nhu cầu thực. Khi lựa chọn có căn cứ và được xem lại bằng bằng chứng, doanh nghiệp có thể tiến từng bước mà vẫn giữ được cái nhìn tổng thể.

Bài viết liên quan

• Quy trình đã đầy đủ mà quản trị vẫn kém: Bảy yếu tố hỗ trợ COBIT 5 nói gì?
• Đánh giá năng lực quy trình theo COBIT 5 Process Assessment Model.
• Thiết lập hệ thống chỉ số đánh giá hiệu quả quản trị IT theo mục tiêu doanh nghiệp.
• Triển khai COBIT từ đâu? Lộ trình xác lập mục tiêu, đánh giá và cải tiến quản trị

Nguồn tham khảo

1. ISACA — COBIT 5: Taking IT Governance and Management to the Next Level
2. ISACA — COBIT 5’s Flexibility Key to Success
3. ISACA — Focus on COBIT Adoption Rather Than Implementation