Cách doanh nghiệp xác định yêu cầu công nghệ

Cách tiếp cận này phù hợp với requirements engineering: ISO/IEC/IEEE 29148:2018 quy định các quá trình tạo và quản lý yêu cầu đối với hệ thống, phần mềm, phần cứng và dịch vụ trong suốt vòng đời. Đối với yêu cầu chất lượng, ISO/IEC 25010:2023 cung cấp mô hình gồm chín đặc tính để hỗ trợ việc đặc tả, đo lường và đánh giá sản phẩm ICT.

Bắt đầu từ nhu cầu nghiệp vụ thay vì tên công nghệ

Nhu cầu nghiệp vụ mô tả vấn đề cần giải quyết hoặc kết quả cần đạt. Nó chưa phải yêu cầu kỹ thuật. Ví dụ, “rút ngắn thời gian xử lý đơn hàng” là mục tiêu nghiệp vụ; “xây dựng ứng dụng microservices” đã là một lựa chọn thiết kế. Nếu doanh nghiệp nhảy trực tiếp từ mục tiêu sang giải pháp, yêu cầu rất dễ bị khóa vào một công nghệ trước khi biết công nghệ đó có thực sự cần thiết hay không.

Doanh nghiệp cần phân rã mục tiêu thành những thay đổi có thể quan sát được trong quy trình. Với mục tiêu giảm thời gian xử lý đơn, các câu hỏi có giá trị hơn là:

·         Công đoạn nào hiện tạo ra thời gian chờ

·         Thông tin nào đang phải nhập lại hoặc kiểm tra thủ công

·         Hệ thống nào phải trao đổi dữ liệu

·         Số lượng giao dịch cần xử lý trong giờ cao điểm là bao nhiêu

·         Sai sót nào phải được ngăn chặn

·         Kết quả nào sẽ chứng minh quy trình mới tốt hơn quy trình hiện tại

Từ đó mới hình thành yêu cầu. Chẳng hạn, nếu nhân viên đang phải nhập lại thông tin đơn hàng từ một hệ thống khác, nhu cầu thực có thể dẫn tới yêu cầu đồng bộ dữ liệu hoặc API, chứ chưa đủ căn cứ để kết luận doanh nghiệp cần thay toàn bộ hệ thống.

Các chỉ tiêu kinh doanh cũng phải được liên kết với chỉ tiêu hệ thống. “Xử lý nhanh” cần được chuyển thành thời gian phản hồi hoặc thời gian hoàn tất giao dịch; “không gián đoạn hoạt động” cần được chuyển thành mức sẵn sàng, thời gian phục hồi hoặc mức mất dữ liệu chấp nhận được. Ngưỡng cụ thể phải xuất phát từ mức mà hoạt động kinh doanh thực sự yêu cầu, không phải từ một con số kỹ thuật được chọn tùy ý.

Thu thập yêu cầu từ người dùng theo công việc thực tế

Một hệ thống có thể đáp ứng quy trình trên giấy nhưng vẫn thất bại nếu người sử dụng phải thực hiện quá nhiều thao tác, không tìm được thông tin cần thiết hoặc phải tạo các cách xử lý bên ngoài hệ thống.

Vì vậy, doanh nghiệp cần nghiên cứu người dùng trong bối cảnh làm việc thật: họ thực hiện nhiệm vụ nào, theo trình tự nào, sử dụng dữ liệu gì, cần quyết định điều gì và gặp trở ngại ở đâu. Phỏng vấn stakeholder chỉ cung cấp một phần thông tin; quan sát quy trình, phân tích dữ liệu vận hành, xem ticket hỗ trợ, lỗi nhập liệu và các bước xử lý ngoại lệ thường làm lộ ra những yêu cầu mà người dùng khó diễn đạt trực tiếp.

ISO 9241-210:2019 đặt thiết kế lấy con người làm trung tâm trong toàn bộ vòng đời của hệ thống tương tác và áp dụng cho cả thành phần phần cứng lẫn phần mềm. Phiên bản này được ISO rà soát và xác nhận lại năm 2025.

Nhu cầu “dễ sử dụng” do đó không nên được giữ nguyên dưới dạng một tính từ. Nó cần chuyển thành các điều kiện kiểm chứng được, chẳng hạn người dùng phải hoàn thành một tác vụ nhất định với số bước hợp lý, tỷ lệ hoàn thành đạt ngưỡng đã thống nhất, lỗi nhập liệu không vượt giới hạn hoặc giao diện đáp ứng yêu cầu accessibility áp dụng cho tổ chức.

Một điểm dễ bị bỏ sót là khác biệt giữa các nhóm người dùng. Nhân viên vận hành, quản lý, khách hàng, bộ phận kiểm soát và quản trị viên có thể cùng sử dụng một hệ thống nhưng có quyền truy cập, dữ liệu, tần suất sử dụng và mức độ thành thạo rất khác nhau. Một yêu cầu chung cho “người dùng” thường không đủ chính xác để thiết kế và nghiệm thu.

