Cách xác định yêu cầu phần mềm doanh nghiệp

Một bộ yêu cầu tốt phải giúp doanh nghiệp thực hiện được ba việc: mô tả đúng nhu cầu, so sánh các giải pháp trên cùng một cơ sở và kiểm chứng được phần mềm sau khi triển khai. Nếu yêu cầu chỉ là danh sách tính năng chung chung, doanh nghiệp có thể chọn được sản phẩm nhiều chức năng nhưng vẫn không giải quyết đúng vấn đề vận hành.

Vì vậy, yêu cầu cần được xây dựng theo một chuỗi logic:

Vấn đề kinh doanh → Mục tiêu cần đạt → Quy trình liên quan → Người sử dụng → Năng lực phần mềm cần có → Điều kiện vận hành → Tiêu chí nghiệm thu

Hiểu đúng yêu cầu phần mềm doanh nghiệp

Yêu cầu phần mềm doanh nghiệp là tập hợp các điều kiện mà giải pháp phải đáp ứng để hỗ trợ mục tiêu kinh doanh, quy trình vận hành và nhu cầu của các bên liên quan.

Yêu cầu không chỉ bao gồm chức năng. Một hệ thống có đủ chức năng nhưng xử lý chậm, khó tích hợp, phân quyền không phù hợp hoặc không đáp ứng quy định bảo mật vẫn có thể không sử dụng được trong thực tế.

Do đó, doanh nghiệp cần xem xét ít nhất bốn lớp yêu cầu:

·         Yêu cầu kinh doanh mô tả kết quả doanh nghiệp muốn đạt được

·         Yêu cầu của bên liên quan mô tả nhu cầu của từng nhóm sử dụng hoặc quản lý

·         Yêu cầu chức năng mô tả hệ thống phải thực hiện được những nghiệp vụ nào

·         Yêu cầu phi chức năng mô tả hệ thống phải vận hành với chất lượng, mức độ an toàn và giới hạn nào

ISO/IEC/IEEE 29148:2018 xác định kỹ nghệ yêu cầu là một tập hợp quá trình được thực hiện xuyên suốt vòng đời của hệ thống và sản phẩm phần mềm, thay vì một hoạt động lập danh sách tính năng diễn ra riêng lẻ trước khi mua.

Phân biệt nhu cầu, giải pháp và tính năng

Ba khái niệm này thường bị trộn lẫn trong quá trình khảo sát:

·         Nhu cầu là điều doanh nghiệp cần đạt được

·         Giải pháp là cách tổ chức dự kiến xử lý nhu cầu

·         Tính năng là khả năng cụ thể mà phần mềm cung cấp

Ví dụ, “giảm thời gian phê duyệt đơn mua hàng” là nhu cầu. “Tự động hóa quy trình phê duyệt” là một hướng giải pháp. “Thiết lập luồng phê duyệt nhiều cấp theo giá trị đơn hàng” là tính năng.

Nếu doanh nghiệp bắt đầu ngay bằng tính năng, nhóm dự án có thể vô tình cố định một giải pháp trước khi hiểu đầy đủ vấn đề. Điều này làm giảm khả năng xem xét những phương án đơn giản hơn, phù hợp hơn hoặc ít tốn chi phí hơn.

Một yêu cầu tốt phải kiểm chứng được

Yêu cầu “phần mềm phải dễ sử dụng” không đủ rõ để đánh giá nhà cung cấp hoặc nghiệm thu. Mỗi bên có thể hiểu “dễ sử dụng” theo một cách khác nhau.

Yêu cầu nên được chuyển thành điều kiện quan sát hoặc đo lường được, chẳng hạn:

·         Nhân viên mới hoàn thành thao tác tạo đơn hàng sau tối đa hai giờ hướng dẫn

·         Người dùng thực hiện tác vụ thường xuyên trong không quá năm bước chính

·         Hệ thống hiển thị thông báo cụ thể khi thiếu dữ liệu bắt buộc

·         Giao diện hỗ trợ tiếng Việt và hiển thị tốt trên độ phân giải màn hình đang sử dụng

Con số cụ thể không nên được chọn tùy ý. Doanh nghiệp cần xác định chúng từ khối lượng công việc, mức độ rủi ro, năng lực người dùng và điều kiện vận hành thực tế.

Bắt đầu từ vấn đề và mục tiêu kinh doanh

Một dự án mua phần mềm dễ thất bại khi tổ chức xem việc “có phần mềm mới” là mục tiêu. Phần mềm chỉ là công cụ. Mục tiêu thực sự phải thể hiện sự thay đổi trong hoạt động kinh doanh.

Doanh nghiệp cần mô tả tình trạng hiện tại bằng các vấn đề cụ thể:

·         Dữ liệu đang bị nhập lặp ở nhiều bộ phận

·         Quy trình phê duyệt phụ thuộc vào email hoặc giấy tờ

·         Báo cáo được tổng hợp thủ công và thường chậm

·         Không truy vết được người đã thay đổi dữ liệu

·         Các chi nhánh sử dụng quy trình hoặc biểu mẫu khác nhau

·         Hệ thống hiện tại không kết nối được với các nền tảng cần thiết

·         Chi phí bảo trì hoặc xử lý lỗi đang tăng

Sau đó, mỗi vấn đề phải được liên kết với một mục tiêu có thể đánh giá.

