Chuyển yêu cầu nghiệp vụ và yêu cầu công nghệ như thế nào?

Vì vậy, hai loại yêu cầu không nên được nối với nhau bằng cách dịch câu chữ. Cầu nối thực sự là chức năng và tiêu chí đo. Mỗi nhu cầu kinh doanh cần được phân rã thành hành vi hệ thống có thể quan sát, sau đó gắn với điều kiện chấp nhận để chứng minh rằng giải pháp công nghệ thực sự tạo ra kết quả nghiệp vụ mong muốn.

Không nên chuyển thẳng yêu cầu nghiệp vụ thành giải pháp công nghệ

Sai lệch thường xuất hiện khi một phát biểu nghiệp vụ được biến ngay thành tên công nghệ hoặc tính năng. Chẳng hạn, “cần giảm thời gian phê duyệt đơn” là yêu cầu về kết quả nghiệp vụ. “Xây ứng dụng mobile”, “dùng AI” hay “triển khai microservice” lại là phương án thiết kế. Chúng chưa chứng minh được tại sao giải pháp sẽ làm thời gian phê duyệt giảm.

Điểm trung gian cần làm rõ là hệ thống phải thay đổi cách công việc được thực hiện như thế nào. Với mục tiêu giảm thời gian phê duyệt, những chức năng có thể liên quan gồm tự động kiểm tra dữ liệu đầu vào, định tuyến hồ sơ theo thẩm quyền, cảnh báo hồ sơ sắp quá hạn và ghi nhận trạng thái theo thời gian thực. Khi đó mới có cơ sở xác định yêu cầu về dữ liệu, giao diện, tích hợp, hiệu năng và bảo mật.

Cách phân biệt này phù hợp với tư duy phân tích nghiệp vụ của IIBA BABOK: requirement biểu diễn một nhu cầu cần được đáp ứng, còn design mô tả cách một giải pháp có thể đáp ứng nhu cầu đó. Nếu quyết định thiết kế xuất hiện trước khi nhu cầu và hành vi cần thiết được làm rõ, tổ chức dễ tối ưu một giải pháp mà chưa xác nhận nó giải quyết đúng vấn đề.

Chuỗi chuyển đổi phải đi từ kết quả đến hành vi hệ thống

Một yêu cầu công nghệ tốt phải giữ được quan hệ nhân quả với yêu cầu nghiệp vụ ban đầu. Chuỗi chuyển đổi có thể biểu diễn như sau:

Mục tiêu nghiệp vụ → quy trình/quy tắc bị tác động → chức năng cần có → dữ liệu và điều kiện xử lý → yêu cầu chất lượng kỹ thuật → tiêu chí chấp nhận → chỉ số nghiệp vụ

Mỗi lớp trả lời một câu hỏi khác nhau.

Chuỗi này ngăn hai lỗi đối nghịch. Nếu dừng ở mục tiêu nghiệp vụ, đội kỹ thuật không có đủ thông tin để xây dựng. Nếu nhảy thẳng xuống kiến trúc hoặc công nghệ, đội dự án mất khả năng chứng minh từng thành phần kỹ thuật phục vụ mục tiêu nào.

Dùng chức năng làm cầu nối giữa nghiệp vụ và công nghệ

Chức năng là lớp chuyển đổi quan trọng nhất vì nó mô tả hành vi mà cả phía nghiệp vụ lẫn phía kỹ thuật đều có thể kiểm tra.

Giả sử yêu cầu nghiệp vụ là: “Giảm tỷ lệ đơn hàng bị hủy do xác nhận tồn kho chậm.”

Không nên chuyển thành: “Cần xây API tồn kho thời gian thực.” API đã là một lựa chọn giải pháp. Trước hết cần xác định hành vi cần thiết:

Khi người dùng đặt hàng, hệ thống phải xác nhận khả năng cấp hàng dựa trên tồn kho khả dụng trước khi đơn được chuyển sang bước thanh toán hoặc xử lý tiếp theo.

Từ hành vi này mới phát sinh các câu hỏi kỹ thuật có ý nghĩa: tồn kho khả dụng nằm ở hệ thống nào, dữ liệu cần mới đến mức nào, khi nguồn tồn kho không phản hồi thì xử lý ra sao, có cần giữ hàng tạm thời hay không, nhiều giao dịch đồng thời được kiểm soát thế nào.

