BRD, FRD, SRS trong dự án ERP: ba tài liệu, ba câu hỏi khác nhau

Ba câu hỏi thay cho ba định nghĩa

Ba tài liệu quen thuộc trong nghề BA thật ra là ba tầng của cùng một câu chuyện, và mỗi tầng trả lời đúng một câu.

• Tài liệu yêu cầu nghiệp vụ, tức BRD, trả lời câu vì sao doanh nghiệp cần làm chuyện này và phạm vi tới đâu.
• Tài liệu yêu cầu chức năng, tức FRD, trả lời câu hệ thống cần làm được những gì để đáp ứng cái đó.
• Còn tài liệu đặc tả yêu cầu phần mềm, tức SRS, trả lời câu hệ thống sẽ làm việc đó bằng cách nào, chi tiết tới mức một người chưa từng dự buổi khảo sát nào cũng làm được.

Cần lưu ý rằng ba câu hỏi này không phải ba mức độ chi tiết của cùng một nội dung, mà là ba loại nội dung khác nhau. Bạn không thể viết BRD chi tiết hơn để nó thành SRS, giống như bạn không thể mô tả kỹ hơn lý do đi du lịch để nó biến thành lịch trình chuyến đi.

Cách nhanh nhất để thấy sự khác biệt là lấy một yêu cầu thật rồi viết nó ra ba lần.

Một yêu cầu chạy xuyên ba tầng

Yêu cầu tôi chọn làm ví dụ là chuyện phê duyệt đơn mua hàng theo hạn mức, vì gần như dự án ERP nào cũng gặp và vì nó đủ đơn giản để nhìn ra sự khác biệt giữa ba tầng.

Ở tầng nghiệp vụ, yêu cầu được viết như sau: doanh nghiệp cần kiểm soát chi phí mua hàng để giảm rủi ro chi vượt ngân sách và rút ngắn thời gian chờ duyệt, do hiện tại toàn bộ việc duyệt đang chạy qua email và chữ ký giấy nên trung bình mỗi đơn phải chờ vài ngày, đồng thời không có cách nào tra lại được ai đã duyệt cái gì vào lúc nào. Bạn để ý là ở tầng này không có chữ nào nói về hệ thống, không có nút bấm, không có trạng thái, chỉ có vấn đề kinh doanh và kết quả mong đợi.

Ở tầng chức năng, cũng yêu cầu đó được viết lại thành: hệ thống phải chặn việc xác nhận đơn mua hàng khi giá trị đơn vượt hạn mức của người tạo, phải chuyển đơn sang trạng thái chờ duyệt và thông báo cho người có thẩm quyền tương ứng, phải lưu lại lịch sử ai duyệt lúc nào, và phải cho phép người duyệt trả đơn về kèm lý do. Ở tầng này đã có hành vi hệ thống, nhưng chưa có chi tiết kỹ thuật, và cũng chưa nói gì tới việc hệ thống đó là Odoo, SAP hay một nền tảng ERP bất kỳ.

Ở tầng đặc tả thì mọi thứ đổi hẳn, bởi đây là tầng duy nhất trong ba tầng buộc bạn phải mở hệ thống thật ra xem. Trên Odoo 19, phân hệ Mua hàng đã có sẵn cấu hình duyệt đơn theo ngưỡng giá trị ở cấp công ty: bật tính năng lên, nhập số tiền tối thiểu, và mọi đơn vượt ngưỡng đó đều phải qua duyệt. Do đó phần "hệ thống chặn đơn vượt ngưỡng" ở tầng chức năng không phải hạng mục lập trình mà là một dòng cấu hình, và cái thật sự tạo ra khoảng cách chỉ còn là biến thể mà doanh nghiệp muốn, tức ngưỡng đặt riêng theo từng người tạo đơn chứ không đặt chung cho cả công ty. Tài liệu đặc tả vì vậy chỉ mô tả đúng phần chênh lệch đó: hạn mức lưu ở đâu, điều kiện so sánh chạy lúc nào, luồng chính người mua thực hiện, luồng thay thế khi người duyệt vắng mặt, luồng ngoại lệ khi đơn bị trả về, kèm bảng trường dữ liệu và ảnh chụp màn hình có đánh số, còn bức tranh đầy đủ của nghiệp vụ mua hàng và phê duyệt này là chủ đề của một bài riêng.