Vấn đề hiện tại	Mục tiêu cần đạt	Chỉ số có thể theo dõi
Phê duyệt đơn hàng kéo dài	Rút ngắn chu kỳ phê duyệt	Thời gian trung bình từ lúc gửi đến lúc duyệt
Nhập dữ liệu lặp	Giảm thao tác thủ công	Số lần nhập lại cùng một trường dữ liệu
Báo cáo thiếu nhất quán	Chuẩn hóa dữ liệu quản trị	Tỷ lệ báo cáo sử dụng cùng nguồn dữ liệu
Khó truy vết thay đổi	Tăng khả năng kiểm soát	Tỷ lệ giao dịch có nhật ký đầy đủ
Tồn kho thiếu chính xác	Cải thiện độ tin cậy của số liệu	Chênh lệch giữa hệ thống và kiểm kê

Mục tiêu không nhất thiết phải là một con số duy nhất. Tuy nhiên, nó phải đủ rõ để doanh nghiệp xác định sau triển khai rằng tình trạng đã được cải thiện hay chưa.

Xác định nguyên nhân trước khi yêu cầu tự động hóa

Một quy trình chậm không luôn đồng nghĩa với việc thiếu phần mềm. Nguyên nhân có thể là:

·         Có quá nhiều cấp phê duyệt

·         Trách nhiệm giữa các bộ phận chưa rõ

·         Dữ liệu đầu vào thường xuyên thiếu

·         Chính sách xử lý có nhiều ngoại lệ

·         Nhân sự không được trao đủ quyền

·         Biểu mẫu thu thập những thông tin không cần thiết

Nếu nguyên nhân nằm ở chính sách hoặc cách tổ chức công việc, phần mềm chỉ có thể số hóa sự phức tạp hiện có. Trước khi xác lập yêu cầu, doanh nghiệp cần phân biệt phần nào nên được loại bỏ, phần nào nên được chuẩn hóa và phần nào thực sự cần tự động hóa.

Xác định phạm vi nghiệp vụ trước khi chọn tính năng

Phạm vi cho biết phần mềm sẽ hỗ trợ những hoạt động nào, nhóm người dùng nào, đơn vị nào và giai đoạn nào. Không xác định phạm vi khiến danh sách yêu cầu mở rộng liên tục và các nhà cung cấp báo giá trên những giả định khác nhau.

Một tuyên bố phạm vi nên làm rõ:

·         Quy trình nằm trong phạm vi

·         Quy trình nằm ngoài phạm vi

·         Phòng ban và đơn vị áp dụng

·         Nhóm người dùng liên quan

·         Địa điểm hoặc chi nhánh triển khai

·         Hệ thống cần thay thế

·         Hệ thống vẫn tiếp tục sử dụng

·         Giai đoạn triển khai dự kiến

·         Những phụ thuộc quan trọng

Ví dụ, thay vì ghi “triển khai phần mềm quản lý nhân sự”, phạm vi có thể được xác định là:

“Giai đoạn đầu áp dụng cho hồ sơ nhân sự, chấm công, nghỉ phép và tính lương tại trụ sở cùng ba chi nhánh; chưa bao gồm tuyển dụng, đánh giá năng lực và quản lý đào tạo.”

Cách mô tả này giúp doanh nghiệp kiểm soát kỳ vọng và giúp nhà cung cấp xác định chính xác khối lượng cấu hình, chuyển đổi dữ liệu, tích hợp và đào tạo.

Mô tả quy trình hiện tại và quy trình mong muốn

Doanh nghiệp nên lập hai mô hình:

·         Quy trình hiện tại phản ánh cách công việc đang thực sự diễn ra

·         Quy trình mong muốn phản ánh cách công việc cần vận hành sau khi cải tiến

Không nên chỉ dựa vào quy trình chính thức trên văn bản. Cách làm thực tế có thể chứa các bước thủ công, bảng tính, trao đổi qua ứng dụng nhắn tin hoặc những ngoại lệ chưa được ghi nhận.

Với mỗi quy trình, cần xác định:

·         Sự kiện bắt đầu

·         Dữ liệu đầu vào

·         Các bước xử lý

·         Người thực hiện

·         Quy tắc ra quyết định

·         Điểm phê duyệt

·         Trường hợp ngoại lệ

·         Dữ liệu đầu ra

·         Sự kiện kết thúc

·         Hệ thống có liên quan

Khi hiểu được luồng nghiệp vụ, doanh nghiệp mới có thể xác định phần mềm phải hỗ trợ thao tác nào, kiểm soát điều kiện gì và trao đổi dữ liệu với đâu.

Xác định đầy đủ các bên liên quan

Yêu cầu phần mềm không nên do một phòng ban hoặc một cấp quản lý tự xây dựng. Mỗi nhóm nhìn hệ thống từ một góc độ khác nhau.

Các bên liên quan thường bao gồm:

·         Người trực tiếp sử dụng phần mềm

·         Quản lý bộ phận

·         Chủ sở hữu quy trình

·         Ban lãnh đạo

·         Bộ phận công nghệ thông tin

·         Bộ phận an toàn thông tin

·         Tài chính và kế toán

·         Pháp chế hoặc tuân thủ

·         Nhóm quản trị dữ liệu

·         Khách hàng, đối tác hoặc nhà cung cấp có tương tác với hệ thống

Người dùng trực tiếp thường hiểu các bước công việc và ngoại lệ. Quản lý quan tâm đến kiểm soát và báo cáo. Bộ phận công nghệ thông tin đánh giá tích hợp, kiến trúc và khả năng vận hành. Bộ phận an toàn thông tin xem xét quyền truy cập, dữ liệu nhạy cảm và rủi ro nhà cung cấp.

Nếu thiếu một nhóm quan trọng, yêu cầu có thể đúng với một bộ phận nhưng xung đột với hoạt động chung của doanh nghiệp.

Phân công trách nhiệm ra quyết định

Doanh nghiệp cần xác định rõ:

·         Ai cung cấp thông tin

·         Ai xác nhận yêu cầu

·         Ai quyết định mức độ ưu tiên