Chuyển điều kiện vận hành thành ràng buộc kỹ thuật

Nhu cầu nghiệp vụ cho biết hệ thống phải tạo ra kết quả gì; điều kiện vận hành xác định hệ thống phải làm được điều đó trong hoàn cảnh nào.

Doanh nghiệp cần khảo sát môi trường hiện tại trước khi chốt yêu cầu: hạ tầng, mạng, thiết bị đầu cuối, hệ thống kế thừa, dữ liệu, giờ hoạt động, địa điểm sử dụng, lượng tải, quy trình sao lưu, năng lực đội vận hành và những phụ thuộc vào bên thứ ba.

Từ môi trường này có thể xuất hiện các yêu cầu hoàn toàn khác nhau. Một ứng dụng văn phòng chỉ hoạt động trong giờ hành chính không có cùng yêu cầu sẵn sàng với nền tảng xử lý giao dịch 24/7. Một hệ thống tại nhà máy có thể phải ưu tiên độ tin cậy, an toàn và khả năng tiếp tục vận hành trong điều kiện mà hệ thống văn phòng không gặp phải. NIST lưu ý rằng môi trường Operational Technology có các yêu cầu riêng về hiệu năng, độ tin cậy và an toàn bên cạnh yêu cầu an ninh mạng.

Các điều kiện vận hành thường phải được chuyển thành chỉ tiêu như:

·         Số người dùng đồng thời và thông lượng giao dịch

·         Thời gian phản hồi ở mức tải xác định

·         Mức sẵn sàng và cửa sổ bảo trì

·         RTO và RPO khi xảy ra sự cố

·         Dung lượng dữ liệu và tốc độ tăng trưởng

·         Hệ thống, giao thức hoặc API phải tích hợp

·         Phiên bản thiết bị, hệ điều hành hoặc trình duyệt phải hỗ trợ

·         Yêu cầu giám sát, logging, backup và khôi phục

·         Giới hạn về vị trí lưu trữ hoặc truyền dữ liệu

Không phải dự án nào cũng cần tất cả các chỉ số trên. Chỉ những điều kiện có khả năng ảnh hưởng tới hoạt động, thiết kế hoặc tiêu chí nghiệm thu mới nên trở thành yêu cầu.

Phân loại yêu cầu để tránh bỏ sót chất lượng hệ thống

Sau khi thu thập nhu cầu, doanh nghiệp cần tách chúng thành các nhóm có chức năng khác nhau.

Yêu cầu chức năng mô tả hệ thống phải thực hiện hành vi nào: tạo đơn, tính giá, phê duyệt, gửi cảnh báo, đồng bộ dữ liệu hoặc tạo báo cáo. Tuy nhiên, danh sách chức năng không đủ để xác định một hệ thống có đáp ứng nhu cầu hay không. Hai sản phẩm có thể có cùng chức năng nhưng khác nhau đáng kể về tốc độ, bảo mật, khả năng phục hồi hoặc khả năng bảo trì.

Do đó cần xác định cả yêu cầu chất lượng. ISO/IEC 25010:2023 cung cấp mô hình chất lượng sản phẩm ICT gồm chín đặc tính và nêu rõ mô hình này có thể được sử dụng để xác định yêu cầu, kiểm tra tính đầy đủ của yêu cầu, xây dựng mục tiêu kiểm thử và thiết lập tiêu chí nghiệm thu.

Ngoài chức năng và chất lượng còn có các ràng buộc. Ví dụ, hệ thống có thể bắt buộc phải trao đổi dữ liệu với một nền tảng hiện hữu, triển khai trong hạ tầng đã được phê duyệt hoặc tuân theo chính sách lưu trữ dữ liệu của doanh nghiệp. Ràng buộc khác với yêu cầu chức năng: nó giới hạn không gian giải pháp mà công nghệ phải đáp ứng.

Bảo mật cũng không nên được thêm vào cuối dự án dưới dạng một yêu cầu chung như “hệ thống phải an toàn”. NIST Cybersecurity Framework 2.0 tổ chức quản trị an ninh mạng theo các kết quả cần đạt và nhấn mạnh việc hiểu, đánh giá, ưu tiên và truyền đạt rủi ro; framework không ép tổ chức phải sử dụng một công nghệ cụ thể để đạt các kết quả đó.

Cách tiếp cận tương tự có thể áp dụng khi xác định yêu cầu: trước hết xác định tài sản, dữ liệu, quyền truy cập, tình huống rủi ro và mức hậu quả chấp nhận được; sau đó mới chuyển chúng thành yêu cầu kiểm soát phù hợp.

Viết mỗi yêu cầu theo cách có thể đo và kiểm chứng

Một yêu cầu chỉ hữu ích khi các bên có thể xác định tương đối rõ hệ thống đã đáp ứng hay chưa. Những câu như “hệ thống phải nhanh”, “giao diện thân thiện”, “bảo mật cao” hoặc “dễ mở rộng” không tạo được cơ sở nghiệm thu vì mỗi stakeholder có thể hiểu chúng khác nhau.