Ba đoạn trên cùng nói về một chuyện. Tuy nhiên, người đọc của chúng khác nhau hoàn toàn: đoạn đầu dành cho người ký hợp đồng, đoạn giữa dành cho người quyết định phạm vi, đoạn cuối dành cho người viết code và người viết kịch bản kiểm thử.

Đặc biệt, ví dụ này còn cho thấy một chuyện mà chỉ dự án triển khai nền tảng có sẵn mới gặp: cùng một câu ở tầng chức năng, tùy hệ thống bạn đang dùng mà nó rơi vào cấu hình hay rơi vào lập trình, và người viết tài liệu không biết điều đó thì sẽ báo giá sai ngay từ đầu.

Bốn loại yêu cầu — cái khung thật

Ba cái tên tài liệu chỉ là vỏ. Cái khung thật sự giúp bạn biết mình đang viết gì là bốn loại yêu cầu, và đây là phần tôi thấy đáng học hơn cả việc so sánh tên file.

Trên cùng là yêu cầu doanh nghiệp, tức mục tiêu chiến lược do ban lãnh đạo đưa ra, giải thích tại sao doanh nghiệp bỏ tiền làm dự án này, và thường gắn với doanh thu, chi phí, hoặc một chỗ vận hành đang tốn quá nhiều người. Một câu điển hình ở tầng này nghe như thế này: triển khai hệ thống để tự động hóa quy trình xử lý đơn hàng và hạch toán kế toán, giảm ba mươi phần trăm thời gian xử lý đơn và hạn chế tối đa sai sót dữ liệu trong vòng sáu tháng sau khi vận hành.

Cụ thể hơn một bậc là yêu cầu của các bên liên quan, xuất phát từ khó khăn thật của một phòng ban hay một vị trí. Chẳng hạn kế toán muốn hệ thống tự ghi nhận doanh thu và tự tạo hóa đơn nháp ngay khi bộ phận kinh doanh xác nhận đơn hàng, thay vì phải ngồi nhập lại hóa đơn từ đầu theo từng đơn.

Xuống tới tầng giải pháp thì yêu cầu chia làm hai nhánh mà bạn chắc đã quen, nhánh chức năng nói hệ thống làm được cái gì và nhánh phi chức năng nói hệ thống phải vận hành như thế nào, tức là giao diện, trải nghiệm, hiệu năng, lưu trữ và bảo mật. Cần lưu ý rằng nhánh phi chức năng hay bị viết thành mấy câu chung chung kiểu giao diện phải thân thiện, và một câu như vậy thì không nghiệm thu được; nếu muốn nó có giá trị thì phải viết ra con số, ví dụ trang danh sách đơn hàng phải hiển thị trong bao nhiêu giây với bao nhiêu bản ghi.

Loại cuối cùng là yêu cầu chuyển đổi, và đây là loại bị bỏ sót nhiều nhất trong các bài so sánh tài liệu. Đặc điểm của nó là chỉ tồn tại tạm thời trong giai đoạn chuyển từ hệ thống cũ sang hệ thống mới, và khi hệ thống mới chạy ổn định thì nó biến mất; chuyển toàn bộ số dư đầu kỳ, danh sách khách hàng và danh mục sản phẩm từ Excel lên hệ thống, hoàn tất trước ngày go-live ba ngày, là một yêu cầu chuyển đổi điển hình.

Đặc biệt, loại thứ tư này là thứ hay làm vỡ kế hoạch nhất, bởi nó không nằm trong danh sách tính năng nên không ai ước lượng công sức cho nó, trong khi khối lượng thực tế của việc làm sạch và đưa dữ liệu lên hệ thống thường lớn hơn nhiều so với hình dung ban đầu của cả hai bên.

Thứ tự bị đảo trong dự án ERP

Tới đây là chỗ mà nội dung BA phổ thông và thực tế triển khai ERP tách nhau ra, và nếu bạn học nghề bằng giáo trình rồi vào dự án Odoo thì đây là chỗ dễ hụt chân nhất.

