Khi chuẩn bị triển khai ERP, nhiều doanh nghiệp bắt đầu bằng câu hỏi: “Chúng ta có bao nhiêu nhân viên cần sử dụng Odoo?”
Đó là một dữ liệu cần có, nhưng chưa đủ để tính số lượng tài khoản. Trong cùng một doanh nghiệp, nhân viên kinh doanh tạo đơn hàng, thu ngân thao tác tại quầy, nhân viên kho quét mã và nhân viên văn phòng xin nghỉ phép đều “sử dụng hệ thống” theo những cách khác nhau. Quyền truy cập của họ cần được xác định từ công việc thực tế.
Sự xuất hiện của Light User trong Odoo 20 là dịp để doanh nghiệp xem lại cách phân loại người dùng. Trước khi tính chi phí license, hãy làm rõ mỗi vị trí cần thực hiện thao tác nào, trên ứng dụng nào và tại bước nào của quy trình.
Light User là gì
Theo phần mô tả trên trang giá Odoo, Light User liên quan đến hai trường hợp: nhân viên được lưu hồ sơ nhưng không có tài khoản đăng nhập; và người dùng có tài khoản với phạm vi truy cập giới hạn.
Những hoạt động được Odoo nêu gồm một số tác vụ cá nhân và nhân sự, Planning, thao tác trong phiên POS với vai trò nhân viên, đọc Knowledge và sử dụng Barcode trong phạm vi nhất định. Phạm vi cụ thể cần được kiểm tra theo cấu hình hệ thống và điều kiện cấp phép áp dụng.
Quét mã trong kho không đồng nghĩa với quyền quản lý toàn bộ nghiệp vụ kho. Một người chỉ quét hàng theo bước được giao có nhu cầu khác với thủ kho cần tạo sản phẩm, điều chỉnh tồn kho, xử lý chứng từ và xem báo cáo. Tương tự, không thể kết luận một vị trí phù hợp với Light User chỉ dựa trên tên chức danh.
Ví dụ doanh nghiệp bán lẻ có 200 nhân sự và kho trung tâm
Giả sử một doanh nghiệp có văn phòng điều hành, nhiều cửa hàng và một kho trung tâm. Nếu lấy tổng số 200 nhân sự để dự toán cùng một loại tài khoản, kết quả có thể không phản ánh đúng cách doanh nghiệp vận hành.
Nhóm triển khai nên bắt đầu bằng một ma trận vai trò:
Nhóm nhân sự | Công việc cần khảo sát trên Odoo | Điểm cần xác nhận |
| Kinh doanh và mua hàng | Tạo, sửa đơn hàng; lập yêu cầu mua; theo dõi và phê duyệt chứng từ | Ứng dụng, quyền tạo/sửa/duyệt và phạm vi dữ liệu |
| Kế toán và quản lý kho | Xử lý nghiệp vụ, đối soát, báo cáo, điều chỉnh khi phát sinh | Quyền nghiệp vụ và các bước ngoại lệ |
| Thu ngân | Thao tác bán hàng trong phiên POS | Vai trò trong POS và quyền cần dùng ngoài phiên bán hàng |
| Nhân viên kho | Quét mã theo quy trình nhận, chuyển hoặc xuất hàng | Có cần tạo chứng từ, điều chỉnh tồn hoặc quản lý sản phẩm không |
| Nhân viên dùng chức năng nhân sự | Xem thông tin cá nhân, chấm công, xin nghỉ phép, xem lịch | Chức năng thực tế có nằm trong phạm vi quyền giới hạn không |
| Nhân sự chỉ cần lưu hồ sơ | Không đăng nhập hệ thống | Cách quản lý hồ sơ và điều kiện tính phí áp dụng |
Bảng trên là ví dụ để khảo sát, không phải kết luận cấp license cho 200 nhân sự.
Cùng một chức danh có thể cần quyền khác nhau
Hãy xét hai nhân viên tại kho trung tâm. Người thứ nhất nhận danh sách công việc và chỉ quét mã để xác nhận hàng đã được lấy hoặc bàn giao. Người thứ hai ngoài quét mã còn tạo sản phẩm, xử lý hàng lệch, điều chỉnh tồn kho và kiểm tra báo cáo. Nếu chỉ ghi cả hai là “nhân viên kho”, doanh nghiệp sẽ bỏ sót sự khác biệt quan trọng khi thiết kế quyền.
Điều này cũng xảy ra ở cửa hàng. Một thu ngân bán hàng trong phiên POS có thể cần phạm vi truy cập khác với quản lý cửa hàng, người phải xử lý đổi trả, kiểm tra doanh thu và phê duyệt các tình huống phát sinh.
Chức danh là điểm bắt đầu để khảo sát; danh sách thao tác mới là cơ sở để thiết kế quyền.
NOS đề xuất bốn bước trước khi chốt số lượng tài khoản
1. Ghi lại thao tác của từng vai trò
Với mỗi vị trí, xác định họ cần xem, tạo, sửa, xác nhận hay phê duyệt dữ liệu gì. Ghi rõ ứng dụng sử dụng, tần suất và phạm vi dữ liệu theo cửa hàng, kho hoặc công ty.
2. Đi theo quy trình từ đầu đến cuối
Một đơn bán hàng có thể bắt đầu tại cửa hàng, đi qua kho trung tâm và kết thúc ở kế toán. Cần xác định ai thao tác trên Odoo tại mỗi điểm bàn giao, ai chỉ cần nhận thông tin và ai chịu trách nhiệm xử lý ngoại lệ.
3. Kiểm thử bằng tài khoản đại diện
Tạo tài khoản thử cho từng nhóm vai trò và chạy cả tình huống thông thường lẫn tình huống phát sinh: thiếu hàng, đổi trả, sai lệch kiểm kê hoặc cần phê duyệt. Nếu người dùng không hoàn thành được công việc với quyền dự kiến, ma trận phải được điều chỉnh trước khi chốt phương án.
4. Tính ngân sách sau khi xác nhận quyền
Khi đã rõ số người theo từng nhóm quyền, doanh nghiệp mới đối chiếu báo giá và điều kiện cấp phép. Ngân sách dự án cũng cần tính đến triển khai, tích hợp, hạ tầng, đào tạo và hỗ trợ sau vận hành.
Một mức giá tham khảo trên mạng không đủ để kết luận chi phí cho doanh nghiệp. Giá và điều kiện áp dụng cần được xác nhận tại thời điểm lập báo giá.
Phân quyền là một phần của thiết kế vận hành
Light User đem lại thêm một lựa chọn để xem xét khi doanh nghiệp có nhiều nhân sự tại cửa hàng, kho hoặc các bộ phận vận hành. Hiệu quả của lựa chọn đó phụ thuộc vào việc mô tả đúng công việc và kiểm thử quyền trên quy trình thực tế.
Với NOS ERP Consulting, câu hỏi đầu tiên trong bài toán người dùng ERP không chỉ là “có bao nhiêu người?”, mà còn là: “Ai cần làm việc gì trên hệ thống để quy trình vận hành trọn vẹn?”
Nếu doanh nghiệp đang chuẩn bị triển khai hoặc nâng cấp Odoo, liên hệ NOS để cùng rà soát ma trận vai trò, quyền truy cập và phương án ngân sách phù hợp.
Tham khảo: Odoo Pricing và Odoo 20 Release Notes. Phạm vi quyền và điều kiện cấp phép cần được xác nhận lại trên phiên bản, cấu hình và báo giá áp dụng cho từng doanh nghiệp.