Thiết kế mô hình phối hợp giữa IT và các bộ phận kinh doanh trong triển khai chuyển đổi số.

Gửi yêu cầu rồi chờ bàn giao chưa tạo được phối hợp

Bộ phận kinh doanh gửi danh sách tính năng, IT xây theo yêu cầu, rồi khi nghiệm thu người dùng nói cách làm không phù hợp. Hai bên có thể đều thực hiện đúng phần được giao nhưng thiếu một quá trình cùng hiểu vấn đề và kiểm chứng. Khoảng trống thường xuất hiện giữa các lần chuyển trách nhiệm.

Mô hình phối hợp cần giữ liên hệ xuyên suốt từ vấn đề, lựa chọn, xây dựng đến sử dụng. Không phải mọi phòng ban đều tham gia mọi quyết định, nhưng người có trách nhiệm phải xuất hiện đúng thời điểm. CDO giúp tổ chức xác định đầu ra chung, quyền và nhịp trao đổi.

Nền tảng lãnh đạo chuyển đổi số hỗ trợ kết nối mô hình này với mục tiêu kinh doanh. Kết quả cần là công việc được quyết định và hoàn tất rõ hơn, không chỉ thêm cuộc họp giữa IT và các đơn vị.

Chọn đơn vị phối hợp theo hành trình hoặc kết quả

Một nhóm làm việc có thể được tổ chức quanh hành trình khách hàng, dịch vụ hoặc quy trình ưu tiên. Phạm vi cần đủ rõ để có chủ sở hữu, người thực hiện và tiêu chí. Nếu phạm vi là toàn bộ doanh nghiệp ngay từ đầu, nhóm có thể khó xác định ai quyết định điều gì.

Chủ sở hữu nghiệp vụ cần có quyền chốt nhu cầu và ưu tiên trong giới hạn. Đội công nghệ xác nhận khả năng, phụ thuộc và kiểm soát. Người dùng cung cấp bằng chứng công việc; các đầu mối dữ liệu, an toàn thông tin hoặc tài chính tham gia theo loại quyết định.

Không mặc định nhóm liên chức năng phải là một bộ phận mới. Có thể phối hợp theo nguồn lực hiện có, miễn là thời gian và trách nhiệm được cam kết. Một danh sách tên không bảo đảm mọi người có khả năng tham gia đúng lúc.

Làm rõ đầu ra chung ở từng giai đoạn

Bảng cho thấy đóng góp, chưa thay thế phân quyền. Mỗi đầu ra cần người chịu trách nhiệm và người quyết định phù hợp. Nếu có nhiều bên phê duyệt, ghi phần từng bên và cách xử lý xung đột, tránh chờ tất cả cùng đồng ý mà không có giới hạn.

Dùng một danh sách công việc gắn với vấn đề

Mỗi mục nên có nhu cầu, người nhận, tiêu chí và bằng chứng. Tính năng cần được nối với nhiệm vụ hoặc kết quả; không chỉ ghi “thêm màn hình”. Những việc dữ liệu, đào tạo và chuẩn hóa quy trình cũng cần xuất hiện, vì chúng ảnh hưởng khả năng áp dụng.

Chốt nguồn trạng thái chính và cách cập nhật. Kinh doanh không nên giữ một danh sách ưu tiên riêng khác với IT mà chưa có cơ chế đối chiếu. Khi phát sinh yêu cầu mới, xem tác động tới việc đang làm và quyền quyết định thay đổi.

GOV.UK Service Manual nhấn mạnh hiểu nhu cầu và giải quyết trọn vấn đề của người dùng. Trong phối hợp doanh nghiệp, có thể vận dụng bằng cách theo hành trình thay vì tối ưu riêng một màn hình hoặc một phòng ban. Phương pháp cần điều chỉnh theo hoạt động thực tế.

Thiết kế nhịp trao đổi theo quyết định

Một nhịp làm việc có thể gồm chọn việc, xem sản phẩm, tháo gỡ điểm chặn và kiểm tra kết quả. Mỗi buổi cần mục đích và đầu ra. Không dùng cuộc họp tiến độ để quyết định lại mọi yêu cầu, cũng không chờ kỳ họp lớn mới báo điều kiện đang thiếu.

Trước buổi chọn việc, chuẩn bị dữ liệu và phụ thuộc. Khi xem sản phẩm, người dùng thực hiện nhiệm vụ và phản hồi theo tiêu chí, không chỉ nhận xét giao diện. Khi tháo gỡ, xác định người có quyền và lựa chọn; nếu vượt quyền, đưa lên đầu mối với thông tin đủ.

Sau cuộc họp, ghi quyết định, người nhận và mốc. Nếu chưa thể quyết định, nêu thiếu dữ liệu gì và ai bổ sung. Chương trình quản lý dự án IT hỗ trợ giữ phạm vi và cam kết trong nhịp phối hợp này.

Chốt tiêu chí kiểm chứng cùng người thực hiện

Kinh doanh xác nhận nhiệm vụ và kết quả cần; IT làm rõ điều kiện kỹ thuật, dữ liệu và vận hành. Tiêu chí phải có cách kiểm tra, gồm đường thuận lợi và ngoại lệ quan trọng. “Dễ dùng” hoặc “đủ tính năng” cần được chuyển thành điều có thể quan sát.