·         Ai phê duyệt thay đổi

·         Ai chấp nhận kết quả nghiệm thu

·         Ai chịu trách nhiệm về ngân sách

·         Ai sở hữu dữ liệu và quy trình

Tham vấn rộng không có nghĩa mọi người đều có quyền phủ quyết. Nếu cơ chế quyết định không rõ, những khác biệt giữa các bộ phận sẽ kéo dài và yêu cầu khó được chốt.

Khai thác và xác nhận yêu cầu

Phỏng vấn là một phương pháp phổ biến nhưng không nên là nguồn duy nhất. IIBA mô tả hoạt động khai thác yêu cầu là quá trình tìm ra, khám phá và nhận diện thông tin liên quan đến sự thay đổi; kết quả sau khai thác còn cần được xác nhận với các bên liên quan.

Doanh nghiệp có thể kết hợp:

·         Phỏng vấn cá nhân

·         Hội thảo liên phòng ban

·         Quan sát công việc thực tế

·         Phân tích biểu mẫu và tài liệu

·         Xem xét dữ liệu giao dịch

·         Khảo sát nhóm người dùng lớn

·         Mô phỏng quy trình

·         Dùng bản mẫu giao diện

·         Thử nghiệm tình huống nghiệp vụ

Bản mẫu đặc biệt hữu ích khi người dùng khó mô tả nhu cầu bằng văn bản. Tuy nhiên, bản mẫu giao diện không thể thay thế yêu cầu về quy tắc nghiệp vụ, dữ liệu, bảo mật và hiệu năng.

Chuyển nhu cầu thành yêu cầu chức năng

Yêu cầu chức năng mô tả những hành vi hoặc năng lực mà phần mềm phải cung cấp. Chúng nên được viết theo ngôn ngữ nghiệp vụ trước khi chuyển sang ngôn ngữ kỹ thuật.

Một yêu cầu chức năng nên trả lời:

·         Ai thực hiện

·         Thực hiện hành động gì

·         Trên dữ liệu nào

·         Trong điều kiện nào

·         Hệ thống phản hồi ra sao

·         Kết quả cần tạo là gì

·         Ngoại lệ được xử lý như thế nào

Ví dụ chưa rõ:

“Phần mềm có chức năng phê duyệt đơn hàng.”

Ví dụ rõ hơn:

“Khi tổng giá trị đơn mua hàng vượt hạn mức của trưởng bộ phận, hệ thống phải chuyển yêu cầu đến giám đốc khối. Người phê duyệt có thể chấp thuận, từ chối hoặc trả lại để bổ sung thông tin. Mỗi hành động phải ghi nhận người thực hiện, thời gian và lý do.”

Phiên bản thứ hai giúp nhà cung cấp hiểu được luồng xử lý, điều kiện, quyền hạn và dữ liệu cần lưu.

Xây dựng yêu cầu theo tình huống sử dụng

Doanh nghiệp có thể viết tình huống sử dụng theo cấu trúc:

1.    Người dùng hoặc vai trò thực hiện

2.    Mục tiêu của người dùng

3.    Điều kiện trước khi bắt đầu

4.    Luồng xử lý chính

5.    Luồng thay thế hoặc ngoại lệ

6.    Kết quả sau khi hoàn tất

7.    Tiêu chí chấp nhận

Ví dụ:

Tình huống: Nhân viên gửi đề nghị thanh toán

Điều kiện: Nhân viên đã đăng nhập và có quyền tạo đề nghị

Luồng chính:

1.    Nhân viên chọn loại chi phí

2.    Nhân viên nhập số tiền và thông tin hóa đơn

3.    Hệ thống kiểm tra trường bắt buộc

4.    Hệ thống xác định luồng phê duyệt theo đơn vị và giá trị

5.    Người phê duyệt nhận thông báo

6.    Quyết định được ghi vào nhật ký

Ngoại lệ:

·         Hóa đơn trùng số

·         Thiếu chứng từ

·         Số tiền vượt ngân sách

·         Người phê duyệt vắng mặt

·         Đề nghị bị trả lại hoặc hủy

Việc mô tả cả ngoại lệ giúp tránh tình trạng phần mềm chỉ chạy được trong trường hợp lý tưởng.

Làm rõ quy tắc nghiệp vụ

Quy tắc nghiệp vụ quyết định cách phần mềm xử lý dữ liệu và lựa chọn hành động. Chúng có thể liên quan đến:

·         Hạn mức phê duyệt

·         Điều kiện tính giá

·         Thời hạn thanh toán

·         Cách phân loại khách hàng

·         Quy tắc cấp tín dụng

·         Công thức tính lương

·         Điều kiện cảnh báo

·         Trình tự xử lý

·         Chính sách lưu trữ

·         Điều kiện khóa hoặc mở dữ liệu

Mỗi quy tắc nên có chủ sở hữu và nguồn xác nhận. Nếu một chính sách chưa thống nhất, phần mềm không thể tự giải quyết sự bất đồng đó.

Không bỏ qua yêu cầu phi chức năng

Yêu cầu phi chức năng xác định chất lượng vận hành của phần mềm. Đây thường là nhóm yêu cầu bị xem nhẹ khi doanh nghiệp tập trung quá nhiều vào bản trình diễn tính năng.

Hiệu năng và khả năng mở rộng

Doanh nghiệp cần cung cấp các thông tin như:

·         Số người dùng được cấp tài khoản

·         Số người dùng đồng thời dự kiến

·         Số giao dịch trong giờ cao điểm

·         Khối lượng dữ liệu hiện tại

·         Tốc độ tăng dữ liệu

·         Thời gian phản hồi chấp nhận được

·         Thời gian hoàn thành báo cáo lớn

