Kiểm soát nội bộ kho ecommerce: phân quyền, tách nhiệm và nhật ký điều chỉnh tồn trên OMS + WMS

1. Khoảng trống: danh sách vai trò không phải là kiểm soát nội bộ

Khi tìm cách chọn phần mềm quản lý kho, các trang xếp hạng và so sánh thường liệt kê tính năng: theo dõi nhập xuất tồn, mã vạch, nhiều kho, cảnh báo hết hàng, phân quyền người dùng. Dòng “phân quyền” xuất hiện như một ô tích trong bảng tính năng. Điều đó đúng ở mức mô tả, nhưng chưa giúp chủ shop trả lời ba câu hỏi vận hành: nhân viên nào được sửa tồn, sửa xong thì ai biết, và khi tồn lệch thì lần ra nguyên nhân bằng cách nào.

Đối chiếu công khai ngày 20/10/2026 (kết quả tìm kiếm và trang xếp hạng phần mềm quản lý kho tại Việt Nam) cho thấy phần lớn nội dung dừng ở mức liệt kê chức năng. Bài này không kết luận đối thủ thiếu tính năng phân quyền hay nhật ký; mục tiêu là điền phần mà người mua thường phải tự suy luận: thiết kế quyền, mức duyệt, nhật ký và nghiệm thu cho một kho ecommerce chạy đa sàn.

Với shop đang đi từ Excel sang hệ thống, nên đọc thêm khi nào bỏ Excel để chuyển sang OMS hoặc OMS + WMS. Với shop đã có hệ thống nhưng tồn vẫn lệch, bài độ chính xác tồn kho và cycle count giúp đo mức lệch; bài này giải quyết phần còn lại: ai được thay đổi sổ và bằng chứng nào được giữ.

Lưu ý về phạm vi: bài nói về kiểm soát vận hành kho và dữ liệu đơn, tồn. Quy định kế toán, thuế, lao động hay bảo vệ dữ liệu cá nhân có yêu cầu riêng; hãy hỏi chuyên gia phù hợp khi cần, đừng coi bảng ví dụ ở đây là tư vấn pháp lý.

2. Trả lời trước: ba nhóm quyền cần tách và một nguyên tắc

Gọn nhất là chia mọi thao tác trong OMS + WMS thành ba nhóm. Nhóm G (ghi nhận hàng thật): nhận hàng, putaway, picking, checking, packing, bàn giao, kiểm đếm. Nhóm S (sửa dữ liệu): điều chỉnh tồn, đổi trạng thái đơn, đổi mapping SKU, sửa vị trí, hủy giữ tồn. Nhóm D (duyệt và mở): duyệt điều chỉnh, mở khu khóa, cho phép bán lại hàng cách ly, chốt kiểm kê.

Nguyên tắc: trên cùng một SKU và cùng một sự kiện, một người không đồng thời giữ cả nhóm S và nhóm D, và hạn chế giữ cả G lẫn D. Người đếm hàng không nên là người duyệt số mình đếm. Người sửa mapping không nên là người xác nhận đơn đã được ghép đúng. Đây là nguyên tắc tách nhiệm cơ bản, áp dụng được cả khi shop chỉ có sáu đến mười người trong kho; khi không đủ người, dùng chủ shop hoặc quản lý ca làm người duyệt thay vì cho cùng một nhân viên tự duyệt.

Nguyên tắc thứ hai: quyền gắn với vai trò và phạm vi, không gắn với người. Khi nhân viên nghỉ hoặc đổi ca, thu hồi bằng cách đổi vai trò, không chia sẻ tài khoản. Tài khoản dùng chung cho cả ca là nguồn gốc của nhật ký vô nghĩa: hệ thống ghi “kho01 đã sửa” nhưng không ai biết người đó là ai.

3. Định lượng: chi phí của một lần sửa tồn không kiểm soát

Muốn quyết định đầu tư vào kiểm soát, cần quy đổi rủi ro ra tiền. Gọi n là số điều chỉnh tồn trong tháng, p là tỷ lệ điều chỉnh sai hoặc không có căn cứ, v là giá vốn trung bình mỗi đơn vị bị lệch, q là số đơn vị lệch trung bình mỗi lần, và m là giờ công điều tra mỗi lần. Chi phí tháng ước tính E = n × p × (q × v + m × giá một giờ công).

