Fit-Gap Analysis trong dự án ERP

Fit-gap analysis trong dự án ERP là cách trả lời câu hỏi đó có căn cứ, và nó là kỹ năng phân biệt rõ nhất một người làm BA ERP với một người làm BA phần mềm.

GAP nói theo cách dùng được

Định nghĩa ngắn thì GAP là phần không đáp ứng được, xét giữa yêu cầu và hệ thống mặc định.

Nhưng định nghĩa không giúp bạn làm việc; cái giúp bạn làm việc là hiểu bản chất của công việc này, đó là phân rã một yêu cầu lớn thành nhiều yêu cầu nhỏ, rồi với từng yêu cầu nhỏ trả lời một câu hỏi duy nhất là áp dụng lên hệ thống thì được tới đâu.

Đây là chỗ người mới hay làm sai. Khách nói muốn quản lý đại lý và bạn đánh giá nguyên cụm đó là fit hay gap, như vậy là không được, bởi "quản lý đại lý" chứa trong nó ít nhất năm sáu việc khác nhau:

• phân loại khách lẻ khách sỉ
• lưu thông tin chi nhánh cửa hàng
• áp chính sách giá theo nhóm
• theo dõi công nợ
• xem báo cáo doanh số theo đại lý

Mỗi việc có mức đáp ứng khác nhau và mỗi việc cần một giải pháp khác nhau, do đó tách càng nhỏ thì đánh giá càng chính xác, và báo giá càng gần với khối lượng thật.

Cấu trúc tài liệu GAP

Bảng dưới đây là cấu trúc tôi vẫn dùng; mỗi công ty có thể thêm bớt, nhưng tám cột này nên có.

Ba cột hay bị bỏ nhất là Req ID, Step – Process ID và Description.

Hai cột mã đầu tiên là hai đầu của một sợi dây: Req ID nối ngược lên yêu cầu nghiệp vụ trong BRD, còn mã bước nối ngang sang quy trình tương lai. Bỏ chúng đi thì khi có vấn đề bạn không truy ngược được tính năng này xuất phát từ bước nào của quy trình nào, ai là người yêu cầu, và đã được xác nhận ở buổi khảo sát nào; dự án nhỏ thì không sao, nhưng dự án vài trăm dòng GAP thì bạn sẽ mất cả buổi để tìm.

Bỏ Description thì khách không đọc được tài liệu của bạn, bởi user story viết theo cấu trúc chuẩn và cấu trúc đó không phải cách khách hàng nói chuyện. Họ đọc một dòng kiểu "Là nhân viên quản lý đại lý, tôi muốn có tính năng để quản lý được thông tin của đại lý gồm chi nhánh, cửa hàng, để có thể truy vấn và dễ dàng trong việc chăm sóc khách hàng" và cảm thấy xa lạ. Thêm một cột mô tả bằng đúng từ họ dùng thì buổi review nhanh hơn hẳn.

Viết user story cho dự án ERP

Cấu trúc thì giống mọi nơi khác, là As a [persona], I [want to], [so that]. Dịch cabin có thể hiểu là “Tôi là ai, tôi cần gì và để làm gì (mục đích / tại sao)”.

Điểm khác nằm ở phần "để". Trong dự án ERP, phần mục đích quan trọng hơn phần tính năng, bởi mục đích mới là thứ bạn đối chiếu với hệ thống. User nói muốn có một nút, nhưng hệ thống có thể đạt được mục đích đó bằng một cách hoàn toàn khác mà không cần nút nào.

Lấy một yêu cầu thật làm ví dụ: nhân viên bán hàng muốn lên yêu cầu đặt hàng của đại lý để theo dõi thống kê. Yêu cầu này chỉ ghi nhận thông tin gồm khách nào, thời gian nào, sản phẩm gì, số lượng bao nhiêu, áp chương trình nào để ra đơn giá cuối; nó có thể thay đổi, có thể hủy khi khách từ chối, và đặc biệt là không được ảnh hưởng tới hóa đơn, giao hàng hay tồn kho.