·         Khả năng mở rộng theo chi nhánh hoặc đơn vị

Thay vì yêu cầu “hệ thống phải nhanh”, có thể viết:

“Trong điều kiện tải dự kiến 300 người dùng đồng thời, 95% thao tác tra cứu thông thường phải phản hồi trong không quá ba giây.”

Ngưỡng này chỉ là một ví dụ về cách viết có thể kiểm thử. Doanh nghiệp phải xác lập giá trị phù hợp từ môi trường thực tế và mức độ quan trọng của từng tác vụ.

Tính sẵn sàng và khôi phục

Cần làm rõ:

·         Khung giờ hệ thống phải hoạt động

·         Khoảng thời gian bảo trì chấp nhận được

·         Mức gián đoạn tối đa có thể chịu

·         Lượng dữ liệu tối đa có thể mất khi xảy ra sự cố

·         Thời gian cần để khôi phục hoạt động

·         Cách sao lưu và kiểm tra bản sao lưu

·         Cơ chế dự phòng

·         Trách nhiệm xử lý sự cố

Hai khái niệm thường được sử dụng là:

·         RTO thể hiện thời gian mục tiêu để khôi phục dịch vụ

·         RPO thể hiện khoảng dữ liệu tối đa có thể bị mất tính theo thời gian

Doanh nghiệp không nên yêu cầu RTO hoặc RPO thấp nhất cho mọi hệ thống, vì mức cam kết càng cao thường kéo theo kiến trúc và chi phí vận hành lớn hơn.

Khả năng sử dụng và khả năng tiếp cận

Các tiêu chí có thể bao gồm:

·         Ngôn ngữ giao diện

·         Thiết bị và kích thước màn hình hỗ trợ

·         Số bước cho tác vụ thường xuyên

·         Khả năng tìm kiếm

·         Cách hiển thị lỗi

·         Hỗ trợ người dùng khuyết tật

·         Mức đào tạo cần thiết

·         Tính nhất quán của thuật ngữ và điều hướng

Cần đánh giá khả năng sử dụng bằng những tác vụ thực tế thay vì chỉ quan sát giao diện trong buổi trình diễn.

Khả năng cấu hình và bảo trì

Doanh nghiệp cần phân biệt:

·         Cấu hình bằng công cụ có sẵn

·         Tùy chỉnh bằng mã nguồn hoặc tiện ích riêng

·         Tích hợp với hệ thống bên ngoài

·         Thay đổi do nhà cung cấp thực hiện

·         Thay đổi mà quản trị viên nội bộ có thể tự thực hiện

Một tính năng có thể đáp ứng yêu cầu ở thời điểm mua nhưng phát sinh chi phí lớn nếu mỗi thay đổi nhỏ đều cần lập trình riêng. Vì vậy, cần hỏi rõ phạm vi cấu hình, giới hạn tùy chỉnh và ảnh hưởng của tùy chỉnh đến việc nâng cấp.

Xác định yêu cầu dữ liệu

Dữ liệu là một phần của giải pháp, không phải công việc phụ chỉ xử lý khi triển khai.

Doanh nghiệp cần xác định:

·         Những đối tượng dữ liệu chính

·         Trường dữ liệu bắt buộc

·         Nguồn tạo dữ liệu

·         Chủ sở hữu dữ liệu

·         Quy tắc kiểm tra tính hợp lệ

·         Dữ liệu nhạy cảm

·         Thời gian lưu trữ

·         Quyền xem và chỉnh sửa

·         Nhu cầu truy vết thay đổi

·         Yêu cầu tìm kiếm và báo cáo

·         Dữ liệu cần chuyển từ hệ thống cũ

Đánh giá chất lượng dữ liệu trước khi chuyển đổi

Phần mềm mới không tự động làm sạch dữ liệu cũ. Trước khi lập yêu cầu chuyển đổi, doanh nghiệp cần kiểm tra:

·         Bản ghi trùng lặp

·         Dữ liệu thiếu

·         Định dạng không nhất quán

·         Mã danh mục không còn sử dụng

·         Mối quan hệ dữ liệu bị lỗi

·         Dữ liệu không có chủ sở hữu

·         Trường thông tin không còn giá trị

Phạm vi chuyển đổi nên xác định rõ dữ liệu nào cần mang sang, dữ liệu nào chỉ lưu trữ để tra cứu và dữ liệu nào có thể loại bỏ theo chính sách được phê duyệt.

Làm rõ báo cáo và phân tích

Yêu cầu “có báo cáo đầy đủ” không đủ để đánh giá phần mềm. Với mỗi báo cáo quan trọng, cần xác định:

·         Người sử dụng

·         Mục đích ra quyết định

·         Nguồn dữ liệu

·         Chỉ số và công thức

·         Chiều phân tích

·         Tần suất cập nhật

·         Bộ lọc cần thiết

·         Định dạng xuất

·         Quyền truy cập

·         Mức độ chi tiết

Doanh nghiệp cũng cần phân biệt báo cáo vận hành tức thời với báo cáo phân tích quản trị. Hai loại này có thể đòi hỏi kiến trúc dữ liệu và tốc độ cập nhật khác nhau.

Xác định yêu cầu tích hợp

Phần mềm doanh nghiệp hiếm khi hoạt động độc lập. Yêu cầu tích hợp phải mô tả luồng dữ liệu, không chỉ liệt kê tên hệ thống.

Với mỗi điểm tích hợp, cần xác định:

·         Hệ thống nguồn

·         Hệ thống đích

·         Loại dữ liệu trao đổi

·         Chiều truyền dữ liệu

·         Tần suất đồng bộ

·         Khối lượng dữ liệu

·         Thời gian trễ chấp nhận được

·         Phương thức kết nối

·         Cơ chế xác thực