Theo trình tự chuẩn mà phần lớn tài liệu mô tả, bạn viết BRD trước để chốt yêu cầu và phạm vi, sau đó mới xuống FRD rồi tới SRS. Trình tự đó hợp lý khi phần mềm được viết từ đầu, bởi lúc chưa có gì trong tay thì phải mô tả từ trên xuống.

Trong dự án triển khai một nền tảng có sẵn thì tình thế ngược lại. Bạn không đứng trước một tờ giấy trắng mà đứng trước một hệ thống đã có rất nhiều tính năng, nên câu hỏi đắt nhất không phải là khách muốn gì mà là chỗ nào hệ thống chưa đáp ứng được cái khách muốn.

Do đó trình tự thực tế mà tôi vẫn đi như sau:

1. Đầu tiên là khảo sát
2. tiếp theo là vẽ hai bộ lưu đồ quy trình hiện tại và tương lai
3. sau đó phân tích yêu cầu theo từng quy trình
4. rồi viết tài liệu GAP
5. rồi review và chốt với khách
6. Chỉ khi hợp đồng yêu cầu bàn giao BRD thì tôi mới viết BRD
7. Cuối cùng mới tới tài liệu giải pháp

Nghe thì giống như làm ngược quy trình, nhưng thực chất không phải: phần việc mà BRD đảm nhiệm trong dự án viết mới, tức xác định phạm vi và chốt yêu cầu, vẫn được làm đầy đủ, chỉ là nó được làm bằng lưu đồ quy trình và tài liệu GAP, tức là bằng hai thứ mà khách hàng đọc hiểu và ký xác nhận được, thay vì bằng một văn bản mô tả.

Chuyện dự án nào bỏ được BRD và bỏ rồi thì ai kẹt, tôi đã nói ở bài về bộ tài liệu dự án ERP. Ở đây chỉ cần thấy rằng trình tự đảo ngược này không sinh ra từ việc làm tắt, mà sinh ra từ việc bạn có sẵn một hệ thống để đối chiếu.

Chỗ trống của FRD

Câu trả lời thẳng là trong bộ tài liệu tôi dùng cho dự án Odoo, FRD không tồn tại như một file riêng.

Lý do nằm ở chính đặc thù của nền tảng có sẵn. Tầng nội dung mà FRD phụ trách, hệ thống cần làm được những gì, trong dự án triển khai lại chính là câu hỏi hệ thống có sẵn đã làm được những gì và còn thiếu những gì, và câu đó được trả lời trong tài liệu GAP chứ không phải trong một văn bản mô tả chức năng.

Cụ thể hơn, mỗi dòng trong tài liệu GAP là một yêu cầu đã được tách nhỏ, kèm đánh giá hệ thống có đáp ứng hay không, kèm hướng giải pháp. Đó đúng là nội dung mà FRD mang, chỉ khác là nó nằm ở dạng bảng và luôn được đối chiếu với hệ thống thật.

Bên cạnh đó, trong bộ template tôi dùng thì tầng "làm thế nào" được tách làm hai tài liệu chứ không gộp một, và lý do tách thì thuộc về bài bộ tài liệu. Điều đáng nói ở bài này là hệ quả với người viết: bạn phải quyết định mỗi dòng GAP sẽ rơi vào tài liệu nào ngay lúc chốt GAP với khách, chứ không phải lúc ngồi mở file ra viết, bởi hai tài liệu đó đi theo hai lịch nghiệm thu khác nhau.

Phần đáng đầu tư nhất của một bản BRD

Giả sử hợp đồng có yêu cầu bàn giao BRD và bạn phải viết. Vậy thì trong tất cả các mục, mục nào đáng dành thời gian nhất.

Câu trả lời không phải mục yêu cầu chức năng như nhiều người nghĩ, mà là mục phạm vi dự án, và trong đó cụ thể hơn nữa là phần ngoài phạm vi.