Như vậy, chức năng không chỉ là “một tính năng cần xây”. Nó là mắt xích giải thích vì sao một thay đổi kỹ thuật có khả năng tác động đến kết quả nghiệp vụ.

Một chức năng có thể sinh nhiều yêu cầu công nghệ

Một chức năng nghiệp vụ thường không tương ứng một-một với một yêu cầu kỹ thuật. Chức năng “xác nhận tồn kho trước khi nhận đơn”, chẳng hạn, có thể tạo ra yêu cầu về:

·         Giao tiếp với hệ thống quản lý tồn kho

·         Quy tắc xác định số lượng khả dụng

·         Cơ chế xử lý khi dịch vụ nguồn không phản hồi

·         Kiểm soát truy cập dữ liệu

·         Thời gian phản hồi tối đa

·         Nhật ký giao dịch phục vụ đối soát

Các yêu cầu này cùng phục vụ một hành vi nhưng kiểm soát những thuộc tính khác nhau của hành vi đó.

Yêu cầu công nghệ phải mô tả cả chức năng và điều kiện chất lượng

Chỉ xác định hệ thống “phải làm gì” vẫn chưa đủ. Hai hệ thống có thể cùng thực hiện một chức năng nhưng tạo ra kết quả nghiệp vụ rất khác nhau nếu tốc độ, độ chính xác, khả năng chịu tải hoặc mức sẵn sàng khác nhau.

Ví dụ:

Hệ thống phải hiển thị trạng thái hồ sơ cho người dùng.

Đây là yêu cầu chức năng, nhưng chưa xác định trạng thái phải cập nhật nhanh đến đâu. Nếu nghiệp vụ cần nhân viên xử lý hồ sơ ngay sau khi trạng thái thay đổi, độ trễ cập nhật trở thành yêu cầu có ảnh hưởng trực tiếp đến kết quả.

Một đặc tả đầy đủ hơn có thể tách thành:

Hệ thống phải cập nhật trạng thái hồ sơ khi bước xử lý hoàn tất.

và:

Trạng thái mới phải khả dụng cho người dùng trong vòng 5 giây kể từ khi giao dịch cập nhật được xác nhận.

Con số 5 giây chỉ hợp lệ khi xuất phát từ nhu cầu vận hành hoặc một giới hạn đã được thống nhất; không nên chọn tùy ý chỉ để biến câu chữ thành định lượng.

ISO/IEC/IEEE 29148 về kỹ thuật yêu cầu nhấn mạnh các đặc tính như khả năng xác minh, tính rõ ràng và khả năng truy vết của yêu cầu. Trong thực tế, một câu như “hệ thống phải nhanh”, “dễ sử dụng” hoặc “bảo mật cao” khó kiểm chứng vì không xác định được trạng thái đạt hay không đạt.

Tiêu chí đo biến yêu cầu thành thứ có thể nghiệm thu

Tiêu chí đo là điểm liên kết giữa kỳ vọng nghiệp vụ, đặc tả kỹ thuật và kiểm thử. Một yêu cầu chỉ có thể được quản trị đáng tin cậy khi các bên biết bằng chứng nào sẽ được dùng để xác nhận nó.

Không phải mọi yêu cầu đều cần một con số. Nhưng mỗi yêu cầu phải có điều kiện xác minh khách quan.

Với một quy tắc nghiệp vụ, tiêu chí có thể là:

Nếu giá trị giao dịch lớn hơn 500 triệu đồng, hồ sơ phải được chuyển đến vai trò phê duyệt cấp 2.

Với hiệu năng:

95% yêu cầu tra cứu phải có thời gian phản hồi không quá 2 giây trong điều kiện tải đã xác định.

Với kiểm soát truy cập:

Người dùng không có quyền phê duyệt không được thực hiện hành động phê duyệt qua giao diện hoặc API.

Ở đây, ngưỡng 500 triệu, 95% hay 2 giây phải đến từ quy định nghiệp vụ, SLA, benchmark hoặc quyết định thiết kế đã được xác nhận. Không nên đưa một con số vào requirement nếu không giải thích được nguồn của ngưỡng đó.

Phân biệt tiêu chí kỹ thuật và kết quả nghiệp vụ

Một lỗi khác là dùng tiêu chí kỹ thuật làm bằng chứng duy nhất cho thành công nghiệp vụ.