·         Cách xử lý lỗi

·         Cách đối soát

·         Đơn vị chịu trách nhiệm

Ví dụ, yêu cầu “tích hợp với phần mềm kế toán” cần được làm rõ thành các luồng như:

·         Đồng bộ danh mục khách hàng

·         Chuyển chứng từ bán hàng đã duyệt

·         Nhận trạng thái hạch toán

·         Đối chiếu công nợ

·         Ghi nhận lỗi và cho phép gửi lại

Kiểm tra khả năng tích hợp thực tế

Một nhà cung cấp tuyên bố có API không đồng nghĩa mọi nghiệp vụ đều tích hợp được. Doanh nghiệp cần yêu cầu làm rõ:

·         API hỗ trợ đối tượng dữ liệu nào

·         Có giới hạn số lượng yêu cầu hay không

·         Có hỗ trợ cập nhật hai chiều hay không

·         Dữ liệu có được cung cấp theo thời gian thực hay không

·         API có thuộc gói dịch vụ đang báo giá hay không

·         Phiên bản API được duy trì trong bao lâu

·         Có môi trường thử nghiệm hay không

·         Ai chịu trách nhiệm khi giao diện tích hợp thay đổi

Đối với tích hợp quan trọng, nên kiểm chứng bằng tài liệu kỹ thuật hoặc một thử nghiệm nhỏ thay vì chỉ dựa vào bản trình bày bán hàng.

Xác định yêu cầu bảo mật và tuân thủ

Bảo mật phải được chuyển thành các kiểm soát cụ thể phù hợp với loại dữ liệu, người dùng và mức độ rủi ro.

Các nhóm yêu cầu thường gồm:

Quản lý danh tính và truy cập

·         Đăng nhập một lần

·         Xác thực đa yếu tố

·         Chính sách mật khẩu

·         Phân quyền theo vai trò

·         Phân tách nhiệm vụ

·         Thu hồi quyền khi nhân viên nghỉ việc

·         Kiểm tra quyền định kỳ

·         Quyền truy cập đặc biệt của quản trị viên

Bảo vệ dữ liệu

·         Mã hóa khi truyền

·         Mã hóa khi lưu trữ

·         Phân loại dữ liệu

·         Che giấu dữ liệu nhạy cảm

·         Hạn chế tải xuống

·         Chính sách lưu trữ và xóa dữ liệu

·         Vị trí lưu trữ

·         Sao lưu và khôi phục

Theo dõi và kiểm toán

·         Ghi nhật ký đăng nhập

·         Ghi nhận thay đổi dữ liệu

·         Ghi nhận hoạt động quản trị

·         Bảo vệ nhật ký khỏi chỉnh sửa

·         Tìm kiếm và xuất nhật ký

·         Cảnh báo hành vi bất thường

·         Thời gian lưu nhật ký

Quản lý rủi ro nhà cung cấp

·         Quy trình xử lý lỗ hổng

·         Thời gian thông báo sự cố

·         Kiểm soát nhà thầu phụ

·         Cơ chế cập nhật bảo mật

·         Kế hoạch duy trì dịch vụ

·         Quyền lấy lại dữ liệu

·         Cách xử lý dữ liệu khi chấm dứt hợp đồng

Không phải mọi phần mềm đều cần cùng mức kiểm soát. Hệ thống xử lý dữ liệu tài chính, thông tin nhân sự hoặc dữ liệu nhạy cảm cần yêu cầu nghiêm ngặt hơn một công cụ nội bộ có rủi ro thấp.

Xác định điều kiện triển khai và vận hành

Một giải pháp phù hợp về chức năng vẫn có thể không phù hợp với môi trường của doanh nghiệp.

Cần xác định:

·         Mô hình triển khai tại chỗ, đám mây hoặc kết hợp

·         Hệ điều hành và trình duyệt cần hỗ trợ

·         Thiết bị đầu cuối

·         Hạ tầng mạng

·         Môi trường kiểm thử

·         Cơ chế quản trị cấu hình

·         Tần suất cập nhật phiên bản

·         Quy trình tiếp nhận thay đổi

·         Công cụ giám sát

·         Đầu mối hỗ trợ

·         Năng lực đội ngũ nội bộ

Xác định trách nhiệm giữa doanh nghiệp và nhà cung cấp

Các hoạt động cần phân công rõ gồm:

·         Chuẩn bị hạ tầng

·         Cấu hình phần mềm

·         Làm sạch dữ liệu

·         Chuyển đổi dữ liệu

·         Phát triển tích hợp

·         Kiểm thử

·         Đào tạo

·         Hỗ trợ sau vận hành

·         Sao lưu

·         Giám sát

·         Xử lý sự cố

·         Nâng cấp

Nếu trách nhiệm không rõ, mỗi bên có thể mặc định công việc thuộc về bên còn lại. Đây là nguồn phổ biến của chi phí phát sinh và chậm tiến độ.

Ưu tiên yêu cầu thay vì coi mọi yêu cầu như nhau

Không phải yêu cầu nào cũng có cùng giá trị kinh doanh. Danh sách không được ưu tiên sẽ khiến doanh nghiệp khó lựa chọn khi ngân sách, thời gian hoặc khả năng của sản phẩm có giới hạn.

Có thể phân loại theo bốn mức:

·         Bắt buộc phải có

·         Nên có

·         Có thể có

·         Chưa thực hiện trong giai đoạn này

Một yêu cầu chỉ nên được xếp vào nhóm bắt buộc khi thiếu nó sẽ dẫn đến ít nhất một hậu quả rõ ràng:

·         Không thể vận hành quy trình cốt lõi

·         Vi phạm yêu cầu pháp lý hoặc kiểm soát bắt buộc