Phần trong phạm vi thì bạn viết càng cụ thể càng tốt: version và bản Community hay Enterprise, danh sách phân hệ triển khai, hình thức hosting, danh sách tích hợp bên thứ ba, và danh sách tính năng cần lập trình lấy từ tài liệu GAP. Ghi tới mức đó thì sau này không ai tranh cãi được là dự án bao gồm cái gì.

Phần ngoài phạm vi thì ngược lại với thói quen của nhiều người, tức là phải viết dài hơn chứ không phải ngắn hơn. Thay vì một câu chung chung kiểu những nội dung không nêu trong tài liệu này đều nằm ngoài phạm vi, hãy liệt kê thẳng ra những phân hệ không triển khai lần này, những báo cáo khách đã hỏi nhưng chưa được duyệt ngân sách, những tích hợp đã bàn tới nhưng chưa chốt; với mỗi dòng thì ghi thêm ai là người đề xuất và đề xuất vào thời điểm nào.

Viết một danh sách như vậy nghe có vẻ tiêu cực trong giai đoạn hai bên đang vui vẻ ký hợp đồng. Tuy nhiên, tới giai đoạn kiểm thử khi có người hỏi tại sao chưa có tính năng này, danh sách đó là thứ duy nhất giúp cuộc trao đổi dừng lại ở mức đối chiếu tài liệu thay vì biến thành tranh cãi về việc ai đã hứa gì với ai.

Thang ưu tiên năm mức

Một mục nữa trong BRD hay bị làm cho có là độ ưu tiên. Rất nhiều tài liệu ghi ba mức cao, trung bình, thấp rồi để đó, và ba chữ đó không giúp ai ra quyết định cả, bởi hỏi mười người thì mười người hiểu chữ "cao" theo mười cách.

Thang tôi dùng có năm mức, và điểm mấu chốt là mỗi mức được định nghĩa bằng hệ quả chứ không bằng cảm giác.

• Mức Critical dành cho những yêu cầu mà thiếu nó thì dự án không còn ý nghĩa, tức hệ thống không dùng được cho nghiệp vụ chính.
• Ngay dưới đó, High là những yêu cầu mà thiếu nó thì hệ thống vẫn chạy được ở mức tối thiểu nhưng người dùng phải làm tay ở nhiều chỗ, và đây cũng là mức hay bị đẩy lên Critical nhất trong buổi review.
• Hai mức giữa thì dễ phân định hơn: Medium mang lại giá trị rõ ràng nhưng không bắt buộc để vận hành, còn Low là thứ làm được thì tốt, phụ thuộc vào thời gian và chi phí còn lại.
• Mức cuối cùng là Future, dành cho những yêu cầu đã ghi nhận nhưng nằm ngoài phạm vi lần này.

Đặc biệt, Future là mức có giá trị lớn nhất trong danh sách xét về mặt quan hệ giữa hai bên, bởi nó cho phép bạn ghi nhận mong muốn của khách mà không đưa nó vào cam kết. Người đề xuất thấy ý kiến của mình được ghi lại nên không cảm thấy bị bỏ qua, còn phạm vi dự án thì vẫn được giữ nguyên.

Thang này cũng là thang bạn dùng lại ở cột độ ưu tiên trong tài liệu GAP, nên đặt định nghĩa cho nó một lần từ đầu dự án thì về sau đỡ phải giải thích nhiều lần.

Năm câu tự kiểm trước khi thực hiện tài liệu

Trước khi bắt đầu thực hiện tài liệu, hãy trả lời năm câu sau.

Trước tiên, hãy áp dụng quy tắc 5W1H khi thực hiện bất kỳ một tài liệu nào:

• Tài liệu này là gì (What)
• Tài liệu này áp dụng ở giai đoạn nào (When)
• Tài liệu này áp dụng nội bộ hay public (Where)
• Tài liệu này do ai thực hiện, ai đọc, ai duyệt,... (Who)
• Tại sao cần thực hiện tài liệu này (Why)
• và cuối cùng, tài liệu này được thực hiện như thế nào (How)

Khi trả lời được tất cả các câu hỏi đó, bạn hãy bắt đầu thực hiện, nếu không hãy tìm hiểu kỹ để tránh mất thời gian của chính bạn hoặc người khác.