Đọc kỹ phần "để" cùng với phần ràng buộc, bạn nhận ra đây chính là tính năng báo giá. Trên Odoo 19, đơn ở trạng thái Báo giá chưa sinh hóa đơn, chưa sinh phiếu giao hàng và chưa phát sinh chuyển động kho; chỉ khi xác nhận thì nó mới trở thành đơn bán hàng. Yêu cầu này là fit, không cần làm gì thêm nhưng vẫn phải dựng thử trên đúng version mà khách sẽ chạy trước khi ghi vào tài liệu.

Nếu chỉ đọc phần "tôi muốn có chức năng tạo yêu cầu đặt hàng" thì rất dễ kết luận hệ thống không có và phải làm mới.

Ba mức đáp ứng và ranh giới giữa chúng

Đáp ứng hoàn toàn, hay fit, là khi hệ thống đã có sẵn và chỉ cần cấu hình rồi dùng hoặc đây là phần nhiều người bỏ sót. Khi bạn vận dụng một tính năng có sẵn để đáp ứng yêu cầu của user mà không phải làm thêm gì, như case báo giá ở trên.

Đáp ứng một phần là khi hệ thống đã có nhưng cần bổ sung thêm mới đạt đúng mong muốn của khách, chẳng hạn thêm trường thông tin, thêm ràng buộc, hoặc thêm một bước trong luồng.

Không đáp ứng là khi tính năng hoàn toàn chưa có trên hệ thống.

Cái bẫy nằm ở ranh giới giữa "một phần" và "không đáp ứng", và quy tắc phân biệt thực ra rất đơn giản: nếu bạn dùng lại một phân hệ hoặc tính năng có sẵn rồi bổ sung lên đó thì là một phần, còn nếu bạn làm mới hoàn toàn mà không dùng gì của hệ thống thì là không đáp ứng. Phân biệt này không phải chuyện hình thức, bởi nó quyết định khối lượng ước tính, đồng thời quyết định luôn việc sau này nâng cấp phiên bản có bị ảnh hưởng hay không.

Tuy nhiên, bạn vẫn có thể phân loại FIT hoặc GAP để dễ dàng quản lý, lúc này cái bẫy ranh giới giữa "một phần" và "không đáp ứng" không còn tồn tại, vì chúng đã quy về FIT.

Solution

Đây là phần quyết định chất lượng của cả tài liệu, và cũng là phần hầu như không có hướng dẫn nào.

• Đầu tiên, nếu là fit, bạn cần ghi rõ dùng tính năng nào của hệ thống, bởi người đọc sau bạn không biết phải cấu hình cái gì; đừng ghi "hệ thống đáp ứng" rồi thôi.
• Tiếp theo, với mức đáp ứng một phần, bạn ghi dùng tính năng nào và cộng thêm phần phải làm để đáp ứng hết.
• Và đặc biệt, ở mức không đáp ứng thì bạn vẫn phải nêu giải pháp, đây là chỗ nhiều người dừng lại, viết "không đáp ứng" rồi bỏ trống cột giải pháp, trong khi khách hàng không trả tiền để nghe bạn nói hệ thống không làm được, họ trả tiền để biết vậy thì làm thế nào.

Hai giải pháp, và không quá hai

Đây là quy tắc quan trọng nhất của phần này, và nó có hai vế đối nhau.

Lý do phải có nhiều nhất hai là bạn chưa biết khách sẽ chọn theo tiêu chí nào: có khách ưu tiên chi phí, có khách ưu tiên thời gian go-live, có khách ưu tiên độ đáp ứng và sẵn sàng chi thêm. Bạn không quyết định thay họ được, việc của bạn là đưa ra các lựa chọn kèm ưu nhược điểm để họ có cơ sở quyết định.

