Một doanh nghiệp có 200 nhân sự không đồng nghĩa phải mua 200 tài khoản ERP cùng một loại.
Có người cần tạo đơn hàng, xác nhận nhập xuất kho, xử lý chứng từ kế toán hoặc phê duyệt giao dịch. Có người chỉ thực hiện một số tác vụ giới hạn. Cũng có nhân sự chỉ cần được lưu hồ sơ trên hệ thống và không đăng nhập.
Vì vậy, câu hỏi đúng không phải là:
“Công ty có bao nhiêu nhân viên?”
Mà là:
“Mỗi người cần làm gì trên hệ thống, được xem dữ liệu nào và có phải xử lý ngoại lệ hay không?”
Checklist dưới đây giúp doanh nghiệp thực hiện bước phân loại ban đầu trước khi đối chiếu chính sách cấp phép và lập ngân sách Odoo.
Trước tiên, cần hiểu đúng ba nhóm
Trong phạm vi bài viết, NOS sử dụng ba nhóm làm khung khảo sát nghiệp vụ. Đây chưa phải kết luận cấp phép cuối cùng cho từng doanh nghiệp.
1. Người dùng nghiệp vụ đầy đủ – Full User
Đây là nhóm cần trực tiếp thực hiện các nghiệp vụ cốt lõi trên ERP, chẳng hạn:
- Tạo, chỉnh sửa hoặc xác nhận báo giá và đơn hàng.
- Tạo yêu cầu mua, đơn mua hoặc phê duyệt mua hàng.
- Quản lý sản phẩm, tồn kho hoặc các giao dịch kho.
- Hạch toán, đối soát hoặc xử lý chứng từ kế toán.
- Quản lý sản xuất, dự án, dịch vụ hoặc quy trình liên phòng ban.
- Xem báo cáo điều hành với phạm vi dữ liệu rộng.
- Xử lý các trường hợp ngoại lệ ảnh hưởng đến giao dịch.
Tên gọi “Full User” trong checklist nhằm mô tả nhóm người dùng có nhu cầu nghiệp vụ đầy đủ. Phương án license thực tế phải được xác nhận theo gói dịch vụ và chính sách Odoo áp dụng.
2. Người dùng giới hạn – Light User
Đây là nhóm có tài khoản đăng nhập nhưng phạm vi sử dụng được giới hạn theo những trường hợp Odoo hỗ trợ.
Ví dụ khảo sát có thể gồm:
- Xem hoặc cập nhật thông tin cá nhân.
- Xem lịch và thực hiện tác vụ được giao trong phạm vi cho phép.
- Thực hiện thao tác giới hạn tại điểm bán.
- Truy cập nội dung Knowledge theo quyền được cấp.
- Thực hiện tác vụ Barcode giới hạn tại kho.
Không nên mặc định rằng mọi nhân viên kho, thu ngân hoặc nhân viên vận hành đều phù hợp với Light User. Một người chỉ quét mã sẽ khác với người được phép điều chỉnh tồn kho, tạo sản phẩm, xác nhận sai lệch hoặc quản lý toàn bộ hoạt động kho.
3. Hồ sơ nhân viên không đăng nhập
Đây là những nhân sự được lưu thông tin trong hệ thống để phục vụ quản lý tổ chức, hợp đồng, phòng ban hoặc các nghiệp vụ nhân sự liên quan nhưng không có nhu cầu tự đăng nhập.
Các giao dịch liên quan có thể được người phụ trách nhân sự hoặc quản lý thực hiện theo quy trình của doanh nghiệp.
Doanh nghiệp cần phân biệt rõ “có hồ sơ nhân viên” với “có tài khoản người dùng”. Hai khái niệm này không tự động giống nhau.
Checklist 10 câu hỏi phân loại người dùng
Hãy lập danh sách từng vai trò, không chỉ từng phòng ban, rồi trả lời lần lượt các câu hỏi sau.
STT | Câu hỏi cần xác nhận | Ý nghĩa phân loại |
1 | Người này có cần tự đăng nhập Odoo không? | Nếu không, có thể chỉ cần hồ sơ nhân viên. |
2 | Người này chỉ xem hay phải tạo và chỉnh sửa giao dịch? | Nhu cầu tạo/sửa nghiệp vụ thường cần quyền cao hơn. |
3 | Người này có xác nhận, phê duyệt hoặc hủy giao dịch không? | Quyền quyết định là yếu tố quan trọng, dù tần suất đăng nhập thấp. |
4 | Người này có xử lý ngoại lệ không? | Đổi trả, thiếu hàng, điều chỉnh tồn hoặc sai chứng từ có thể làm thay đổi nhóm quyền. |
5 | Người này được xem dữ liệu ở phạm vi nào? | Một cửa hàng, một kho, một công ty hay toàn hệ thống. |
6 | Công việc có thuộc phạm vi quyền giới hạn Odoo đang hỗ trợ không? | Cần đối chiếu tài liệu, cấu hình và môi trường thực tế. |
7 | Người này có dùng nhiều ứng dụng hoặc tham gia quy trình liên phòng ban không? | Nhu cầu xuyên ứng dụng thường không còn là một tác vụ giới hạn đơn lẻ. |
8 | Có cần truy vết chính xác ai thực hiện giao dịch không? | Nếu có, không nên dùng chung tài khoản. |
| 9 | Vai trò có thường xuyên thay đổi hoặc kiêm nhiệm không? | Cần thiết kế quy trình cập nhật quyền khi nhân sự thay đổi. |
| 10 | Tài khoản mẫu đã được kiểm thử bằng giao dịch thực tế chưa? | Chưa kiểm thử thì chưa nên chốt phương án license. |
Bảng quyết định nhanh
Tình huống | Nhóm khảo sát ban đầu | Việc cần làm trước khi chốt |
Không đăng nhập, chỉ cần lưu thông tin nhân sự | Hồ sơ nhân viên | Xác nhận không phát sinh nhu cầu tự thao tác. |
Có đăng nhập nhưng chỉ dùng một số tác vụ giới hạn | Ứng viên Light User | Đối chiếu đúng ứng dụng, quyền, phiên bản và hợp đồng. |
Tạo, sửa, xác nhận hoặc phê duyệt nghiệp vụ cốt lõi | Ứng viên Full User | Kiểm tra ứng dụng và phạm vi dữ liệu cần truy cập. |
Chỉ quét mã theo nhiệm vụ được giao | Có thể xem xét Light User | Kiểm thử Barcode; xác nhận không cần quản lý tồn kho hoặc dữ liệu nền. |
Quản lý kho, điều chỉnh tồn, xử lý chênh lệch | Thường cần quyền nghiệp vụ đầy đủ | Chạy thử các tình huống kiểm kê và ngoại lệ. |
Thu ngân thao tác POS theo phạm vi giới hạn | Có thể xem xét Light User | Kiểm thử bán hàng, đổi trả, hoàn tiền và đóng phiên. |
Quản lý cửa hàng phê duyệt đổi trả, xem báo cáo | Cần đánh giá như người dùng nghiệp vụ | Không phân loại chỉ dựa trên số lần đăng nhập. |
Kế toán lập, kiểm tra hoặc điều chỉnh chứng từ | Thường cần quyền nghiệp vụ đầy đủ | Kiểm tra phân quyền theo vai trò và phạm vi công ty. |
Các cụm từ “có thể xem xét” và “thường cần” được dùng có chủ đích. Checklist này giúp khoanh vùng để kiểm thử, không thay thế báo giá hoặc điều khoản cấp phép chính thức.
Năm lỗi thường gặp khi phân loại
Lỗi 1 — Dùng chức danh để quyết định license
Hai người cùng có chức danh “nhân viên kho” nhưng một người chỉ quét mã, người còn lại quản lý sản phẩm, điều chỉnh tồn và xác nhận kiểm kê. Nhu cầu quyền của họ không giống nhau.
Lỗi 2 — Cho rằng người ít đăng nhập chỉ cần quyền thấp
Giám đốc có thể chỉ đăng nhập vài lần mỗi tuần nhưng cần phê duyệt giao dịch quan trọng hoặc xem báo cáo của nhiều đơn vị.
Lỗi 3 — Dùng chung tài khoản cho nhiều nhân viên
Tài khoản dùng chung làm giảm khả năng truy vết, khó xác định trách nhiệm và tạo rủi ro khi nhân sự thay đổi.
Lỗi 4 — Chỉ kiểm thử quy trình bình thường
Quyền thường phát sinh vấn đề tại các trường hợp đổi trả, thiếu hàng, điều chỉnh giá, hủy chứng từ hoặc chênh lệch tồn kho.
Lỗi 5 — Chốt số lượng tài khoản quá sớm
Nếu quy trình và vai trò chưa được xác nhận, con số license ban đầu chỉ là ước tính. Doanh nghiệp nên ghi rõ giả định và cập nhật sau khảo sát, cấu hình mẫu hoặc UAT.
Cách sử dụng checklist trong dự án Odoo
NOS đề xuất thực hiện theo bốn bước:
Bước 1 — Liệt kê vai trò thực tế. Ghi rõ bộ phận, địa điểm, số lượng người và trường hợp kiêm nhiệm.
Bước 2 — Ghép vai trò với thao tác. Đánh dấu ai xem, tạo, sửa, xác nhận, phê duyệt và xử lý ngoại lệ trong từng quy trình.
Bước 3 — Tạo tài khoản đại diện để kiểm thử. Thử cả giao dịch bình thường và tình huống ngoại lệ. Kiểm tra người dùng có làm được việc và có nhìn thấy dữ liệu vượt phạm vi hay không.
Bước 4 — Đối chiếu chính sách cấp phép. Sau khi nhu cầu nghiệp vụ đã rõ, doanh nghiệp mới xác định phương án tài khoản và yêu cầu báo giá chính thức.
Kết quả nên được lưu thành ma trận gồm:
Vai trò → Thao tác → Ứng dụng → Phạm vi dữ liệu → Ngoại lệ → Nhóm người dùng dự kiến → Kết quả kiểm thử
Phân loại đúng để quản trị tốt hơn, không chỉ để tính chi phí
Mục tiêu của việc phân loại không đơn thuần là giảm số lượng license.
Một ma trận người dùng được xây dựng đúng còn giúp doanh nghiệp:
- Phân định rõ trách nhiệm trong từng quy trình.
- Kiểm soát dữ liệu theo cửa hàng, kho, công ty hoặc bộ phận.
- Truy vết người thực hiện giao dịch.
- Đào tạo đúng nội dung cho từng nhóm.
- Cấp, thay đổi và thu hồi quyền khi nhân sự biến động.
- Kiểm thử phân quyền trước khi vận hành chính thức.
Nếu doanh nghiệp đang chuẩn bị triển khai hoặc nâng cấp Odoo, NOS có thể hỗ trợ khảo sát quy trình, lập ma trận vai trò và kiểm thử quyền trước khi chốt phương án người dùng.