·         Tạo ra rủi ro không thể chấp nhận

·         Không đạt mục tiêu kinh doanh chính

·         Không thể kết nối với hệ thống thiết yếu

·         Không thể nghiệm thu hoặc đưa vào sử dụng

Việc một người dùng mong muốn tính năng nào đó chưa đủ để biến nó thành yêu cầu bắt buộc.

Đánh giá giá trị, rủi ro và chi phí

Mỗi yêu cầu quan trọng nên được xem xét trên ba chiều:

·         Giá trị mà yêu cầu tạo ra

·         Rủi ro nếu không đáp ứng

·         Chi phí hoặc độ phức tạp để thực hiện

Một yêu cầu có giá trị thấp nhưng chi phí tùy chỉnh cao nên được xem xét loại bỏ hoặc thay đổi quy trình. Ngược lại, một kiểm soát ít được sử dụng nhưng ngăn ngừa rủi ro nghiêm trọng vẫn có thể là yêu cầu bắt buộc.

Quản lý xung đột yêu cầu

Các bộ phận có thể đưa ra yêu cầu trái ngược:

·         Người dùng muốn thao tác nhanh, bộ phận kiểm soát muốn thêm bước phê duyệt

·         Kinh doanh muốn dữ liệu mở, an toàn thông tin muốn giới hạn truy cập

·         Từng chi nhánh muốn quy trình riêng, ban lãnh đạo muốn chuẩn hóa

·         Bộ phận nghiệp vụ muốn tùy chỉnh sâu, công nghệ thông tin muốn dễ nâng cấp

Không nên giải quyết xung đột bằng cách ghi nhận cả hai yêu cầu. Nhóm dự án cần đưa ra quyết định dựa trên mục tiêu, rủi ro, chính sách và tổng chi phí sở hữu.

Viết tiêu chí chấp nhận cho yêu cầu quan trọng

Tiêu chí chấp nhận mô tả điều kiện để doanh nghiệp xác nhận một yêu cầu đã được đáp ứng. Đây là cầu nối giữa khảo sát nhu cầu, đánh giá giải pháp và nghiệm thu.

Một tiêu chí tốt cần:

·         Quan sát hoặc kiểm thử được

·         Có điều kiện thực hiện rõ ràng

·         Có kết quả mong đợi

·         Không phụ thuộc vào nhận xét cảm tính

·         Phản ánh đúng tình huống nghiệp vụ

·         Bao gồm trường hợp lỗi hoặc ngoại lệ khi cần

Ví dụ:

Yêu cầu: Hệ thống kiểm soát hóa đơn trùng

Tiêu chí chấp nhận:

·         Khi người dùng nhập cùng mã số thuế, số hóa đơn và ngày hóa đơn đã tồn tại, hệ thống phải cảnh báo trước khi lưu

·         Cảnh báo phải hiển thị bản ghi có khả năng trùng

·         Chỉ người có quyền ngoại lệ mới được tiếp tục

·         Trường hợp tiếp tục phải lưu người phê duyệt và lý do

Tiêu chí này giúp doanh nghiệp đánh giá sản phẩm trong buổi trình diễn và sử dụng lại khi kiểm thử nghiệm thu.

Xây dựng kịch bản trình diễn theo yêu cầu

Doanh nghiệp không nên để nhà cung cấp chỉ trình diễn những tính năng thuận lợi nhất. Cần chuẩn bị một bộ kịch bản chung và yêu cầu các nhà cung cấp thực hiện trên cùng dữ liệu mẫu.

Mỗi kịch bản nên bao gồm:

·         Bối cảnh nghiệp vụ

·         Vai trò tham gia

·         Dữ liệu đầu vào

·         Quy tắc cần xử lý

·         Kết quả mong đợi

·         Trường hợp ngoại lệ

·         Tiêu chí đánh giá

Cách làm này giúp phân biệt ba trạng thái:

·         Phần mềm đáp ứng sẵn

·         Phần mềm đáp ứng bằng cấu hình

·         Phần mềm cần tùy chỉnh hoặc phát triển thêm

Ba trạng thái có ảnh hưởng rất khác nhau đến chi phí, thời gian, rủi ro nâng cấp và sự phụ thuộc vào nhà cung cấp.

Chuẩn hóa tài liệu yêu cầu để đánh giá nhà cung cấp

Bộ yêu cầu không nhất thiết phải là một tài liệu dài. Nó có thể gồm nhiều thành phần được liên kết với nhau:

·         Mục tiêu và phạm vi

·         Danh sách bên liên quan

·         Sơ đồ quy trình

·         Danh mục yêu cầu

·         Quy tắc nghiệp vụ

·         Mô hình dữ liệu

·         Danh sách tích hợp

·         Yêu cầu phi chức năng

·         Tiêu chí chấp nhận

·         Kịch bản trình diễn

·         Ma trận đánh giá

·         Danh sách giả định và ràng buộc

Mỗi yêu cầu nên có mã nhận diện để truy vết trong quá trình đánh giá và triển khai.

Trường thông tin	Nội dung cần ghi
Mã yêu cầu	Mã duy nhất
Mô tả	Điều hệ thống phải đáp ứng
Lý do	Mục tiêu hoặc rủi ro liên quan
Nguồn	Người hoặc tài liệu xác nhận
Mức ưu tiên	Bắt buộc, nên có, có thể có
Tiêu chí chấp nhận	Cách kiểm chứng
Phụ thuộc	Quy trình, dữ liệu hoặc hệ thống liên quan
Trạng thái nhà cung cấp	Có sẵn, cấu hình, tùy chỉnh, không đáp ứng
Ghi chú	Giả định, giới hạn hoặc điều kiện

Tránh dùng danh sách yêu cầu dạng Có hoặc Không