“API phản hồi dưới 500 ms” chứng minh API đạt mục tiêu hiệu năng đã đặt ra, nhưng không tự chứng minh “thời gian xử lý đơn hàng đã giảm 30%”. Kết quả cuối còn phụ thuộc các bước thủ công, quy tắc phê duyệt, chất lượng dữ liệu và những hệ thống khác.

Do đó cần hai tầng đo:

Tiêu chí chấp nhận kỹ thuật xác nhận hệ thống hoạt động đúng theo requirement.

KPI nghiệp vụ xác nhận thay đổi hệ thống thực sự cải thiện kết quả mà tổ chức quan tâm.

Hai tầng phải liên kết, nhưng không được coi là một.

Giữ truy vết từ mục tiêu nghiệp vụ đến yêu cầu kỹ thuật

Khi một dự án có hàng chục hoặc hàng trăm requirement, quan hệ giữa chúng cần được ghi nhận thay vì dựa vào trí nhớ của BA, Product Owner hoặc kỹ sư.

Mỗi yêu cầu công nghệ nên trả lời được ít nhất ba câu hỏi:

Nó xuất phát từ yêu cầu nghiệp vụ nào?

Nó hỗ trợ chức năng hoặc quy tắc nào?

Điều gì chứng minh nó đã được đáp ứng?

Có thể quản lý quan hệ này bằng mã định danh và ma trận truy vết. Ví dụ:

Giá trị của truy vết thể hiện rõ khi requirement thay đổi. Nếu ngưỡng nghiệp vụ, quy tắc xử lý hoặc chức năng bị điều chỉnh, nhóm dự án có thể xác định những thành phần kỹ thuật và ca kiểm thử nào chịu ảnh hưởng.

Truy vết theo chiều ngược lại cũng quan trọng. Nếu một yêu cầu kỹ thuật không thể liên kết đến mục tiêu, chức năng, ràng buộc hoặc yêu cầu chất lượng đã được chấp thuận, cần đặt câu hỏi liệu nó có thực sự cần thiết hay chỉ là một quyết định kỹ thuật được đưa vào phạm vi mà chưa có lý do nghiệp vụ rõ ràng.

Một ví dụ hoàn chỉnh về chuyển đổi yêu cầu

Giả sử doanh nghiệp xác định vấn đề:

Thời gian xử lý yêu cầu hoàn tiền đang quá dài, làm tăng số lượt khách hàng liên hệ lại.

Yêu cầu nghiệp vụ có thể được chuẩn hóa thành:

Giảm thời gian từ lúc tiếp nhận yêu cầu hoàn tiền hợp lệ đến lúc hoàn tất quyết định xử lý.

Tiếp theo, phân tích nguyên nhân cho thấy nhân viên đang phải kiểm tra thủ công trạng thái thanh toán và đối chiếu điều kiện hoàn tiền.

Từ đó hình thành các chức năng:

Hệ thống tự động lấy trạng thái thanh toán của giao dịch.

Hệ thống đánh giá yêu cầu theo các quy tắc hoàn tiền đã được phê duyệt.

Hồ sơ không đủ điều kiện tự động phải được chuyển cho nhân viên xử lý cùng lý do cụ thể.

Những chức năng này có thể tiếp tục sinh yêu cầu công nghệ về tích hợp cổng thanh toán, cấu trúc dữ liệu giao dịch, công cụ quản lý quy tắc, phân quyền và ghi log.

Tiêu chí chấp nhận cho một chức năng có thể là:

Với giao dịch có đầy đủ dữ liệu và đáp ứng điều kiện tự động, hệ thống phải trả về kết quả đánh giá mà không yêu cầu nhân viên nhập lại thông tin đã có.

Nếu doanh nghiệp đặt mục tiêu “80% hồ sơ đủ điều kiện được đánh giá tự động”, tỷ lệ 80% trở thành KPI nghiệp vụ hoặc mục tiêu giải pháp khi có cơ sở dữ liệu chứng minh ngưỡng này khả thi. Nó không nên được biến thành requirement chỉ vì nhóm dự án muốn có một con số đẹp.

Ví dụ cho thấy một mục tiêu nghiệp vụ không được “dịch” thành một requirement công nghệ duy nhất. Nó được phân rã thành một chuỗi quan hệ có thể giải thích và kiểm chứng.