Lý do không quá hai là nếu bạn đưa bốn năm phương án thì khách sẽ không chọn được, buổi họp review giải pháp biến thành buổi bàn luận, và tới cuối vẫn chưa chốt được gì. Hai phương án là con số vừa đủ để có lựa chọn thật mà vẫn ra được quyết định trong một buổi.

Ba tiêu chí so sánh, và luôn là ba tiêu chí này:

• chi phí
• thời gian thực hiện
• và độ đáp ứng của hệ thống

Cần lưu ý một chuyện, và đây là cách tôi dung hòa giữa hai lời khuyên hay mâu thuẫn nhau trong nghề: trong tình huống bạn đang ở giai đoạn khảo sát và thật sự chưa đủ dữ kiện để loại bớt phương án, thì cứ ghi hết ra rồi cùng tech lead lọc lại trong buổi review nội bộ.

Cái phải giữ tối đa hai là bản gửi khách, không phải bản nháp của bạn.

Ghi nhược điểm tới hệ quả nghiệp vụ

Đây là chỗ phân biệt một tài liệu GAP dùng được với một tài liệu GAP hình thức.

Lấy một yêu cầu thật: phân loại khách hàng là khách lẻ hay khách sỉ để áp chính sách bán hàng tương ứng. Trên Odoo 19, hệ thống có sẵn tính năng gắn thẻ cho liên hệ nên về mặt kỹ thuật là làm được, và đánh giá ở đây là một phần.

Giải pháp thứ nhất là dùng thẻ. Nếu bạn viết nhược điểm là "không tối ưu" thì khách đọc xong không hiểu gì; viết đúng phải là thế này:

“thẻ tag không có ràng buộc nào, nhân viên quên gắn cũng không có cảnh báo, và người dùng có thể vô tình xóa thẻ, dẫn tới hệ quả cuối cùng là dữ liệu khách hàng không phân loại được lẻ hay sỉ, kéo theo chính sách giá áp sai và báo cáo doanh số theo nhóm khách không dùng được”.

Giải pháp thứ hai là thêm một trường phân loại và đặt trường đó bắt buộc, tốn công hơn nhưng dữ liệu chắc chắn.

Khách đọc hai đoạn đó là quyết định được ngay. Đó là mục tiêu của cột giải pháp.

Mức độ khách muốn tới

Có một câu phải đặt trước khi viết giải pháp mà rất hay bị bỏ qua, đó là khách muốn lưu trữ để tra cứu, hay muốn hệ thống ràng buộc bằng logic.

Ví dụ với yêu cầu quản lý hợp đồng nhà cung cấp. Nếu khách chỉ cần lưu mã hợp đồng, loại hợp đồng, ngày ký, ngày bắt đầu, ngày kết thúc để tra cứu và biết khi nào sắp hết hạn, thì đó là một menu đơn giản. Nhưng nếu khách muốn hệ thống chặn không cho đơn mua vượt quá số lượng ghi trên hợp đồng, ràng buộc giá, ràng buộc điều khoản thanh toán, thì đó là một câu chuyện hoàn toàn khác về khối lượng. Hai mức độ đó cách nhau rất xa, và nếu bạn không hỏi thì bạn sẽ báo giá theo mức bạn hiểu còn khách nghiệm thu theo mức họ nghĩ.

Đi kèm nguyên tắc này là một việc phải làm, đó là xin mẫu thật của khách trước khi thiết kế, mẫu hợp đồng thật, biểu mẫu thật, báo cáo thật họ đang dùng.

Thiết kế theo tưởng tượng là làm lại.

Thứ tự các dòng GAP

Nghe như chuyện nhỏ, thực ra không.

Các dòng GAP phải được sắp theo đúng thứ tự của quy trình. Ví dụ dòng "phân loại khách lẻ hay khách sỉ" phải đứng trên dòng "quản lý cửa hàng chi nhánh của khách sỉ", bởi nếu viết ngược thì người đọc tới dòng thứ hai sẽ dừng lại và hỏi làm sao biết đâu là khách sỉ, rồi phải đọc xuống dưới mới hiểu.

