Một doanh nghiệp bán lẻ có 200 nhân sự đang chuẩn bị triển khai ERP. Ban lãnh đạo hỏi: “Chúng ta cần mua bao nhiêu tài khoản?”
Nếu trả lời ngay bằng con số 200, nhóm dự án có thể đang tính cả những người chỉ được lưu hồ sơ nhân sự và không đăng nhập. Nhưng nếu chỉ tính nhân viên văn phòng, họ có thể bỏ sót thu ngân, nhân viên kho hoặc người quản lý phải xử lý giao dịch trên hệ thống. Số nhân sự không tự động bằng số tài khoản ERP cần dùng.
Ở bài trước về Odoo 20 và Light User, NOS đã đề xuất phân loại theo công việc thực tế. Bài này đi thêm một bước: dùng một doanh nghiệp giả định 200 nhân sự để chỉ ra cách lập danh sách người dùng có thể kiểm chứng, trước khi đối chiếu điều kiện cấp phép và ngân sách.
Bắt đầu từ một ngày vận hành, không bắt đầu từ bảng nhân sự
Giả sử doanh nghiệp có nhiều cửa hàng, một kho trung tâm và văn phòng điều hành. Một đơn bán hàng có thể đi qua thu ngân, kho, bộ phận chăm sóc khách hàng và kế toán. Nếu thiếu hàng, nhân viên mua hàng cần làm việc với nhà cung cấp; nếu phát sinh đổi trả, quản lý cửa hàng hoặc người có thẩm quyền phải xử lý ngoại lệ.
Với mỗi bước, nhóm khảo sát nên hỏi bốn câu:
1. Ai thực hiện thao tác trên hệ thống? Người này có tự đăng nhập hay chỉ nhận thông tin từ người khác?
2. Họ làm gì? Xem, quét mã, tạo, sửa, xác nhận, phê duyệt hay báo cáo?
3. Họ được thấy dữ liệu nào? Một cửa hàng, một kho, một công ty hay toàn doanh nghiệp?
4. Ai xử lý khi quy trình lệch chuẩn? Thiếu hàng, sai lệch tồn, trả hàng hoặc điều chỉnh giá là những tình huống dễ làm thay đổi nhu cầu quyền.
Một danh sách chức danh như “thu ngân”, “nhân viên kho” hay “quản lý” chưa trả lời đủ bốn câu hỏi này.
Ma trận khảo sát cho doanh nghiệp 200 nhân sự
Ví dụ dưới đây là giả định minh họa, không đại diện cho cơ cấu nhân sự, số lượng license hay dự án khách hàng cụ thể của NOS.
Nhóm công việc | Thao tác cần xác nhận | Tình huống phải kiểm thử |
Bán hàng và mua hàng | ạo đơn, sửa nội dung, theo dõi giao hàng, tạo yêu cầu mua hoặc phê duyệt | Đổi giá, thiếu hàng, hủy đơn, mua bổ sung |
Quản lý cửa hàng và kho | Kiểm tra giao dịch, duyệt ngoại lệ, điều phối hàng và xem báo cáo đúng phạm vi | Trả hàng, chênh lệch kiểm kê, chuyển kho |
Thu ngân | Thao tác trong phiên POS theo vai trò được giao | Hoàn tiền, đổi trả, đóng phiên và xử lý sai lệch quỹ |
Nhân viên kho | Nhận nhiệm vụ và quét mã trong bước nhận, chuyển hoặc xuất hàng | Hàng thiếu, hàng hỏng, mã không khớp, điều chỉnh tồn |
Kế toán | Đối soát giao dịch, lập và kiểm tra chứng từ, theo dõi công nợ | Sai thông tin hóa đơn, hủy chứng từ, xử lý kỳ đã khóa |
Nhân viên chỉ dùng tác vụ cá nhân | Xem thông tin cá nhân, chấm công, xin nghỉ hoặc xem lịch | Thay đổi ca, người duyệt vắng mặt |
Nhân sự chỉ cần lưu hồ sơ | Không đăng nhập ERP | Cần xác nhận có phát sinh nhu cầu tự thao tác về sau không |
Ma trận này cho biết điều cần khảo sát, chưa phải bảng phân loại Full User, Light User hoặc hồ sơ không đăng nhập. Ví dụ, một nhân viên kho chỉ quét mã có thể khác đáng kể với người được giao điều chỉnh tồn hoặc tạo sản phẩm. Mọi phương án Light User cần kiểm tra theo phạm vi Odoo công bố, cấu hình thực tế và điều kiện hợp đồng áp dụng.
Đừng bỏ qua người làm việc ít nhưng nắm bước quyết định
Một giám đốc chỉ đăng nhập vài lần mỗi tuần vẫn có thể cần xem báo cáo nhiều công ty hoặc phê duyệt đơn mua. Ngược lại, một nhân viên hiện diện mỗi ngày tại cửa hàng có thể chỉ thực hiện một thao tác giới hạn. Tần suất đăng nhập không đủ để quyết định loại quyền.
Điểm dễ bỏ sót thứ hai là tài khoản “dùng chung”. Khi nhiều người cùng đăng nhập một tài khoản, nhóm dự án sẽ khó xác định ai đã thực hiện giao dịch và ai chịu trách nhiệm khi có sai lệch. Vì thế, cần ghi nhận người thực hiện và quyền của từng vai trò trong quy trình, rồi xác nhận cách cấp tài khoản phù hợp với chính sách và yêu cầu truy vết của doanh nghiệp.
Điểm thứ ba là sự thay đổi công việc sau khi vận hành. Một thu ngân có thể được bổ nhiệm làm quản lý cửa hàng; một nhân viên kho chuyển sang xử lý kiểm kê. Ma trận người dùng cần có người phụ trách cập nhật khi nhân sự đổi vai trò, chứ không chỉ được lập một lần để tính ngân sách ban đầu.
Từ 200 nhân sự đến phương án tài khoản có thể kiểm chứng
NOS đề xuất thực hiện theo năm bước:
Bước 1 — Lập danh sách vai trò. Ghi bộ phận, địa điểm, số người, người phụ trách và công việc đang thực hiện. Đánh dấu các vị trí có nhiều vai trò cùng lúc.
Bước 2 — Ghép vai trò với từng bước quy trình. Với luồng bán hàng, mua hàng, kho, kế toán và nhân sự, xác định ai xem, ai thao tác và ai phê duyệt. Làm rõ quyền khi có ngoại lệ.
Bước 3 — Kiểm tra phạm vi dữ liệu. Một cửa hàng có được xem tồn kho của cửa hàng khác không? Người quản lý có được duyệt giao dịch ở công ty khác không? Đây là câu hỏi về kiểm soát dữ liệu bên cạnh câu hỏi về license.
Bước 4 — Dùng tài khoản đại diện để chạy thử. Kiểm thử giao dịch thông thường và ít nhất một tình huống ngoại lệ cho mỗi nhóm vai trò. Nếu tài khoản không làm được việc hoặc thấy nhiều dữ liệu hơn mức cần thiết, chỉnh ma trận và thử lại.
Bước 5 — Đối chiếu điều kiện cấp phép và lập ngân sách. Chỉ sau khi các thao tác đã được xác nhận, mới xác định nhóm nào cần tài khoản nghiệp vụ, nhóm nào có thể đáp ứng bằng quyền giới hạn theo Odoo, và nhóm nào chỉ cần lưu hồ sơ không đăng nhập. Đối chiếu báo giá tại thời điểm quyết định, cùng chi phí triển khai, tích hợp, đào tạo và hỗ trợ.
Kết quả của quá trình này không chỉ là một số lượng tài khoản. Doanh nghiệp còn có một ma trận vai trò và quyền để dùng cho cấu hình, đào tạo, kiểm thử trước khi vận hành và quản lý thay đổi nhân sự về sau.
Quyết định tốt cần dữ liệu tốt
Với doanh nghiệp 200 nhân sự, mục tiêu không phải gán cho mỗi người một nhãn license càng sớm càng tốt. Mục tiêu là làm rõ ai chịu trách nhiệm tại từng bước và quyền nào đủ để họ hoàn thành công việc, kể cả khi phát sinh ngoại lệ.
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 quy trình và lập ma trận vai trò trước khi chốt phương án tài khoản.
Nguồn tham khảo: Odoo Pricing; Odoo 20 Release Notes; Odoo Access Rights. Các nhận định về quyền Light User cần xác nhận trên phiên bản, cấu hình và hợp đồng áp dụng; ví dụ 200 nhân sự là giả định minh họa.