Bạn vẫn xem được các bài đã đăng mà không cần đăng nhập.
Ba tầng chứ không phải hai, cây quyết định bốn câu hỏi, và vì sao nửa vời là kịch bản tệ nhất khi cân nhắc customize hệ thống ERP.
Khách mô tả xong một nghiệp vụ, và câu hỏi đầu tiên bật ra trong phòng họp gần như luôn là cái này có customize được không.
Câu đó sai, và nó sai theo một cách rất kín đáo: nó giả định rằng chỉ có hai lựa chọn, và rằng lựa chọn nằm ở phía kỹ thuật. Thực tế là có ba tầng để chọn, và câu hỏi quyết định lại là một câu hỏi kinh doanh chứ không phải câu hỏi kỹ thuật
Cách chia phổ biến khi bàn về chủ đề này là hai tầng: hoặc dùng cấu hình có sẵn, hoặc viết code. Trên Odoo thì giữa hai tầng đó còn một tầng nữa, và tầng giữa này có ranh giới riêng đáng biết. Những gì mô tả dưới đây là hành vi tôi ghi nhận trên Odoo 19; Studio đổi khá nhanh giữa các bản nên nếu bạn đang chạy bản khác thì hãy dựng lại trước khi tin.
Đầu tiên là tầng cấu hình, gồm bật tắt tính năng trong phần cài đặt, khai báo bảng giá, dựng quy tắc kho, đặt ngưỡng phê duyệt và phân quyền. Đây là thứ hệ thống được thiết kế để người dùng tự làm, và nó không để lại dấu vết gì khi nâng cấp.
Tiếp theo là tầng Studio, nơi bạn thêm trường mới, đổi nhãn, cho ẩn hiện theo điều kiện, thêm menu và dạng xem, thêm tiêu chí tìm kiếm và bộ lọc, sửa mẫu in, thêm Smart Button, dựng luồng phê duyệt nhiều cấp, phân quyền hiển thị từng trường theo nhóm người dùng, và thậm chí tạo cả model mới lẫn module mới — tức gần như toàn bộ những gì một yêu cầu cỡ vừa cần, mà không phải gọi developer. Đây cũng chính là lý do tầng này hay bị đánh giá sai ở cả hai phía.
Và cuối cùng là tầng code, dành cho logic phức tạp, workflow phức tạp, cùng việc tích hợp với hệ thống bên ngoài, những chỗ mà Studio không đáp ứng được. Ngoài ra còn vài chỗ nhỏ hơn nhưng cũng bắt buộc phải có developer, gồm:
Cần lưu ý một chuyện về tầng giữa: Studio thuộc bản Enterprise, không có trong bản Community. Do đó nếu khách đang cân nhắc bản Community thì bạn chỉ có hai tầng thật, và toàn bộ những gì Studio làm được sẽ rơi xuống tầng code cùng với chi phí tương ứng, đây là chuyện phải nói trước khi báo giá chứ không phải sau.
Đây là chỗ hay bị hiểu sai theo cả hai hướng: có người coi Studio là customize nên né, có người coi nó là cấu hình nên dùng thoải mái.
Về mặt kỹ thuật, Studio không sửa vào phần lõi của hệ thống. Nó tạo ra các view kế thừa dưới dạng XML nằm ngoài lõi, nên khi nâng cấp thì phần lõi vẫn được cập nhật bình thường. Ở nghĩa đó thì nó đứng gần phía cấu hình hơn phía code.
Nhưng có hai chỗ Studio vượt ra khỏi ranh giới đó, và cả hai đều đáng biết trước.
Chỗ thứ nhất là tạo model mới. Đây là điểm không quay đầu được, bởi model tạo bằng Studio thì không xóa được. Điều buồn cười là module lại xóa được dễ dàng, vì module thực chất chỉ là menu. Sự bất đối xứng đó nghĩa là bạn có thể thử nghiệm với module, nhưng việc tạo model phải được coi như một quyết định thiết kế, không phải một thao tác thử cho biết.
Chỗ thứ hai là chuyện phân quyền, và ở đây cần phân biệt hai thứ hay bị gộp làm một. Studio có phân quyền thật ở cấp trường, tức cho phép hoặc cấm một nhóm người dùng nhìn thấy một trường cụ thể, và đây là công cụ hợp lệ mà BA chủ động dùng được. Nhưng Studio cũng có tùy chọn tắt nút tạo, sửa, xóa trên một dạng xem, và cái này thì không phải phân quyền, đó chỉ là ẩn nút trên giao diện, người dùng hiểu hệ thống thì lách được, nên muốn chặn thật thì vẫn phải dùng song song với phân quyền ở tầng dữ liệu.
Bên cạnh đó còn một chuyện nữa cần biết trước khi giao Studio cho ai: nó không lưu lịch sử thay đổi, nên mọi thứ làm bằng Studio phải được ghi tay vào tài liệu nếu bạn muốn còn dấu vết về sau.
Trước khi hỏi customize được không, hãy đi qua bốn câu này.
Câu thứ nhất: nghiệp vụ này có phải lợi thế cạnh tranh của doanh nghiệp không? Đây là câu quan trọng nhất và cũng là câu hay bị bỏ qua nhất. Nếu cách làm hiện tại của khách là thứ khiến họ khác biệt trên thị trường, ví dụ như cách họ tính hoa hồng cho đại lý, cách họ phân bổ hàng cho các kênh... thì bạn nên bảo vệ nó và làm hệ thống theo họ. Còn nếu đó chỉ là thói quen hình thành từ giới hạn của phần mềm cũ, thì đổi quy trình rẻ hơn đổi hệ thống rất nhiều.
Câu thứ hai: hệ thống có cách khác đạt được cùng mục đích không? Rất nhiều GAP trông như phải custom hóa ra do người thiết kế giải pháp chưa nắm rõ về độ đáp ứng của hệ thống. Bài toán theo dõi hàng đang trên đường giữa hai kho là ví dụ điển hình: cấu hình mặc định không đáp ứng, nhưng giải được bằng vị trí trung chuyển kết hợp với tuyến và quy tắc, không cần một dòng code nào. Cách xử lý đó tôi sẽ nói kỹ ở một bài riêng, vì tư duy phía sau nó dùng lại được cho nhiều bài toán kho khác.
Câu thứ ba: nếu phải làm thêm thì Studio có đủ không? Trả lời câu này đòi hỏi bạn biết ranh giới ở mục trên. Và nếu câu trả lời là Studio đủ, còn một câu phụ nữa: dự án này có yêu cầu nào khác bắt buộc phải code không? Bởi việc trộn Studio với code trong cùng một dự án là chuyện cần cân nhắc ở cấp dự án chứ không phải cấp từng yêu cầu.
Câu thứ tư: nếu phải code thì nó ảnh hưởng gì tới lần nâng cấp sau? Đây là câu biến một quyết định kỹ thuật thành một con số, và cách ước lượng con số đó thì tôi đã nói riêng ở bài về nợ kỹ thuật của customization.
Đây là phần tôi muốn nhấn nhất, và nó đi ngược với trực giác tiết kiệm.
Khi một nghiệp vụ của khách thực sự khác với cách hệ thống làm, bạn có hai lựa chọn lành mạnh.
Cả hai đều có cái giá của nó và cả hai đều chạy được.
Lựa chọn thứ ba, và là lựa chọn hay được chọn nhất vì nó rẻ nhất trên báo giá, là làm một nửa: hệ thống lo phần dễ, còn phần khó thì để người dùng bù bằng thao tác thủ công, bằng file Excel bên ngoài, bằng quy ước nội bộ.
Cách này trông như thỏa hiệp hợp lý, nhưng thực tế nó gộp nhược điểm của cả hai phía: dữ liệu vẫn nằm ngoài hệ thống nên báo cáo vẫn sai, mà chi phí thì vẫn đã bỏ ra.
Dấu hiệu nhận biết bạn đang rơi vào phương án nửa vời: trong tài liệu giải pháp có câu nào đó đại ý là người dùng sẽ tự theo dõi phần này bên ngoài, hoặc bộ phận kia sẽ đối chiếu thủ công hằng tháng. Mỗi câu như vậy là một chỗ mà sáu tháng sau sẽ có người hỏi vì sao số trên hệ thống không khớp.
Việc của bạn không phải là quyết định thay khách mà là làm cho họ quyết định được, và điều đó nghĩa là mỗi phương án phải đi kèm ba thông tin:
Phần đánh đổi là phần hay bị viết chung chung nhất. Đừng ghi "phương án này kém linh hoạt hơn", hãy ghi đúng hệ quả nghiệp vụ:
Và với những nghiệp vụ mà bạn thực sự khuyến nghị đổi quy trình thay vì đổi hệ thống, hãy nói thẳng điều đó kèm lý do.
Khách hàng phân biệt được giữa một đối tác đang tiết kiệm công sức cho mình và một đối tác đang bảo vệ khoản đầu tư của họ, và sự phân biệt đó nằm ở chỗ bạn có giải thích được lý do hay không.
Có một câu hỏi mà bốn câu ở trên chưa trả lời hết: nếu dự án vừa có phần dùng Studio vừa có phần phải code thì sao. Câu trả lời của tôi khá cực đoan và tôi sẽ nói riêng, vì nó là nguyên tắc ảnh hưởng tới toàn bộ cách tổ chức một dự án Odoo chứ không chỉ tới một dòng trong tài liệu GAP.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận