INFOCHIEF ACADEMY · ITIL 4 KNOWLEDGE SERIES
Progress Iteratively with Feedback: Tổ chức cải tiến từng bước và học hỏi từ phản hồi.
Cải tiến từng bước cần mục tiêu chung, phạm vi có ý nghĩa và phản hồi có thể thay đổi lựa chọn. Thiết kế từng vòng với trách nhiệm, điều kiện và bằng chứng giúp tổ chức học trước khi tăng phạm vi.
Biên soạn: Infochief Academy · Chuyên đề: Quản lý dịch vụ theo ITIL 4
Một kế hoạch cải tiến có thể được chuẩn bị rất kỹ nhưng vẫn chứa nhiều giả định: người dùng sẽ tiếp nhận cách làm mới, dữ liệu đủ tốt và các nhóm sẽ phối hợp theo thiết kế. Nếu chỉ kiểm tra sau khi triển khai toàn bộ, tổ chức có thể phát hiện vấn đề khi nguồn lực đã dùng nhiều và lựa chọn sửa đã thu hẹp.
Progress Iteratively with Feedback của ITIL 4 giúp tổ chức tiến bằng những phần công việc có thể kiểm chứng, rồi dùng phản hồi để điều chỉnh. Nguyên tắc không chỉ là chia một kế hoạch lớn thành nhiều đợt. Mỗi bước cần tạo hiểu biết hoặc kết quả, và hiểu biết ấy phải ảnh hưởng việc làm tiếp theo.
Giữ mục tiêu chung trước khi chia nhỏ
Một cải tiến cần kết quả mong đợi đủ rõ để các bước cùng hướng tới. Nếu mỗi nhóm chọn một việc dễ làm rồi gọi đó là một vòng cải tiến, tổ chức có thể hoàn thành nhiều đầu ra mà vấn đề chính vẫn tồn tại. Mục tiêu giúp chọn giả định và phạm vi cần kiểm chứng.
Cần ghi điều kiện phải giữ, như chất lượng dữ liệu, quyền, khả năng duy trì hoặc cam kết dịch vụ. Bước nhỏ không có nghĩa tác động luôn nhỏ. Một thay đổi cấu hình ít dòng vẫn có thể ảnh hưởng nhiều người, nên mức kiểm soát phải dựa vào tác động chứ không chỉ độ lớn công việc.
Tình huống giả định xuyên suốt bài: doanh nghiệp muốn người dùng tự gửi đúng yêu cầu qua cổng dịch vụ, nhưng nhiều trường hợp chọn sai hoặc bỏ luồng. Kết quả cần cải thiện là yêu cầu đủ điều kiện để được cung cấp và người dùng tiếp tục được công việc, không chỉ giảm số cuộc gọi.
Nền tảng trong chương trình ITIL 4 Foundation là hướng tham khảo để thống nhất cách dùng nguyên tắc. Trong áp dụng, nhóm phải tiếp tục làm rõ nhu cầu và giới hạn thực tế, để việc chia bước không che một mục tiêu còn mơ hồ.
Chọn một bước đủ nhỏ và đủ ý nghĩa
Phạm vi cần nhỏ để quan sát và điều chỉnh được, nhưng đủ để kiểm tra một mối liên hệ quan trọng. Với cổng dịch vụ, có thể chọn một loại yêu cầu và một nhóm sử dụng. Nếu chỉ sửa màu nút mà chưa tác động điều đang cản lựa chọn, bước thử sẽ khó giúp hiểu vấn đề.
Mỗi bước nên nêu giả định. Chẳng hạn, hướng dẫn ngắn theo công việc sẽ giúp người dùng chọn đúng loại yêu cầu; hoặc dữ liệu được tự lấy từ nguồn đã xác nhận sẽ giảm nhập sai. Viết giả định giúp biết phải quan sát gì và điều gì khiến nhóm đổi phương án.
Cũng cần xác định sản phẩm của bước: một mẫu hướng dẫn, một luồng cung cấp hoặc một thay đổi công cụ. Sản phẩm phải có người nhận và điều kiện sử dụng. Hoàn thành nó chưa chứng minh giả định đúng, nên kế hoạch phải giữ thời gian cùng trách nhiệm kiểm tra sau thực hiện.
Các phụ thuộc cần được xem trước. Nếu muốn thử tự phục vụ nhưng nguồn thông tin vai trò chưa đúng, phải xử lý điều kiện dữ liệu hoặc giới hạn phạm vi. Không nên gọi một thử nghiệm không đủ đầu vào là bằng chứng người dùng không thích cách làm mới.
Năng lực tổ chức phạm vi và giao nhận có thể được phát triển qua chương trình Quản lý Dự án IT. Khi áp dụng, cần giữ khả năng điều chỉnh, để kế hoạch không buộc nhóm triển khai các đợt sau dù phản hồi đã chỉ ra giả định chưa phù hợp.
Thiết kế phản hồi trước khi thực hiện
Phản hồi cần nguồn, thời điểm và người xử lý. Có thể dùng quan sát, dữ liệu, trao đổi với người dùng và thông tin từ nhóm cung cấp. Mỗi nguồn nhìn một phần; ý kiến tích cực chưa tự chứng minh chất lượng, còn tỷ lệ hoàn tất chưa giải thích vì sao những trường hợp khác bị dừng.
Trong thử nghiệm cổng dịch vụ, nhóm theo dõi người dùng chọn loại nào, bước nào phải hỏi lại, điều kiện nào thiếu và công việc sau có tiếp tục được không. Phản hồi từ người bỏ luồng cũng quan trọng, vì chỉ khảo sát người đã hoàn tất có thể bỏ sót vấn đề lớn nhất.
Cần giữ định nghĩa và dữ liệu nền để hiểu điều đã thay đổi. Nếu cách tính hoặc nhóm dùng đổi giữa các vòng, kết quả không còn so sánh đơn giản. Báo cáo phải nêu khác biệt và giới hạn, tránh gán mọi biến động cho biện pháp thử.
| Nội dung một vòng đề xuất | Câu hỏi cần trả lời | Đầu ra để quyết định |
|---|---|---|
| Mục tiêu và giả định | Bước này kiểm tra điều gì? | Cơ chế đóng góp dự kiến |
| Phạm vi và điều kiện | Ai tham gia, điều gì phải giữ? | Giới hạn và trách nhiệm rõ |
| Thực hiện | Cách làm nào được đưa vào thử? | Sản phẩm cùng hồ sơ hoạt động |
| Phản hồi | Quan sát gì từ các bên? | Dữ liệu, điểm dừng và ý kiến |
| Quyết định tiếp theo | Giữ, sửa, mở rộng hay dừng? | Lựa chọn cùng căn cứ và điều kiện |
Bảng là công cụ tổ chức vòng cải tiến đề xuất, không phải phương pháp dự án bắt buộc của ITIL. Có thể dùng trong nhiều cách tổ chức công việc. Điều quan trọng là phản hồi có khả năng thay đổi lựa chọn, không chỉ được thu như một thủ tục cuối bước.
Năng lực tổ chức dịch vụ và cải tiến có thể được phát triển qua chương trình Quản lý Dịch vụ IT – ITSM. Trong thực hành, người sở hữu dịch vụ cần tham gia diễn giải phản hồi, vì dữ liệu kỹ thuật và kết quả người dùng không phải lúc nào cũng nói cùng một điều.
Quyết định bằng bằng chứng, giữ quyền điều chỉnh
Trước thử nghiệm, thống nhất những dấu hiệu để giữ, sửa hoặc dừng. Không cần mọi tình huống đều có một ngưỡng số cứng, nhưng phải biết ai đánh giá và ai có quyền lựa chọn. Nếu kết quả gây tác động vượt phạm vi, cần đường chuyển cấp thay vì để nhóm tự mở rộng hoặc tự chấp nhận hệ quả.
Trong tình huống giả định, phản hồi có thể cho thấy người dùng chọn đúng hơn nhưng phải nhập thông tin đã có ở hệ thống khác. Biện pháp tiếp theo có thể là cải thiện giao nhận dữ liệu, không tiếp tục thêm hướng dẫn. Nếu dữ liệu chưa đủ tin, cần kiểm chứng nguồn trước khi tự động lấy.
Không nên diễn giải phản hồi để bảo vệ phương án đã chọn. Một kết quả chưa đạt có thể là hiểu biết có giá trị nếu nó chỉ ra giả định sai trước khi mở rộng. Nhưng nhóm phải ghi bài học và điều chỉnh, không dùng khái niệm học hỏi để chấp nhận việc lặp lại cùng vấn đề mà không thay lựa chọn.
Người quản lý cần giữ thời gian và nguồn lực cho việc sửa. Nếu mọi người chỉ được giao thực hiện theo lịch mà không có khả năng xử lý phát hiện, vòng phản hồi sẽ bị đứt. Chương trình Trưởng Phòng IT – IT Manager là hướng tham khảo để phát triển cách điều phối những điều kiện này.
Theo hai vòng thử để hiểu điểm nghẽn
Ở vòng đầu của tình huống giả định, nhóm thử cách mô tả yêu cầu bằng ngôn ngữ công việc. Dữ liệu và quan sát cho thấy người dùng hiểu tốt hơn, nhưng nhiều yêu cầu vẫn thiếu thông tin về vai trò. Nhóm nhận ra phần hướng dẫn đã hỗ trợ một điều kiện, còn chất lượng đầu vào chưa đủ để cung cấp.
Vòng tiếp theo tập trung vào một nguồn thông tin vai trò đã được xác nhận. Phạm vi vẫn giữ nhỏ, có cách xử lý khi nguồn không khớp. Nhóm theo dõi việc nhập lại, chất lượng yêu cầu và khả năng xử lý sau tiếp nhận. Nếu phần tự lấy dữ liệu giúp tiến triển, cần xác định điều kiện duy trì trước khi mở rộng.
Hai vòng không được trình như kết quả thực của một doanh nghiệp; đây là tình huống giả định để minh họa cách học. Điều cần thấy là bước sau được chọn từ phát hiện của bước trước. Nhóm không chỉ chia cùng một phương án thành hai đợt triển khai rồi gọi đó là cải tiến lặp.
Cũng cần quan sát tác động lên người cung cấp. Một trải nghiệm tốt hơn ở cổng có thể làm nhóm xử lý nhận nhiều yêu cầu mà năng lực chưa sẵn sàng. Cách nhìn toàn luồng giúp xác định việc cần phối hợp, để cải tiến một điểm không tạo quá tải ở điểm sau.
Mở rộng khi điều kiện có thể duy trì
Sau các vòng phù hợp, quyết định mở rộng cần dựa vào kết quả, rủi ro và nguồn lực. Không nên mặc định thử tốt ở một nhóm sẽ tốt ở mọi nhóm. Sự khác nhau về vai trò, dữ liệu, giờ làm hoặc đối tác có thể yêu cầu một vòng kiểm chứng thêm.
Người sở hữu thường xuyên cần nhận cách làm, dữ liệu và trách nhiệm. Nếu kết quả chỉ được giữ nhờ nhóm thử xử lý ngoại lệ thủ công, cần tổ chức khả năng duy trì trước khi tăng phạm vi. Cải tiến có chất lượng phải tạo cách làm dùng được sau khi hỗ trợ đặc biệt kết thúc.
Nhóm nên lưu giả định, phát hiện và lựa chọn để các vòng sau không phải học lại từ đầu. Việc ghi có thể gọn, nhưng phải đủ giải thích vì sao giữ hoặc đổi. Khi nhu cầu thay đổi, những căn cứ này giúp xác định phần nào còn phù hợp thay vì giữ cách làm chỉ vì đã được triển khai.
Progress Iteratively with Feedback tạo khả năng tiến có kiểm soát trong điều kiện chưa biết hết. Mục tiêu giữ hướng, phạm vi giúp kiểm chứng, phản hồi giúp học và quyền điều chỉnh giúp sử dụng điều đã học. Khi bốn phần được nối, doanh nghiệp có thể cải tiến từng bước mà vẫn đi tới kết quả chung.