Ví dụ giả định: 120 điều chỉnh mỗi tháng, 6% sai hoặc thiếu căn cứ, mỗi lần lệch 4 đơn vị giá vốn 150.000 đồng, điều tra mất 1,5 giờ với giờ công quy đổi 60.000 đồng. Khi đó E = 120 × 0,06 × (4 × 150.000 + 1,5 × 60.000) = 7,2 × 690.000, xấp xỉ 4,97 triệu đồng mỗi tháng. Đó chưa tính đơn bị hủy do oversell hay phạt chậm giao, chỉ mới tính giá trị hàng lệch và công điều tra.

Công thức có giới hạn. Nếu shop chưa lưu lý do điều chỉnh, p không đo được; khi đó bước đầu tiên không phải mua thêm quyền mà là bắt buộc nhập lý do và chứng từ. Nếu vài SKU chiếm phần lớn giá trị, nên tính E riêng cho nhóm đó thay vì dùng giá trị trung bình toàn kho, vì ngưỡng duyệt hợp lý cho khăn giấy khác với điện thoại hay mỹ phẩm cao cấp.

Đừng đưa con số E vào báo cáo như kết quả của JST ERP hay của một khách hàng nếu chưa đo. Đây là cách để đội mua tự lập luận chi phí chứ không phải mức tiết kiệm được cam kết.

4. Bản đồ vai trò cho kho ecommerce 6–30 người

Không cần hàng chục vai trò. Với phần lớn shop đa sàn, tám vai trò là đủ để bắt đầu và tách nhiệm có ý nghĩa. Mỗi vai trò cần mô tả bằng thao tác được phép, phạm vi dữ liệu và thao tác bị cấm, thay vì chỉ ghi tên chức danh.

Hai vai trò hay bị bỏ sót là nhân viên dữ liệu SKU và người đọc nhật ký độc lập. Mapping SKU sai gây oversell rất âm thầm, nên quyền sửa mapping nên tách khỏi quyền sửa số tồn; xem thêm chuẩn hóa master data SKU, barcode và mapping. Còn người đọc nhật ký độc lập là người không tham gia thao tác hằng ngày, thường là chủ shop hoặc người quản lý khác bộ phận, để việc rà soát không biến thành tự chấm điểm.

Đừng cấp quyền “xem tất cả” cho mọi người. Quyền xem cũng là rủi ro: giá vốn, thông tin khách, danh sách đơn giá trị lớn và vị trí hàng đắt tiền không cần nằm trên màn hình của nhân viên picking. Nguyên tắc tối thiểu cần thiết giúp giảm cả rủi ro dữ liệu cá nhân lẫn thất thoát; chi tiết về dữ liệu cá nhân nên được rà cùng người phụ trách pháp lý của doanh nghiệp.

5. Mức duyệt điều chỉnh tồn theo giá trị và rủi ro

Một ngưỡng duyệt chung cho mọi SKU luôn sai: quá thấp thì quản lý bị ngập, quá cao thì SKU đắt bị bỏ lọt. Hãy tính mức duyệt theo giá trị chênh G = |q| × giá vốn và theo lớp rủi ro của SKU. Bốn mức dưới đây là ví dụ thiết kế, cần hiệu chỉnh theo biên lợi nhuận và tần suất của shop.

Bắt đầu bằng L0 hậu kiểm thay vì chặn. Nếu bắt mọi điều chỉnh nhỏ đều qua duyệt, đội sẽ lách bằng cách gộp nhiều lần sửa nhỏ để dưới ngưỡng. Vì vậy cần thêm quy tắc cộng dồn: tổng giá trị điều chỉnh âm trên cùng SKU trong 7 ngày vượt ngưỡng L1 thì lần kế tiếp tự động nâng mức. Đây là điểm cần hỏi khi demo: hệ thống có cấu hình được ngưỡng cộng dồn không, hay phải làm báo cáo thủ công.

