"Có tính năng" không đồng nghĩa với "đáp ứng yêu cầu"

Tính năng có. Yêu cầu không được đáp ứng. Đó là hai chuyện khác nhau.

Bốn khoảng cách giữa "có" và "dùng được"

Trong các dự án tôi tham gia, quy trình chọn ERP ở phần lớn doanh nghiệp chạy trên một bảng danh sách chức năng / tính năng / module được chọn: vendor tick, khách so, rồi chọn bên tick nhiều nhất. Cả hai bên đều tin bảng đó nói lên điều gì đó về việc hệ thống có chạy được nghiệp vụ của họ không.

Vấn đề là một bảng tính năng về bản chất không trả lời được câu hỏi nghiệp vụ; nó trả lời câu hỏi hệ thống có chứa thành phần này không, và đó là câu hỏi khác.

Cần nói rõ rằng chuyện này không phải lúc nào cũng là vendor gian dối. Phần lớn trường hợp là vendor tick đúng theo nghĩa hẹp của họ còn khách hiểu theo nghĩa rộng của mình, và không ai sai; cái sai là quy trình, vì nó dừng ở tầng danh sách trong khi câu hỏi thật nằm ở tầng nghiệp vụ.

Trong công việc hằng ngày, việc đánh giá tính năng ERP có thật sự đáp ứng được yêu cầu hay không rơi vào bốn dạng khoảng cách, và biết bốn dạng này thì bạn kiểm được nhanh hơn nhiều.

Có tính năng nhưng không liên kết

Đây là dạng khó phát hiện nhất, bởi mỗi thành phần đứng riêng đều đúng.

Quay lại case phê duyệt ở trên. Yêu cầu gốc của khách là đơn hàng cho đại lý được chiết khấu theo quy tắc của doanh nghiệp, và nếu chiết khấu vượt mức cho phép thì phải được cấp trên duyệt mới xử lý tiếp. Tách nhỏ ra thành hai yêu cầu:

• nhân viên bán hàng tạo được yêu cầu phê duyệt khi đơn vượt mức
• và trưởng bộ phận duyệt được yêu cầu đó

Nhìn vào hệ thống thì cả hai đều làm được, vì có app Approvals, cấu hình được loại phê duyệt, tạo được yêu cầu, và hệ thống tự sinh activity cho người duyệt. Nếu chỉ đối chiếu tới đây thì kết luận là fit.

Tuy nhiên, trước khi kết luận bất cứ điều gì thì có hai chi tiết phải nói ra.

• Đầu tiên, theo kiểm tra mã nguồn Community bản 19 thì app Approvals không nằm trong đó, tức nó là tính năng của bản Enterprise; do đó nếu khách đang cân nhắc bản Community thì toàn bộ phương án này chưa tồn tại, và cái bạn đang đánh giá là fit thực chất là một khoản license chưa được báo giá.
• Tiếp theo, và đây mới là chỗ quan trọng, yêu cầu thật của khách không phải là tạo được yêu cầu duyệt mà là đơn chưa duyệt thì không đi tiếp được, cái đó thì hai phân hệ độc lập không làm được, bởi activity chưa hoàn thành không chặn nút xác nhận đơn.

Khi đã hiểu đúng thì dòng GAP phải viết lại: đánh giá không còn là fit nữa mà là một phần, bởi bạn vẫn dùng module có sẵn và chỉ thiếu ràng buộc; còn cột giải pháp thì có tới ba đường chứ không phải hai như nhiều người vẫn nghĩ.

• Đầu tiên là dùng app Approvals mặc định và chấp nhận rằng việc tuân thủ do nội bộ khách tự quản lý, với nhược điểm phải ghi rõ ra tài liệu là đơn hàng vẫn xác nhận được khi chưa duyệt.
• Tiếp theo là dùng approval rule của Odoo Studio gắn trên chính nút xác nhận đơn, để đơn chỉ chuyển trạng thái khi người có thẩm quyền đã duyệt; đường này không cần code, nhưng Studio cũng thuộc bản Enterprise và việc cài nó có thể kéo theo thay đổi về gói license, đồng thời ghi chép của tôi về cách cấu hình này là từ các bản trước 19 nên phải dựng lại trên đúng bản khách sẽ chạy.
• Cuối cùng là customize bằng code, thêm ràng buộc rằng đơn nào có activity phê duyệt chưa hoàn thành thì không cho xác nhận.