Cột “Có/Không” không phản ánh mức độ đáp ứng thực tế. Nhà cung cấp có thể chọn “Có” dù tính năng:

·         Chỉ tồn tại trong phiên bản cao hơn

·         Cần mua thêm mô-đun

·         Chỉ đáp ứng một phần

·         Cần tùy chỉnh

·         Phụ thuộc vào sản phẩm của bên thứ ba

·         Chưa có nhưng nằm trong lộ trình

·         Không hoạt động trong môi trường của doanh nghiệp

Nên yêu cầu nhà cung cấp phân loại và giải thích:

·         Đáp ứng tiêu chuẩn

·         Đáp ứng bằng cấu hình

·         Đáp ứng bằng tùy chỉnh

·         Đáp ứng qua đối tác hoặc sản phẩm khác

·         Đáp ứng một phần

·         Không đáp ứng

·         Có trong lộ trình nhưng chưa phát hành

Mỗi câu trả lời quan trọng cần kèm điều kiện, chi phí, thời gian và bằng chứng kiểm chứng.

Xác định ràng buộc ngân sách và tổng chi phí sở hữu

Yêu cầu phải phản ánh khả năng đầu tư thực tế. Một danh sách yêu cầu không có giới hạn ngân sách dễ dẫn đến phương án vượt quá khả năng triển khai.

Tổng chi phí không chỉ là phí bản quyền. Doanh nghiệp cần xem xét:

·         Phí thuê bao hoặc giấy phép

·         Phí triển khai

·         Phí cấu hình

·         Phí tùy chỉnh

·         Phí tích hợp

·         Phí chuyển đổi dữ liệu

·         Chi phí hạ tầng

·         Chi phí kiểm thử

·         Chi phí đào tạo

·         Phí hỗ trợ

·         Phí nâng cấp

·         Chi phí nhân sự nội bộ

·         Chi phí thay đổi quy trình

·         Chi phí chấm dứt và chuyển dữ liệu

·         Chi phí phát sinh khi số người dùng hoặc dữ liệu tăng

Một giải pháp có giá mua thấp có thể tạo tổng chi phí cao nếu cần nhiều tùy chỉnh, khó nâng cấp hoặc buộc doanh nghiệp phụ thuộc vào dịch vụ của nhà cung cấp.

Gắn yêu cầu với phương án mua sắm

Các yêu cầu cần đủ rõ để phân biệt:

·         Sử dụng sản phẩm tiêu chuẩn

·         Cấu hình sản phẩm

·         Mua thêm mô-đun

·         Tích hợp công cụ khác

·         Tùy chỉnh

·         Phát triển riêng

·         Thay đổi quy trình để phù hợp sản phẩm

Không phải khoảng cách nào giữa nhu cầu và sản phẩm cũng nên được giải quyết bằng tùy chỉnh. Doanh nghiệp cần cân nhắc giá trị của yêu cầu so với chi phí duy trì giải pháp trong nhiều năm.

Kiểm tra bộ yêu cầu trước khi gửi nhà cung cấp

Trước khi sử dụng danh sách yêu cầu để tìm và đánh giá phần mềm, doanh nghiệp nên thực hiện một vòng kiểm tra chất lượng.

Kiểm tra tính đầy đủ

Bộ yêu cầu đã bao phủ:

·         Mục tiêu kinh doanh

·         Phạm vi

·         Quy trình chính

·         Trường hợp ngoại lệ

·         Người dùng

·         Dữ liệu

·         Tích hợp

·         Bảo mật

·         Hiệu năng

·         Vận hành

·         Hỗ trợ

·         Chuyển đổi dữ liệu

·         Tiêu chí chấp nhận

·         Ràng buộc ngân sách và thời gian

Kiểm tra tính rõ ràng

Mỗi yêu cầu phải tránh:

·         Từ ngữ mơ hồ

·         Nhiều cách diễn giải

·         Gộp nhiều yêu cầu trong một câu

·         Thuật ngữ không được định nghĩa

·         Giải pháp kỹ thuật không có lý do

·         Mô tả cảm tính

·         Điều kiện bị bỏ ngỏ

Kiểm tra tính nhất quán

Cần tìm các xung đột như:

·         Hai quy tắc cho cùng một trường hợp

·         Quyền truy cập mâu thuẫn

·         Chỉ số được tính theo nhiều công thức

·         Yêu cầu thời gian thực nhưng hệ thống nguồn chỉ cập nhật theo lô

·         Chính sách lưu dữ liệu trái với yêu cầu xóa

·         Phạm vi triển khai không khớp ngân sách hoặc thời gian

Kiểm tra khả năng kiểm thử

Với từng yêu cầu bắt buộc, cần trả lời được:

·         Sẽ kiểm tra bằng cách nào

·         Cần dữ liệu gì

·         Kết quả mong đợi là gì

·         Ai có quyền xác nhận

·         Điều kiện nào được xem là không đạt

Nếu không thể mô tả cách kiểm thử, yêu cầu có thể chưa đủ rõ để dùng làm cơ sở mua sắm và nghiệm thu.

Quy trình xác định yêu cầu phần mềm theo từng bước

Doanh nghiệp có thể thực hiện theo mười bước sau:

1.    Xác định vấn đề kinh doanh cần giải quyết

2.    Thiết lập mục tiêu và chỉ số kết quả

3.    Xác định phạm vi và các ràng buộc

4.    Nhận diện bên liên quan và quyền quyết định

5.    Khảo sát quy trình, dữ liệu và hệ thống hiện tại

6.    Thiết kế quy trình mong muốn

7.    Xây dựng yêu cầu chức năng và phi chức năng

8.    Viết tiêu chí chấp nhận và kịch bản kiểm thử