Điều chỉnh dương (tìm thấy hàng) cũng cần duyệt. Thêm tồn mà không có phiếu nhận hay phiếu chuyển là cách phổ biến để che việc đã xuất hàng ngoài luồng, và nó trực tiếp làm tăng tồn công bố lên sàn, dẫn đến oversell. Xem thêm xử lý hàng thất lạc sai vị trí để phân biệt hàng đang nằm sai chỗ với hàng thật sự thừa.

6. Nhật ký thao tác: sáu trường tối thiểu và ba cách xem

Nhật ký chỉ hữu ích khi truy được. Mỗi bản ghi biến động tồn hoặc đổi trạng thái nên có tối thiểu: (1) người thực hiện bằng tài khoản cá nhân, (2) thời điểm hệ thống ghi, (3) đối tượng: SKU, vị trí, kho, mã đơn, (4) giá trị trước và sau, (5) lý do chọn từ danh mục kèm mã chứng từ gốc, (6) người đề xuất, người duyệt và thời điểm duyệt.

Ba cách xem cần có. Theo SKU: toàn bộ lịch sử một mã để trả lời “tồn của mã này đã lệch vì đâu”. Theo vị trí hoặc ca: để thấy một khu hay một ca có tỷ lệ điều chỉnh cao bất thường. Theo người: để phát hiện một tài khoản đề xuất quá nhiều điều chỉnh, hay duyệt gần như tất cả đề xuất của một người khác. Nếu hệ thống chỉ cho xuất cả bảng, việc phân tích rơi lại Excel và người xem thường bỏ qua.

Danh mục lý do nên ngắn (8–12 mục) và có nghĩa thao tác: đếm lại phát hiện lệch, hàng hỏng, hàng mất đã lập biên bản, nhận thiếu so với phiếu, chuyển kho chưa xác nhận, sửa vị trí, hàng hoàn không đạt QC. Mục “khác” cần ghi chú bắt buộc và hiển thị riêng trong báo cáo hằng tuần, vì nó thường là nơi che giấu điều chỉnh không có căn cứ.

Nhật ký cũng phải chống sửa: người có quyền nghiệp vụ không có quyền xóa bản ghi nhật ký. Nếu có sửa, hệ thống ghi thêm bản ghi mới thay vì ghi đè. Câu hỏi cần đặt cho nhà cung cấp là nhật ký lưu bao lâu, ai xuất được, và việc xuất có tự được ghi lại không.

7. Kiểm kê và khóa vị trí: thời điểm dễ gian lận nhất

Trong lúc kiểm kê, nhiều shop mở quyền sửa tồn rộng để xử lý nhanh, rồi quên thu hồi. Đây là cửa sổ rủi ro cao vì cùng một người đếm, nhập số đếm và sửa tồn. Quy trình nên chia phiên kiểm kê thành ba bước với ba người hoặc ba vai trò: người đếm lần một, người đếm lần hai độc lập (không thấy số lần một), và người duyệt chênh lệch. Số đếm lần hai chỉ hiện khi lần một đã khóa.

Vị trí đang kiểm kê phải khóa với giao dịch phụ: không picking, không putaway, không chuyển trong khi đếm; nếu đơn gấp cần lấy hàng, ghi nhận ngoại lệ bằng phiếu riêng. Bài khóa vị trí khi kiểm kê cycle count mô tả cách tránh tồn nhảy giữa chừng. Từ góc nhìn kiểm soát, khóa vị trí cũng là cách bảo vệ người đếm khỏi bị nghi oan khi có giao dịch ngoài luồng.

Nếu hai lần đếm khác nhau vượt dung sai, đếm lần ba bởi người thứ ba rồi mới đề xuất điều chỉnh. Dung sai ví dụ: 0 đơn vị với SKU giá trị cao, 1 đơn vị hoặc 2% (lấy số lớn hơn) với SKU thông thường. Con số này cần chỉnh theo thực tế; điều quan trọng là cố định trước khi đếm, không thỏa thuận sau khi đã thấy chênh lệch.

8. Đơn hàng: ai được hủy, đổi nguồn xuất, đổi địa chỉ, đổi trạng thái

Không chỉ tồn kho cần kiểm soát. Một số thao tác trên đơn tác động trực tiếp tới hàng: hủy đơn đã picking, đổi nguồn xuất, thay SKU thay thế, gộp hoặc tách đơn, đổi địa chỉ sau khi in vận đơn. Mỗi thao tác nên có quyền riêng, điều kiện trạng thái rõ và nhật ký đầy đủ. Ví dụ, đổi địa chỉ sau khi vận đơn đã tạo không nên thuộc quyền của nhân viên đóng gói; nó nên đi qua điều phối đơn vì liên quan phí vận chuyển và đối soát COD.

Liên quan trực tiếp tới tồn là các thao tác giải phóng giữ tồn. Nếu ai cũng có quyền bấm hủy giữ, tồn công bố có thể tăng nhầm và gây oversell, nhất là khi đơn đã lấy hàng ra khỏi kệ. Tham khảo thêm xử lý đơn hủy sau khi đã picking và putback, đổi nguồn xuất hàng đã giữ tồn và giải phóng tồn giữ treo.

9. Hàng hoàn, hàng lỗi, cách ly và hủy: nơi thất thoát nằm im

Hàng hoàn, hàng lỗi và khu cách ly là các trạng thái “không bán được” nhưng vẫn có giá vốn. Hàng chuyển trạng thái từ không bán được sang bán được là điểm tăng tồn khả dụng, nên phải có người duyệt độc lập với người nhận hoặc QC. Ngược lại, chuyển từ bán được sang hủy cần chứng từ, vì đó là cách hợp thức hóa việc mất hàng.

Quy tắc kiểm soát gọn: mọi chuyển trạng thái tăng tồn khả dụng cần hai dấu vết (người kiểm, người duyệt) với SKU lớp cao; mọi chuyển trạng thái hủy hoặc thanh lý cần biên bản có người thứ ba chứng kiến và, nếu giá trị lớn, ảnh hoặc video. Với hàng gắn serial hoặc lô, phải lưu serial/lô trong chính bản ghi chuyển trạng thái, tham khảo quản lý lô và hạn sử dụng FEFO và phát hiện hàng hoàn bị đánh tráo.

10. Tài khoản, PDA và thiết bị: nơi tách nhiệm bị phá vỡ

Nhiều kiểm soát thất bại vì thiết bị. Một chiếc PDA đăng nhập sẵn tài khoản trưởng ca và để trong kho sẽ phá hỏng mọi bảng quyền. Quy tắc đơn giản: mỗi người dùng tài khoản riêng, đăng nhập đầu ca, tự đăng xuất hoặc khóa sau một khoảng không hoạt động ngắn, không dùng tài khoản của người khác kể cả “cho nhanh”. Nếu PDA dùng chung theo ca, ghi nhận ai nhận thiết bị, giờ nhận, giờ trả.

Mật khẩu và quyền cần có vòng đời. Khi nhân viên nghỉ, vô hiệu hóa tài khoản trong cùng ngày. Khi chuyển vị trí làm việc, đổi vai trò thay vì cộng thêm quyền mới lên quyền cũ. Rà soát danh sách tài khoản mỗi quý: tài khoản không hoạt động quá 30 ngày cần được xác nhận hoặc khóa. Với mùa sale, nhân sự thời vụ chỉ nên có vai trò G, thời hạn quyền gắn với đợt làm việc; xem thêm đào tạo nhân viên kho thời vụ.

Về PDA mất mạng và gửi lại, một thao tác đồng bộ trễ không được tạo ra biến động trùng; thảo luận chi tiết có ở xử lý PDA mất mạng trong kho và PDA picking, checking, packing.

11. Tích hợp sàn và API: tài khoản máy cũng cần phân quyền

Kết nối với Shopee, Lazada, TikTok Shop thường dùng quyền ủy quyền do người quản trị gian hàng cấp. Rủi ro là một người giữ toàn bộ khóa kết nối, hoặc khóa kết nối nằm trong tài khoản cá nhân của nhân viên đã nghỉ. Hãy đặt quy tắc: người được ủy quyền kết nối là vai trò quản trị có tên trong danh sách; khi người đó nghỉ, quy trình thu hồi và cấp lại phải có người thay thế đã chỉ định.

Với tích hợp tự xây hoặc API, ghi rõ tài khoản máy nào có quyền gì: chỉ đọc đơn, ghi tồn, ghi trạng thái giao. Tài khoản máy không nên có quyền sửa tồn gốc ngoài kênh đẩy đã khai báo. Khi có sự cố đồng bộ, tài khoản máy cũng phải xuất hiện trong nhật ký với danh tính riêng để phân biệt thay đổi do người và do hệ thống; kịch bản xử lý có trong phục hồi sự cố đồng bộ đơn và tồn kho.

Các giới hạn như thời gian token, phạm vi quyền hay cách thu hồi khác nhau theo từng sàn và thay đổi theo thời gian. Bài không nêu chi tiết chính sách của sàn; hãy kiểm tra tài liệu dành cho người bán hiện hành và xác nhận với nhà cung cấp phần mềm.

12. OMS-only hay OMS + WMS: kiểm soát nội bộ đổi quyết định thế nào

OMS xử lý đơn, giữ tồn, đồng bộ kênh và chứng từ cấp đơn. WMS thêm lớp vị trí, tác vụ lấy hàng, xác nhận quét và nhật ký vật lý. Về kiểm soát, khác biệt nằm ở độ chi tiết của bằng chứng: OMS-only cho biết đơn nào đã đóng và tồn tổng thay đổi bao nhiêu, còn WMS cho biết ai quét SKU nào tại vị trí nào, lúc nào.

Các ngưỡng 5 và 8–10 người là điểm tham chiếu để thảo luận, không phải quy tắc cứng; một shop bán hàng giá trị cao có thể cần WMS sớm hơn nhiều. Quyết định đúng hơn là so sánh chi phí lệch tồn (mục 3) với chi phí triển khai và vận hành WMS; xem thêm chi phí và ROI WMS cho ecommerce Việt Nam và khi nào chuyển từ OMS sang OMS + WMS.

13. Những câu trả lời dễ gây hiểu sai

“Có phân quyền rồi nên an toàn.” Phân quyền chỉ ngăn thao tác ngoài vai trò. Nếu một vai trò vừa đề xuất vừa duyệt, hoặc ai cũng dùng chung tài khoản quản lý, phân quyền không còn tác dụng. Hãy hỏi: vai trò nào ghi và vai trò nào duyệt cùng một biến động.

“Có nhật ký là truy được.” Nhật ký không có lý do, chứng từ gốc hoặc người duyệt chỉ cho biết có thay đổi, không cho biết thay đổi có đúng không. Nhật ký xuất được nhưng không lọc được theo SKU hay ca sẽ không được dùng thực tế.

“Tin nhân viên lâu năm thì khỏi duyệt.” Tách nhiệm không phải là nghi ngờ cá nhân; nó bảo vệ cả người làm khỏi bị nghi oan khi có lệch. Hãy trình bày như một quy tắc áp dụng cho mọi người, kể cả quản lý.

“Chặn nhiều là tốt.” Kiểm soát quá nặng khiến đội lách bằng sửa ngoài hệ thống hoặc ghi chú ngoài luồng. Nhắm vào điểm rủi ro lớn (điều chỉnh âm, mở trạng thái bán, hàng giá trị cao) và để phần còn lại hậu kiểm.

“Thêm WMS là tự có tách nhiệm.” WMS cung cấp công cụ, nhưng bảng quyền, mức duyệt và quy trình thu hồi vẫn do shop thiết kế và vận hành. Triển khai không có phần này vẫn có thể ghi nhật ký đầy đủ nhưng không ai đọc.

14. Kịch bản minh họa: kho 14 người, ba sàn, một tuần cao điểm

Ví dụ giả định để thử logic, không phải khách hàng thật. Một shop có 14 người trong kho chia hai ca, bán trên ba sàn, 2.500 đơn mỗi ngày vào cao điểm, 1.800 SKU trong đó 60 SKU thuộc lớp cao (giá vốn trên 800.000 đồng mỗi đơn vị). Trước cao điểm, nhật ký cho thấy 9 tài khoản có quyền sửa tồn, trong đó 3 tài khoản dùng chung cho ca.