Chọn đường nào là việc của khách. Tuy nhiên, nếu đây là điểm kiểm soát tài chính như chiết khấu, hạn mức công nợ, giá bán,... thì đừng đặt các phương án ngang hàng nhau trong buổi họp; hãy ghi thẳng vào tài liệu rằng phương án thứ nhất không kiểm soát được gì, và nêu rõ bạn khuyến nghị phương án nào.

Có tính năng nhưng thiếu hạ tầng bên ngoài

Dạng này rơi vào các tính năng có yếu tố tích hợp, và nó là chỗ vỡ scope nhiều nhất.

Khách hàng thấy trong hệ thống có chức năng gửi tin nhắn, và họ nghĩ rất tự nhiên rằng có SMS thì gửi được thôi, bật lên là xong.

Thực tế để gửi được một tin nhắn tới khách hàng cuối thì chuỗi công việc như sau:

1. phải tìm và ký với một nhà cung cấp dịch vụ tin nhắn
2. phải được họ mở API
3. phải đăng ký tên thương hiệu hiển thị trên tin nhắn
4. phải đăng ký mẫu tin nhắn với cơ quan quản lý và chờ duyệt
5. rồi cuối cùng mới tới phần việc của bạn là ánh xạ từng tham số trong mẫu tin nhắn với từng trường dữ liệu trong hệ thống

Trong chuỗi đó, phần hệ thống làm được chỉ là mắt xích cuối; bốn mắt xích trước phụ thuộc vào bên thứ ba và vào thời gian phê duyệt mà bạn không kiểm soát được. Nếu bạn đánh dòng này là fit và không nói gì thêm thì hai chuyện sẽ xảy ra: khối lượng công việc thật vượt xa ước tính, và lịch go-live bị trượt vì chờ duyệt mẫu tin nhắn mà trong mắt khách thì đó là lỗi của bạn.

Nguyên tắc rút ra là với bất kỳ tính năng nào có chữ tích hợp, câu hỏi không phải là hệ thống có hỗ trợ không, mà là toàn bộ chuỗi từ đầu tới cuối gồm những mắt xích nào và ai chịu trách nhiệm từng mắt xích.

Cùng một chữ, khác định nghĩa

Dạng này rất hay gặp ở thị trường Việt Nam, và tốn kém vì nó thường bị phát hiện muộn.

Odoo có phân hệ hóa đơn. Khách hàng làm kế toán, nghe "hóa đơn" là hiểu theo nghĩa hóa đơn giá trị gia tăng, thứ có mã số thuế, có ký số, được phát hành theo quy định. Còn hóa đơn trong Odoo là chứng từ ghi nhận công nợ phải thu: nó tính đúng số tiền, đúng thuế suất, đúng hạn thanh toán, và là cơ sở để đối chiếu công nợ, nhưng bản thân nó chưa phải hóa đơn điện tử đã phát hành.

Ở đây cần nói thêm một vế mà nhiều bài viết bỏ qua. Trên Odoo 19 có sẵn module l10n_vn_edi_viettel do chính Odoo S.A. viết, giấy phép LGPL-3, tích hợp với dịch vụ SInvoice của Viettel và có wizard hủy, điều chỉnh hóa đơn; module này được cài tự động khi bật localization Việt Nam. Nghĩa là phần kết nối kỹ thuật đã có sẵn nhưng chuỗi việc phía SInvoice thì vẫn phải đưa vào kế hoạch, gồm:

• tạo tài khoản
• khai mẫu hóa đơn
• khai ký hiệu hóa đơn
• làm thông báo phát hành
• cùng chứng thư số để ký

Đúng dạng khoảng cách thứ hai vừa nói ở trên. Còn với nhà cung cấp khác thì trong mã nguồn Community bản 19 chỉ thấy module cho Viettel SInvoice, nên bạn phải tra Odoo Apps Store hoặc tính phần tích hợp đó vào scope.