Yêu cầu tốt cần chỉ ra đối tượng, hành vi hoặc thuộc tính cần đạt, điều kiện áp dụng và tiêu chí kiểm chứng khi cần thiết.

Thay vì viết “hệ thống phản hồi nhanh”, doanh nghiệp có thể quy định: trong điều kiện tải đã xác định, 95% yêu cầu thuộc một giao dịch cụ thể phải hoàn thành trong thời gian không vượt quá ngưỡng do nghiệp vụ chấp nhận. Con số cuối cùng phải được xác lập từ hành vi người dùng, khả năng vận hành và chi phí thực tế, không nên sao chép một benchmark không liên quan.

Tương tự, “khôi phục nhanh” có thể được tách thành RTO và RPO; “chịu tải cao” thành số phiên đồng thời hoặc giao dịch mỗi giây; “tích hợp được” thành hệ thống nguồn/đích, dữ liệu trao đổi, giao thức và điều kiện lỗi; “dễ sử dụng” thành tác vụ, nhóm người dùng và tiêu chí đánh giá tương ứng.

Việc định lượng không có nghĩa mọi yêu cầu đều phải chứa một con số. Một yêu cầu về quy tắc phân quyền chẳng hạn có thể được kiểm chứng bằng việc một vai trò không được phép thực hiện một hành động nhất định. Nguyên tắc quan trọng hơn là phải có phương pháp xác định PASS/FAIL hoặc bằng chứng đủ rõ để nghiệm thu.

Doanh nghiệp cũng nên duy trì khả năng truy vết: mỗi yêu cầu quan trọng phải liên hệ được với nhu cầu nghiệp vụ, nhóm người dùng, rủi ro hoặc ràng buộc đã tạo ra nó. Khi một yêu cầu không còn truy được về một nhu cầu thực, đó là tín hiệu cần kiểm tra xem nó có đang tồn tại chỉ do giả định kỹ thuật hay không.

Xác nhận và ưu tiên trước khi dùng yêu cầu để chọn công nghệ

Danh sách yêu cầu ban đầu gần như luôn có xung đột. Người dùng muốn hệ thống phản hồi tức thời; bộ phận an ninh muốn nhiều bước kiểm soát; vận hành muốn thay đổi tối thiểu; kinh doanh muốn ra mắt nhanh; tài chính muốn hạn chế chi phí. Xác định yêu cầu công nghệ vì thế không kết thúc ở việc thu thập càng nhiều yêu cầu càng tốt.

Doanh nghiệp cần xác nhận từng yêu cầu với stakeholder chịu trách nhiệm và ưu tiên theo tác động thực tế. Có thể phân biệt:

·         Yêu cầu bắt buộc để quy trình hoạt động hoặc đáp ứng nghĩa vụ phải tuân thủ

·         Yêu cầu quan trọng tạo tác động đáng kể tới kết quả nghiệp vụ

·         Yêu cầu có giá trị nhưng có thể trì hoãn

·         Mong muốn chưa đủ căn cứ để trở thành điều kiện bắt buộc

Khi hai yêu cầu xung đột, quyết định phải dựa vào trade-off. Mức sẵn sàng cao hơn có thể làm tăng chi phí hạ tầng; lưu giữ nhiều dữ liệu hơn có thể làm tăng chi phí và nghĩa vụ bảo vệ dữ liệu; kiểm soát truy cập chặt hơn có thể tăng số bước của người dùng. Không có một cấu hình “tốt nhất” độc lập với nhu cầu nghiệp vụ và mức rủi ro mà doanh nghiệp chấp nhận.

Trước khi yêu cầu được dùng cho RFP, đánh giá sản phẩm hoặc thiết kế hệ thống, doanh nghiệp có thể kiểm tra một ma trận đơn giản:

Khi ma trận này đủ rõ, doanh nghiệp mới có cơ sở so sánh các phương án công nghệ. Một sản phẩm có nhiều tính năng nhất chưa chắc đáp ứng tốt nhất; phương án phù hợp là phương án thỏa các yêu cầu quan trọng trong điều kiện vận hành thực tế với mức chi phí, rủi ro và trade-off mà tổ chức chấp nhận.

Xác định yêu cầu công nghệ thực chất là quá trình dịch chuyển từ “doanh nghiệp cần đạt điều gì” sang “hệ thống phải thể hiện những hành vi và thuộc tính nào để chứng minh điều đó”. Nhu cầu nghiệp vụ xác lập kết quả, người dùng cung cấp yêu cầu từ công việc thực tế, còn điều kiện vận hành đặt ra các giới hạn mà giải pháp phải chịu được.

Khi các đầu vào này được chuyển thành yêu cầu chức năng, yêu cầu chất lượng, ràng buộc và tiêu chí nghiệm thu có thể kiểm chứng, doanh nghiệp có thể đánh giá công nghệ dựa trên bằng chứng thay vì dựa vào danh sách tính năng hoặc tên nền tảng. Đây cũng là ranh giới quan trọng giữa xác định đúng yêu cầu công nghệ và chọn giải pháp quá sớm.