Một tài liệu bốn năm dòng thì không sao, nhưng một tài liệu vài trăm dòng mà mỗi dòng đều buộc người đọc nhảy tới nhảy lui thì buổi review sẽ rất dài, và khách sẽ mất kiên nhẫn trước khi tới được những dòng quan trọng. Thứ tự trình bày là cách bạn kể câu chuyện của giải pháp, và người đọc từ trên xuống phải hiểu được chứ không phải tự ghép lại.

Review nội bộ trước khi gửi khách

Tài liệu GAP không được gửi thẳng cho khách sau khi viết xong; phải có một buổi review nội bộ trước, và buổi đó cần đủ đội triển khai, đặc biệt là tech lead để verify về mặt giải pháp.

Ba tiêu chí để đánh giá trong buổi này là đúng, đủ và hợp lý.

• Đúng về giải pháp, tức cái bạn đề xuất có thực sự làm được không và làm theo cách đó có phải cách hợp lý không.
• Đủ về yêu cầu, tức có bỏ sót yêu cầu nào từ báo cáo khảo sát không.
• Và hợp lý về chi phí triển khai, tức khối lượng ước tính có tương xứng với giá trị mang lại không.

Trong trường hợp một số giải pháp cần lập trình hoặc vượt ngoài phạm vi dự án thì còn một bước bàn giao nữa trước khi gặp khách, và tôi để chuyện đó ở bài về việc chốt giải pháp với khách hàng.

Sau khi review nội bộ xong thì gửi tài liệu cho khách và tổ chức một buổi demo giải pháp; cách chuẩn bị buổi đó và cách chốt được lựa chọn ngay trong buổi là một chủ đề riêng đủ dài để nói ở chỗ khác.

Test trên hệ thống trước khi kết luận

Đây là nguyên tắc cuối cùng và cũng là nguyên tắc bị vi phạm nhiều nhất.

Không kết luận fit hay gap dựa trên danh sách tính năng, không kết luận dựa trên trí nhớ về một dự án trước, và không kết luận dựa trên việc module đó có tồn tại. Hãy mở hệ thống lên, dựng đúng kịch bản nghiệp vụ của khách, rồi chạy thử. Rất nhiều thứ trông như fit nhưng khi chạy thật thì phát hiện hai phân hệ không liên kết với nhau, hoặc tính năng đó thuộc phiên bản khác, hoặc hành vi đã đổi so với phiên bản bạn quen dùng.

Chi phí của việc test một yêu cầu thường chỉ là vài chục phút, còn chi phí của việc đánh sai một dòng GAP là phần chênh lệch giữa ngân sách và chi phí triển khai.

Checklist chốt một dòng GAP

Trước khi coi một dòng là xong, kiểm lại:

• Tách yêu cầu đủ nhỏ để chỉ trả lời một câu hỏi
• Điền mã yêu cầu gốc và mã bước tham chiếu về quy trình tương lai
• Viết Description bằng ngôn ngữ khách hàng
• Dựng kịch bản và test thật trên hệ thống
• Ghi version của hệ thống đã test
• Đưa hai giải pháp, không quá hai, ở bản gửi khách
• Ghi nhược điểm mỗi giải pháp tới hệ quả nghiệp vụ
• Hỏi khách muốn lưu trữ tra cứu hay ràng buộc logic
• Xếp dòng này đúng thứ tự quy trình
• Báo sale nếu giải pháp cần code hoặc vượt scope

Mười việc này mất chừng vài phút cho mỗi dòng, và nó tiết kiệm cho bạn nhiều hơn thế rất nhiều ở giai đoạn triển khai.

Còn một chuyện nữa mà tài liệu GAP không tự giải quyết được, và nó là nguyên nhân sinh ra phần lớn rắc rối về sau: một tính năng có tồn tại trong hệ thống không có nghĩa là nó đáp ứng được yêu cầu của khách, và khoảng cách giữa hai chuyện đó là chủ đề của một bài riêng.