Không để tiêu chí xuất hiện lần đầu khi nghiệm thu. Có thể dùng mẫu thử, hồ sơ hoặc nhiệm vụ đại diện để thống nhất sớm. Phạm vi thử phải được phép và bảo vệ dữ liệu. Những yêu cầu chưa rõ nên được khảo sát thay vì cam kết một giải pháp chắc chắn.

Đừng xem một người đại diện là toàn bộ người dùng nếu vai trò và bối cảnh khác nhau. Tìm nhóm có nhiệm vụ hoặc điều kiện khác để kiểm tra trong phạm vi phù hợp. Khi phản hồi mâu thuẫn, xem khác biệt công việc trước khi chọn ý kiến theo chức danh.

Tình huống giả định: IT làm đúng tính năng nhưng quy trình chưa đổi

Một doanh nghiệp giả định xây hệ thống phê duyệt yêu cầu. Kinh doanh gửi yêu cầu, IT triển khai, nhưng người quản lý vẫn phê duyệt qua chat rồi nhân viên nhập lại. Nhóm dự án nhận thấy cách quản lý chưa được xác nhận cùng thiết kế.

CDO tổ chức nhóm có chủ quy trình, quản lý trực tiếp và IT. Nhóm làm rõ nguồn trạng thái chính, thời điểm quyết định và ngoại lệ. Người dùng thử nhiệm vụ thật trong môi trường được phép; các vấn đề về quyền và dữ liệu được giao đầu mối xử lý.

Khi chuyển tiếp, quản lý chốt cách làm mới và phần báo cáo trùng được điều chỉnh. Tình huống không giả định mức tiết kiệm. Bài học là phối hợp phải bao gồm thay đổi vận hành, không kết thúc ở việc bàn giao chức năng.

Giải quyết xung đột bằng lựa chọn có thông tin

Khi kinh doanh muốn nhanh và IT lo rủi ro, đưa ra phương án với phạm vi, điều kiện, chi phí và tác động. Có thể giới hạn thử nghiệm, chia giai đoạn hoặc thay thứ tự, nếu đáp ứng kiểm soát. Không dùng câu “IT không hỗ trợ” hoặc “kinh doanh không hiểu” thay cho phân tích.

Xác nhận quyền quyết định ở mức phù hợp. Người điều phối không tự vượt quyền phê duyệt ngân sách, dữ liệu hoặc thay đổi. APM mô tả quản trị qua quyền và trách nhiệm; cơ chế phối hợp cần nối với mô hình này để điểm chặn có đường giải quyết.

Giữ hồ sơ quyết định và lý do. Khi điều kiện đổi, xem lại cùng các bên bị ảnh hưởng. Những yêu cầu ngoài phạm vi không nên được nhận âm thầm rồi làm trễ cam kết khác.

Chuyển tiếp sang vận hành từ trước go-live

Lập trách nhiệm hỗ trợ, tài liệu, quyền, kiểm tra và xử lý ngoại lệ trong kế hoạch. Chủ quy trình nhận mức áp dụng và kết quả; đội IT nhận dịch vụ theo phạm vi; người chăm sóc dữ liệu nhận công việc tương ứng. Xác nhận năng lực và nguồn lực, không chỉ chữ ký bàn giao.

Nội dung quản lý dịch vụ IT giúp nối dự án với vận hành. Kỳ kiểm chứng sau triển khai cần xem công việc có thể thực hiện, vấn đề lặp và kết quả, rồi giao hành động cải thiện.

Nếu nhà cung cấp tham gia, làm rõ vai trò và đường chuyển việc. Không để nhân viên phải tự tìm bên xử lý khi xảy ra lỗi. Cơ chế phối hợp phải tiếp tục hoạt động khi nhóm dự án rút khỏi công việc thường ngày.

Đánh giá mô hình qua luồng quyết định và kết quả

Có thể xem thời gian chờ quyết định, số yêu cầu bị làm lại, chất lượng tiêu chí và mức áp dụng. Dữ liệu cần phạm vi và bối cảnh; một thay đổi số lượng chưa đủ để kết luận nguyên nhân. Lấy mẫu hồ sơ giúp hiểu các điểm khó trong cơ chế.

• Chủ sở hữu kết quả có quyền và thời gian tham gia.
• Nhu cầu, dữ liệu và phụ thuộc được xem cùng nhau.
• Có nguồn ưu tiên và trạng thái chính được các bên dùng.
• Tiêu chí kiểm chứng được thống nhất trước xây dựng.
• Điểm vượt quyền có người tiếp nhận và mốc phản hồi.
• Vận hành, áp dụng và lợi ích sau bàn giao có trách nhiệm rõ.

Nền tảng IT Manager hỗ trợ xác nhận năng lực của đội công nghệ trong mô hình chung. CDO cần duy trì mạch từ vấn đề đến quyết định, kiểm chứng và vận hành để phối hợp trở thành năng lực tổ chức, thay vì phụ thuộc vào quan hệ cá nhân của một dự án.

Bài viết liên quan

• CDO nên lựa chọn dự án chuyển đổi số đầu tiên dựa trên những tiêu chí nào?
• Rủi ro chuyển đổi số không chỉ nằm ở công nghệ: Dữ liệu, con người và vận hành
• Thiết lập chương trình quản trị dữ liệu làm nền tảng cho chuyển đổi số.
• Một Business Case chuyển đổi số thuyết phục cần chứng minh chi phí, lợi ích và kết quả nào?

Nguồn tham khảo

1. APM – What is governance?
2. GOV.UK Service Manual – Solve a whole problem for users
3. GOV.UK Service Manual – Learning about users and their needs