Cách xác định phạm vi của giải pháp

Ranh giới này đặc biệt quan trọng khi một vấn đề có nhiều nguyên nhân hoặc liên quan đến nhiều hệ thống, quy trình và bên tham gia. Không phải mọi yếu tố có liên quan đến vấn đề đều phải nằm trong giải pháp. Chỉ những yếu tố cần được can thiệp để giải quyết đúng vấn đề đã xác định mới nên được đưa vào phạm vi.

Bắt đầu phạm vi từ vấn đề mà giải pháp phải xử lý

Phạm vi trước hết phải được neo vào vấn đề cần giải quyết. Câu hỏi trọng tâm không phải là “giải pháp có thể làm được những gì?”, mà là “giải pháp cần xử lý phần nào của vấn đề để đạt kết quả mong muốn?”.

Nếu vấn đề được xác định quá rộng, phạm vi giải pháp cũng dễ bị mở rộng theo. Chẳng hạn, một tổ chức phát hiện thời gian xử lý yêu cầu khách hàng quá lâu. Nếu nguyên nhân trực tiếp nằm ở bước tiếp nhận và phân loại yêu cầu, giải pháp có thể chỉ cần tập trung vào hai bước này. Việc đồng thời thay đổi toàn bộ hệ thống chăm sóc khách hàng, chính sách nhân sự và cơ cấu tổ chức chỉ vì chúng có liên quan sẽ làm phạm vi vượt khỏi vấn đề thực sự cần can thiệp.

Do đó, trước khi chốt phạm vi cần làm rõ ba điểm: trạng thái hiện tại cần thay đổi, kết quả cần đạt được và phần nguyên nhân mà giải pháp có khả năng tác động. Ba điểm này tạo ranh giới ban đầu để đánh giá một yêu cầu có thuộc giải pháp hay không.

Xác định rõ những gì nằm trong phạm vi giải pháp

Phần được bao gồm phải mô tả đủ cụ thể để những người tham gia có thể nhận biết đâu là trách nhiệm của giải pháp. Tùy bản chất vấn đề, phạm vi có thể bao gồm quy trình, chức năng, nhóm người dùng, dữ liệu, khu vực hoạt động, bước nghiệp vụ hoặc điểm tương tác mà giải pháp phải xử lý.

Thay vì ghi chung chung rằng “cải thiện quy trình tiếp nhận yêu cầu”, phạm vi có thể xác định rõ hơn rằng giải pháp xử lý việc ghi nhận yêu cầu, chuẩn hóa thông tin đầu vào, phân loại yêu cầu và chuyển yêu cầu đến đúng nhóm phụ trách. Khi đó, mỗi thành phần đều có quan hệ trực tiếp với vấn đề đã xác định.

Một nội dung chỉ nên được đưa vào phạm vi khi có thể giải thích được vai trò của nó đối với kết quả cần đạt. Nếu loại bỏ một hạng mục mà khả năng giải quyết vấn đề không thay đổi đáng kể, hạng mục đó cần được xem xét lại thay vì mặc nhiên giữ trong phạm vi.

Ghi rõ những gì bị loại trừ khỏi giải pháp

Phần loại trừ quan trọng không kém phần được bao gồm. Nếu chỉ mô tả những gì giải pháp sẽ làm, các bên liên quan vẫn có thể suy diễn rằng những nội dung có liên quan khác cũng sẽ được xử lý.

Giả sử giải pháp tập trung rút ngắn thời gian phân loại yêu cầu khách hàng. Phạm vi có thể bao gồm việc chuẩn hóa dữ liệu đầu vào và tự động chuyển yêu cầu, nhưng loại trừ việc thay đổi chính sách giá, thiết kế lại sản phẩm hoặc tái cấu trúc bộ phận chăm sóc khách hàng. Các nội dung này có thể ảnh hưởng đến trải nghiệm khách hàng, nhưng không trực tiếp thuộc phần vấn đề mà giải pháp đang chịu trách nhiệm.

Loại trừ không có nghĩa là một vấn đề không quan trọng. Nó chỉ xác nhận rằng vấn đề đó không được giải quyết trong phạm vi hiện tại. Sự phân biệt này giúp tránh nhầm lẫn giữa “có liên quan” và “thuộc trách nhiệm của giải pháp”.

Một loại trừ tốt nên đủ cụ thể để có thể dùng khi phát sinh yêu cầu mới. Khi có đề xuất bổ sung, có thể đối chiếu trực tiếp với ranh giới đã xác định thay vì tranh luận lại phạm vi từ đầu.

Đặt ranh giới bằng đối tượng, điểm giao tiếp và điều kiện giới hạn

Chỉ ghi “bao gồm” và “không bao gồm” đôi khi chưa đủ. Phạm vi còn cần chỉ ra nơi trách nhiệm của giải pháp bắt đầu, nơi nó kết thúc và điều kiện mà giải pháp được giả định sẽ hoạt động.

