Xác định người chịu trách nhiệm quy trình trước khi chọn phần mềm

Khi nhiều bộ phận cùng làm một quy trình, mỗi bên có thể kỳ vọng phần mềm buộc bên khác phản hồi. Công cụ có thể chuyển việc, nhưng bên mua vẫn cần thống nhất thẩm quyền về quy tắc, ngoại lệ và điểm bàn giao chưa rõ. Nếu chưa thống nhất, việc chọn sản phẩm có nguy cơ tự động hóa bất đồng thay vì cải thiện quy trình.

Tìm quyết định vượt ranh giới bộ phận

Vẽ hành trình từ yêu cầu nghiệp vụ đầu tiên đến kết quả cuối cùng. Hướng dẫn khám phá của GOV.UK khuyến nghị hiểu hành trình rộng hơn và học từ các nhóm cùng tham gia.[1] Bao gồm công việc ngoài hệ thống và người chịu hệ quả khi bàn giao thất bại.

Hỏi ai được đổi quy tắc, chấp nhận ngoại lệ và giải quyết xung đột giữa mục tiêu cục bộ. Người quản trị công cụ chưa chắc có thẩm quyền đó. Người bảo trợ cấp cao có thể duyệt ngân sách nhưng không có thời gian xử lý quyết định quy trình thường xuyên.

Viết tuyên bố thẩm quyền trước sơ đồ vai trò

Mô tả phạm vi của người sở hữu bằng ngôn ngữ dễ hiểu. Xác định ranh giới quy trình, quyết định người đó được đưa ra và vấn đề phải chuyển cấp. Nêu ai cung cấp bằng chứng vận hành và ai thay thế khi người sở hữu vắng mặt.

Không nhầm quyền sở hữu quy trình với một vai trò triển khai có tên cụ thể. Trong Scrum, Product Owner chịu trách nhiệm về giá trị sản phẩm và quản lý Product Backlog hiệu quả.[5] Định nghĩa đó không tự động trao quyền với mọi chính sách vận hành của các bộ phận. Cần xác nhận các trách nhiệm này nối với nhau thế nào trong tổ chức.

Ví dụ giả định: mở tài khoản doanh nghiệp

Một nhà bán buôn giả định muốn dùng một hệ thống để tiếp nhận tài khoản. Kinh doanh muốn kích hoạt nhanh, tài chính muốn rà soát trước khi cho mua chịu, còn vận hành cần địa chỉ giao hợp lệ. Buổi trao đổi ban đầu tạo ra ba định nghĩa trái nhau về trạng thái sẵn sàng.

Người bảo trợ chỉ định người sở hữu quy trình có thể thống nhất ranh giới kích hoạt với các bộ phận. Quy tắc sau đó tách tài khoản tạm khỏi tài khoản được đặt đơn mua chịu. Đến lúc ấy nhóm mới so sánh cách các sản phẩm hỗ trợ trạng thái và ngoại lệ đã thống nhất.

Kiểm tra quyền sở hữu có dùng được không

Một cái tên trong bài trình bày chưa đủ. Nhờ người dự kiến sở hữu xử lý một bất đồng thực tế trước khi cam kết phần mềm lớn.

• Xác định sự kiện bắt đầu và kết quả cuối trong phạm vi phụ trách.
• Nêu thẩm quyền với quy tắc, ngoại lệ và ưu tiên liên phòng ban.
• Chỉ rõ tuyến chuyển cấp cho quyết định vượt thẩm quyền.
• Phân công báo cáo vận hành và người quyết định thay thế.
• Xác nhận ai sở hữu quy trình sau khi nhóm triển khai rời đi.

Nhận rõ chi phí của tập trung thẩm quyền

Một người sở hữu có thể thành điểm nghẽn nếu mọi quyết định thường ngày đều phải xin duyệt trực tiếp. Phân quyền cho quyết định lặp lại trong giới hạn rõ. Giữ thay đổi liên phòng ban và ngoại lệ tranh chấp cho người chịu trách nhiệm chung.

Một số tổ chức không thể trao toàn bộ thẩm quyền cho một người. Khi đó, ghi rõ cơ chế quản trị và điều kiện phản hồi mong đợi. Hoãn cam kết sản phẩm phụ thuộc vào chính sách chưa chốt. Giới hạn rõ hữu ích hơn chức danh ấn tượng nhưng không có quyền quyết định thực tế.