Kiểm tra chất lượng bằng câu hỏi “vì sao” và “đo bằng gì”

Trước khi chốt requirement, hai câu hỏi ngắn có thể phát hiện phần lớn khoảng trống trong chuỗi chuyển đổi.

Với mỗi yêu cầu kỹ thuật, hỏi:

Vì sao hệ thống cần điều này?

Câu trả lời phải dẫn được về chức năng, ràng buộc hoặc mục tiêu nghiệp vụ. Nếu chỉ nhận được câu trả lời như “kiến trúc chuẩn là vậy”, “đội kỹ thuật thường làm thế” hoặc “công nghệ này hiện đại hơn”, requirement có thể đang chứa quyết định thiết kế chưa được chứng minh.

Sau đó hỏi:

Đo hoặc kiểm chứng bằng gì?

Nếu không xác định được test, điều kiện quan sát, dữ liệu đối chiếu hoặc chỉ số phù hợp, requirement có khả năng còn mơ hồ.

Hai câu hỏi tạo thành một kiểm tra đơn giản:

Có lý do nghiệp vụ nhưng không đo được → requirement chưa đủ rõ

Đo được nhưng không có lý do nghiệp vụ hoặc ràng buộc hợp lệ → có nguy cơ xây thứ không cần thiết

Có cả lý do và tiêu chí kiểm chứng → requirement có nền tảng tốt hơn để thiết kế, kiểm thử và quản lý thay đổi

Những lỗi thường làm đứt liên kết giữa hai loại yêu cầu

Lỗi phổ biến nhất là mô tả giải pháp thay cho nhu cầu. “Phải dùng chatbot AI” không cho biết vấn đề nào cần giải quyết hoặc mức cải thiện nào được kỳ vọng. Khi công nghệ bị khóa quá sớm, các phương án khác có thể bị loại trước khi được đánh giá.

Lỗi thứ hai là giữ requirement ở dạng định tính. “Xử lý nhanh”, “giao diện thân thiện”, “hệ thống ổn định” đều thiếu điều kiện kiểm chứng. Cần xác định thuộc tính quan trọng đối với nghiệp vụ và cách đánh giá thuộc tính đó trong bối cảnh vận hành cụ thể.

Lỗi thứ ba là tạo quá nhiều yêu cầu kỹ thuật nhưng không duy trì truy vết. Phạm vi sau đó có thể tiếp tục tăng vì không ai xác định được requirement nào bắt buộc, requirement nào chỉ hỗ trợ và requirement nào đã mất lý do tồn tại sau một thay đổi nghiệp vụ.

Cuối cùng, không phải mọi yêu cầu công nghệ đều cần dẫn trực tiếp đến một KPI doanh thu hoặc năng suất. Yêu cầu về bảo mật, lưu vết, tuân thủ, khả năng phục hồi hoặc tính toàn vẹn dữ liệu có thể xuất phát từ ràng buộc pháp lý, rủi ro hoặc tiêu chuẩn vận hành. Điều bắt buộc vẫn là phải xác định được nguồn và lý do của requirement, thay vì gán cho nó một lợi ích kinh doanh không có căn cứ.

Yêu cầu nghiệp vụ và yêu cầu công nghệ liên kết tốt khi có một chuỗi lý giải liên tục: kết quả cần đạt → hành vi cần thay đổi → chức năng hệ thống → điều kiện kỹ thuật → tiêu chí kiểm chứng. Chức năng trả lời hệ thống phải làm gì để phục vụ nghiệp vụ; tiêu chí đo xác định khi nào có thể coi yêu cầu đã được đáp ứng; truy vết bảo đảm mối quan hệ đó không bị mất khi phạm vi thay đổi.

Do đó, mục tiêu không phải là “dịch” tài liệu nghiệp vụ sang ngôn ngữ kỹ thuật. Mục tiêu là biến nhu cầu thành các requirement mà mỗi yêu cầu đều có nguồn gốc, chức năng, điều kiện và bằng chứng chấp nhận rõ ràng. Khi làm được điều này, đội nghiệp vụ có thể kiểm tra giải pháp có tạo đúng giá trị hay không, còn đội công nghệ có đủ căn cứ để thiết kế, xây dựng và kiểm thử mà không phải tự suy đoán ý định ban đầu.