Ranh giới có thể được xác định theo nhiều chiều. Với một quy trình, đó có thể là bước bắt đầu và bước kết thúc. Với một hệ thống, đó có thể là nhóm người dùng, dữ liệu được xử lý và các hệ thống bên ngoài chỉ được kết nối chứ không bị thay đổi. Với một hoạt động vận hành, ranh giới có thể nằm ở đơn vị tổ chức, địa điểm hoặc trường hợp sử dụng cụ thể.

Các ràng buộc và giả định cũng cần được thể hiện khi chúng ảnh hưởng trực tiếp đến phạm vi. Ví dụ, một giải pháp có thể được thiết kế trên giả định rằng hệ thống dữ liệu hiện tại vẫn được giữ nguyên. Khi đó, việc thay thế toàn bộ hệ thống dữ liệu không thể tự động được xem là một phần của giải pháp.

Cách xác định này làm rõ một điểm thường bị bỏ sót: giải pháp có thể tương tác với một thành phần mà không chịu trách nhiệm thay đổi thành phần đó. Phân biệt được hai mức này giúp ranh giới chính xác hơn.

Kiểm tra phạm vi bằng tình huống cụ thể và kết quả cần đạt

Một phạm vi có thể nghe rõ ràng trên văn bản nhưng vẫn mơ hồ khi áp dụng. Vì vậy, nên kiểm tra bằng các tình huống thực tế: nếu một yêu cầu cụ thể xuất hiện, có thể xác định ngay nó nằm trong hay ngoài phạm vi hay không?

Có thể sử dụng ba câu hỏi để kiểm tra:

·         Yêu cầu này có trực tiếp phục vụ vấn đề và kết quả đã xác định không

·         Giải pháp có được xác định là bên chịu trách nhiệm xử lý đối tượng hoặc công đoạn này không

·         Nếu không thực hiện yêu cầu này, mục tiêu cốt lõi của giải pháp có bị ảnh hưởng không

Ví dụ, nếu mục tiêu là giảm thời gian chuyển yêu cầu khách hàng đến đúng bộ phận, chức năng tự động phân loại có quan hệ trực tiếp với kết quả. Trong khi đó, thiết kế lại giao diện toàn bộ cổng khách hàng có thể hữu ích nhưng chưa chắc cần thiết để đạt mục tiêu đó. Trường hợp sau chỉ nên được đưa vào phạm vi khi có quan hệ cần thiết với kết quả, không phải vì nó là một cải tiến hấp dẫn.

Phép kiểm tra này cũng giúp phát hiện hai lỗi đối lập: phạm vi quá hẹp khiến giải pháp không đủ khả năng xử lý vấn đề và phạm vi quá rộng khiến nguồn lực bị phân tán sang những nội dung không cần thiết.

Kiểm soát thay đổi để phạm vi không mở rộng ngoài mục tiêu

Phạm vi đã xác định không có nghĩa là bất biến. Trong quá trình phân tích hoặc triển khai, thông tin mới có thể cho thấy một nội dung ban đầu bị loại trừ thực ra cần thiết để giải quyết vấn đề. Khi đó phạm vi có thể thay đổi, nhưng thay đổi phải có lý do gắn với mục tiêu của giải pháp.

Một yêu cầu mới không nên được bổ sung chỉ vì “tiện làm cùng”, “có liên quan” hoặc “sẽ tốt hơn nếu có”. Cần đánh giá yêu cầu đó có thay đổi khả năng đạt kết quả hay không, có làm dịch chuyển ranh giới trách nhiệm hay không và có kéo theo các phần việc khác ngoài dự kiến hay không.

Nếu một thay đổi thực sự cần thiết, phạm vi bao gồm, phạm vi loại trừ và các ranh giới liên quan cũng phải được cập nhật đồng bộ. Nếu không, mô tả phạm vi cũ sẽ không còn phản ánh đúng trách nhiệm thực tế của giải pháp.

Cách kiểm soát này giữ cho phạm vi phục vụ vấn đề thay vì biến thành danh sách ngày càng dài của mọi cải tiến có thể thực hiện.

Phạm vi của giải pháp cần xác định rõ vấn đề được xử lý, những gì được bao gồm, những gì bị loại trừ, ranh giới trách nhiệm, điều kiện giới hạn và kết quả mà giải pháp phải tạo ra. Một nội dung không nên được đưa vào chỉ vì có liên quan đến vấn đề; nó phải có vai trò cần thiết đối với kết quả mà giải pháp chịu trách nhiệm. Khi cả phần bao gồm và loại trừ đều được diễn đạt đủ rõ để kiểm tra bằng tình huống thực tế, phạm vi trở thành cơ sở hữu ích để giữ giải pháp tập trung và kiểm soát các yêu cầu phát sinh.