9.    Ưu tiên yêu cầu theo giá trị, rủi ro và chi phí

10.  Xác nhận, phê duyệt và quản lý thay đổi

Các bước có thể lặp lại. Khi xuất hiện thông tin mới, doanh nghiệp có thể điều chỉnh yêu cầu nhưng phải ghi nhận lý do, tác động và người phê duyệt.

Đầu ra tối thiểu trước khi tìm phần mềm

Trước khi mời nhà cung cấp, doanh nghiệp nên có ít nhất:

·         Một mô tả ngắn về vấn đề và mục tiêu

·         Phạm vi triển khai

·         Danh sách quy trình cốt lõi

·         Nhóm người dùng và số lượng dự kiến

·         Danh sách yêu cầu bắt buộc

·         Yêu cầu dữ liệu và tích hợp chính

·         Yêu cầu bảo mật quan trọng

·         Tiêu chí chấp nhận

·         Bộ kịch bản trình diễn

·         Ngân sách và thời gian mục tiêu

·         Người có quyền quyết định

Không nhất thiết mọi chi tiết phải hoàn hảo ngay từ đầu. Tuy nhiên, các yếu tố ảnh hưởng trực tiếp đến việc lựa chọn sản phẩm, chi phí và rủi ro phải được làm rõ trước khi nhận báo giá.

Những sai lầm thường gặp khi xác định yêu cầu

Sao chép danh sách tính năng từ nhà cung cấp

Danh sách của nhà cung cấp phản ánh cấu trúc sản phẩm, không nhất thiết phản ánh vấn đề của doanh nghiệp. Cách làm này dễ khiến tổ chức ưu tiên những tính năng dễ trình diễn hơn những năng lực thực sự quan trọng.

Chỉ hỏi cấp quản lý

Quản lý hiểu mục tiêu và kiểm soát nhưng có thể không nắm hết thao tác, dữ liệu thiếu, trường hợp ngoại lệ và cách người dùng xử lý công việc hằng ngày.

Mô tả giải pháp thay vì nhu cầu

Yêu cầu như “phải có nút xuất Excel ở góc phải” đã cố định thiết kế. Nhu cầu thực tế có thể là người dùng cần tải dữ liệu theo quyền được cấp để phân tích ngoại tuyến.

Đánh dấu quá nhiều yêu cầu là bắt buộc

Khi gần như mọi yêu cầu đều là bắt buộc, việc ưu tiên mất ý nghĩa. Doanh nghiệp khó thương lượng phạm vi và có xu hướng chọn sản phẩm tuyên bố đáp ứng nhiều nhất thay vì sản phẩm phù hợp nhất.

Bỏ qua ngoại lệ

Quy trình chính thường dễ đáp ứng. Khác biệt giữa các giải pháp lại xuất hiện ở cách xử lý dữ liệu sai, giao dịch bị từ chối, người phê duyệt vắng mặt, kết nối gián đoạn hoặc chính sách đặc biệt.

Không gắn yêu cầu với tiêu chí nghiệm thu

Nhà cung cấp và doanh nghiệp có thể cùng đồng ý với một câu mô tả nhưng hiểu khác nhau. Khi không có tiêu chí chấp nhận, sự khác biệt chỉ bộc lộ ở giai đoạn kiểm thử hoặc đưa vào sử dụng.

Thu thập yêu cầu một lần rồi khóa cứng

Yêu cầu cần được quản lý thay đổi. Tuy nhiên, quản lý thay đổi không có nghĩa tùy ý bổ sung. Mỗi thay đổi phải được đánh giá về giá trị, chi phí, thời gian, rủi ro và tác động đến các yêu cầu khác.

Cách biết bộ yêu cầu đã đủ tốt để mua phần mềm

Bộ yêu cầu có thể được xem là sẵn sàng khi doanh nghiệp trả lời được các câu hỏi sau:

·         Vấn đề nào đang được giải quyết

·         Kết quả nào phải thay đổi

·         Quy trình và đơn vị nào nằm trong phạm vi

·         Ai sẽ sử dụng và ai có quyền quyết định

·         Những năng lực nào là bắt buộc

·         Dữ liệu nào phải quản lý hoặc chuyển đổi

·         Hệ thống nào phải tích hợp

·         Mức bảo mật, hiệu năng và sẵn sàng cần đạt

·         Yêu cầu nào có thể thay đổi để phù hợp sản phẩm

·         Yêu cầu nào không thể thỏa hiệp

·         Cách kiểm chứng từng yêu cầu quan trọng

·         Tổng chi phí được đánh giá trong khoảng thời gian nào

·         Trách nhiệm của doanh nghiệp và nhà cung cấp được phân chia ra sao

Dấu hiệu quan trọng nhất không phải tài liệu dài bao nhiêu mà là những nhà cung cấp khác nhau có thể đọc cùng một bộ yêu cầu, hiểu tương đối giống nhau và đưa ra phương án có thể so sánh hay không.

Xác định yêu cầu phần mềm doanh nghiệp là hoạt động làm rõ nhu cầu và điều kiện thành công trước khi đánh giá sản phẩm. Doanh nghiệp cần bắt đầu từ vấn đề, mục tiêu và quy trình; sau đó mới chuyển thành yêu cầu chức năng, phi chức năng, dữ liệu, tích hợp, bảo mật và vận hành.

Mỗi yêu cầu quan trọng phải có lý do, mức ưu tiên và tiêu chí chấp nhận. Khi yêu cầu đủ rõ và có thể kiểm chứng, doanh nghiệp không chỉ chọn phần mềm chính xác hơn mà còn kiểm soát tốt hơn phạm vi, chi phí, trách nhiệm và quá trình nghiệm thu.