Giả sử trong tuần đầu có 70 điều chỉnh, trong đó 8 mục chọn “khác”. Con số 8 trên 70 (khoảng 11%) là tín hiệu để xem lại danh mục lý do, vì nếu tỷ lệ “khác” còn cao thì nhật ký chưa phân tích được. Nếu 5 trong 8 điều chỉnh đó cùng một ca và một khu, đó là câu hỏi điều tra, chưa phải kết luận về một cá nhân. Điều tra theo chuỗi bằng chứng: phiếu đếm, vị trí, giao dịch quét liên quan và ảnh, rồi mới trao đổi với người liên quan.

Việc giảm số người có quyền S cũng có chi phí: tổ trưởng cũ có thể phàn nàn chậm. Cần đo thời gian chờ duyệt trung bình và đặt mục tiêu phản hồi trong ca, ví dụ L1 trong 30 phút trong giờ làm việc. Nếu duyệt chậm gây nghẽn picking, giải pháp là thêm người duyệt dự phòng hoặc điều chỉnh ngưỡng L0, không phải bỏ tách nhiệm.

15. Checklist năm việc đội mua có thể làm trong hai tuần

1. Lập bản đồ G/S/D hiện tại. Liệt kê 15–20 thao tác kho và đơn quan trọng, ghi vai trò đang làm được. Đánh dấu chỗ một người giữ cả S và D hoặc tài khoản dùng chung.
2. Lấy mẫu 30 điều chỉnh gần nhất. Đối chiếu chứng từ gốc và lý do; đo p (tỷ lệ thiếu căn cứ) và tính E bằng công thức ở mục 3.
3. Đặt bốn mức duyệt L0–L3. Chọn ngưỡng theo giá vốn thực tế, thêm quy tắc cộng dồn 7 ngày, phân nhóm SKU lớp thấp, trung và cao.
4. Yêu cầu demo sáu ca kiểm soát. Điều chỉnh tự duyệt bị chặn, điều chỉnh hai mức, kiểm kê hai lần độc lập, khóa vị trí, truy nhật ký theo SKU và thu hồi quyền người nghỉ. Lưu kết quả, không chỉ nghe giải thích.
5. Chốt nhịp rà soát. Hằng tuần xem điều chỉnh “khác” và điều chỉnh âm theo ca; hằng quý rà tài khoản và quyền. Gán người đọc nhật ký độc lập.

Checklist này dành cho quá trình chọn và triển khai, không phải danh sách tác vụ tự động chạy trên hệ thống đang bán. Mọi thay đổi vai trò hay ngưỡng nên thử trên nhóm nhỏ, ghi lại và có đường lui. Khi cần trao đổi theo dữ liệu của shop, xem sản phẩm OMS + WMS, giải pháp vận hành kho và quản lý đa kênh marketplace.

16. Bộ ca nghiệm thu kiểm soát nội bộ

Khi demo hoặc pilot, tạo dữ liệu thử trong môi trường được phép. Mỗi ca cần đầu vào, kết quả mong đợi và bằng chứng lưu lại.

Không coi một ca đạt là đủ. Nếu hệ thống chỉ chặn ở giao diện nhưng API hoặc import vẫn cho sửa, đó là điểm hở. Hãy hỏi thao tác qua import hàng loạt, qua API và qua thiết bị cầm tay có cùng kiểm soát không.

17. Những điểm cần dữ liệu thật và giới hạn nghiên cứu

Bài này không có số liệu khách hàng. Các phần cần số liệu của shop, nên đo trước khi ra quyết định: tần suất và tỷ lệ điều chỉnh thiếu căn cứ (mục 3), ngưỡng giá vốn cho L0–L3, tỷ lệ chênh khi đếm hai lần độc lập, thời gian duyệt trung bình và số ngoại lệ “khác” mỗi tuần. Không dùng con số trong bài như kết quả của một khách hàng hay của sản phẩm.

Nghiên cứu gồm kết quả tìm kiếm công khai và nội dung bài viết hiện có trên chính trang này, ngày rà soát 20/10/2026. Không truy cập nhóm Facebook riêng hay dữ liệu Search Console. Khả năng cụ thể của JST ERP (cấu hình vai trò, ngưỡng cộng dồn, nhật ký theo SKU, khóa vị trí) phải được xác nhận trong buổi tư vấn theo phiên bản; xem thêm câu hỏi thường gặp và cam kết và quy trình hỗ trợ. Liên hệ để rà soát bản đồ quyền kho của bạn.