Cùng một chữ, hai định nghĩa, và cả hai bên đều không nhận ra mình đang nói chuyện khác nhau cho tới lúc UAT. Đây chính là lý do tài liệu nên có mục thuật ngữ, và mục đó nên được viết bằng đúng cách khách hàng gọi. Tôi từng làm một dự án trong lĩnh vực đào tạo cộng đồng, nơi người học không được gọi là học viên mà gọi bằng một từ nội bộ hoàn toàn khác; nếu không thống nhất từ đầu thì cả dự án nói chuyện lệch nhau suốt.

Tính năng đúng, phiên bản sai

Dạng cuối cùng đơn giản nhất nhưng vẫn xảy ra thường xuyên.

Một tính năng có thể chỉ tồn tại ở bản trả phí chứ không có ở bản cộng đồng. Odoo Studio là ví dụ điển hình: nó thuộc bản Enterprise, và cần lưu ý thêm rằng nó nằm ở gói cao hơn gói cơ bản, nên việc cài Studio có thể kéo theo thay đổi về gói license mà khách chưa tính tới. Studio cũng không chỉ là công cụ chỉnh giao diện như nhiều người tưởng, nó tạo được trường mới, model mới, automation, mẫu in, và cả approval rule như đã nói ở phần trên.

Ngoài chuyện phiên bản trả phí, hành vi hệ thống còn đổi giữa các version. Một ví dụ cụ thể là cơ chế chọn phần thưởng khi một chương trình khuyến mãi có nhiều dòng reward cùng đủ điều kiện: ở các bản cũ hệ thống tự áp phần thưởng có mức chiết khấu cao hơn, còn bản mới thì để người dùng chọn. Mốc đổi rơi vào khoảng version 16 sang 17 theo ghi chép của tôi, nhưng đây đúng là loại chi tiết bạn phải dựng lại trên đúng bản khách chạy chứ đừng tin trí nhớ, kể cả trí nhớ của tôi.

Do đó khi mô tả bất kỳ hành vi nào trong tài liệu, hãy ghi rõ phiên bản. Một dòng nhỏ thôi, nhưng nó cứu bạn khi có người đọc lại tài liệu sau hai năm.

Ba việc phải làm trước khi trả lời khách

Khi khách hỏi hệ thống có làm được cái này không, đừng trả lời từ danh sách tính năng mà hãy trả lời sau khi đã làm ba việc.

Việc thứ nhất là dựng đúng kịch bản của khách chứ không dựng kịch bản demo. Kịch bản demo là kịch bản được thiết kế để chạy trơn tru, còn kịch bản của khách có những chi tiết mà kịch bản demo không có: đơn có nhiều dòng với mức thuế khác nhau, khách hàng vừa là nhà cung cấp, hàng giao làm nhiều đợt. Chính những chi tiết đó làm lộ ra khoảng cách.

Việc thứ hai là chạy hết luồng chứ không dừng ở màn hình. Rất nhiều khoảng cách chỉ hiện ra ở bước sau: tạo được yêu cầu phê duyệt là một chuyện, bấm xác nhận đơn xem có bị chặn không là chuyện khác; nhập được số liệu là một chuyện, xem báo cáo có ra đúng con số đó không là chuyện khác.

Việc thứ ba là hỏi ngược lại khách để biết họ muốn tới mức nào, bởi cùng một yêu cầu thì mức "lưu trữ để tra cứu" và mức "hệ thống ràng buộc bằng logic" cách nhau rất xa về khối lượng, và bạn không đoán được nếu không hỏi.

Sau ba việc đó, câu trả lời của bạn không còn là được hay không được nữa, mà là được theo cách này, và có điểm này anh chị cần biết trước. Đó là câu trả lời mà khách hàng tin được, và cũng là câu trả lời bảo vệ được bạn về sau.

Cái giá của việc bỏ qua

Chi phí của việc dựng thử một kịch bản thường chỉ là vài chục phút.

Chi phí của việc không dựng thử hiện ra muộn hơn nhiều, và nó không rơi vào lúc ký hợp đồng mà rơi vào giai đoạn UAT, khi khách hàng thao tác thật và phát hiện hệ thống không chặn cái đáng lẽ phải chặn. Lúc đó bạn ở vào tình thế khó: khách nói đây là lỗi, bạn biết hệ thống đang chạy đúng như đã mô tả, và cả hai đều đang nói thật.

Đó là một cuộc trò chuyện khác, và nó đáng được nói riêng.