Kết luận nhanh: thất thoát là vấn đề quyền và bằng chứng, không phải vấn đề đếm
Phần lớn kho ecommerce Việt Nam đã có đủ công cụ để phát hiện lệch tồn. Cái thiếu là hợp đồng kiểm soát quanh thao tác sửa số: ai được sửa, sửa vì lý do gì, bằng chứng nào phải tồn tại trước khi sửa, ai duyệt ở mức giá trị nào, và sau đó ai đọc báo cáo tổng hợp. Khi thiếu hợp đồng này, mỗi lần kiểm kê sẽ kết thúc bằng một thao tác đưa hệ thống về khớp thực tế — và toàn bộ thông tin về nguyên nhân biến mất cùng lúc.
Hệ quả rất cụ thể. Doanh nghiệp không biết mình mất hàng ở cửa nhận, ở bàn đóng gói, ở khâu bàn giao hay ở hàng hoàn. Không biết thì không sửa được cơ chế, nên tháng sau tiếp tục mất và tiếp tục điều chỉnh. Đó là lý do một kho có thể vừa báo cáo tồn kho chính xác vừa lỗ đều đặn vì hao hụt.
- Định lượng: quy thất thoát ra tiền theo một công thức và một mẫu số cố định.
- Phân loại: mọi thay đổi số lượng phải mang reason code trong danh mục đóng.
- Phân quyền: tách người phát hiện, người duyệt và người hạch toán.
- Bằng chứng: gắn ảnh, log scan, biên bản hoặc chứng từ vào từng điều chỉnh.
- Thu hồi: đưa phần tổn thất của carrier, 3PL và sàn vào quy trình khiếu nại có hạn.
Tóm tắt nhanh
Thất thoát tồn kho (shrinkage) là phần chênh lệch giữa lượng hàng đáng lẽ còn theo sổ sách và lượng hàng thực tế có thể bán, sau khi đã loại trừ các sai lệch do dữ liệu và chứng từ. Nó gồm nhiều nhóm nguyên nhân khác nhau về bản chất: hao hụt vật lý, hư hỏng, hết hạn, mất trong vận chuyển, mất do quy trình lỏng và mất do hành vi cố ý. Trộn chung sáu nhóm này vào một con số khiến mọi giải pháp đều trở thành khẩu hiệu.
Bốn việc tạo ra khác biệt lớn nhất, theo thứ tự chi phí triển khai từ thấp đến cao: đóng danh mục reason code và bắt buộc chọn khi điều chỉnh; tách quyền tạo và quyền duyệt kèm ngưỡng giá trị; ghi nhận bằng chứng tại điểm phát sinh thay vì tại thời điểm kiểm kê; và đo thất thoát theo tiền, theo nguyên nhân, theo ca và theo vị trí thay vì chỉ theo số lượng toàn kho.
Bài viết này bổ sung cho pillar về độ chính xác tồn kho và cycle count. Bài kia trả lời câu hỏi “số liệu có đúng không và đếm thế nào”. Bài này trả lời câu hỏi khác: “hàng và tiền đang rơi ở đâu, ai được phép thay đổi số, và làm sao đòi lại phần đáng được bồi thường”.
Thông tin thực thể liên quan
Tranh luận về thất thoát thường bế tắc vì sáu khái niệm khác nhau bị gọi chung là “lệch tồn”. Tách rõ chúng là điều kiện để phân công trách nhiệm.
| Khái niệm | Bản chất | Đo bằng gì | Ai chịu trách nhiệm chính |
|---|---|---|---|
| Chênh lệch kiểm kê (count variance) | Khác biệt giữa số đếm và số hệ thống tại một thời điểm | Số lượng theo SKU và vị trí | Quản lý kho |
| Thất thoát (shrinkage) | Phần chênh lệch đã xác nhận là mất hàng thật, không phải lỗi dữ liệu | Giá trị theo giá vốn | Vận hành và tài chính |
| Hư hỏng (damage) | Hàng còn nhưng không bán được theo tiêu chuẩn | Giá trị và số lượng theo mức phân loại | Kho và QC |
| Điều chỉnh tồn (inventory adjustment) | Thao tác thay đổi số dư trong hệ thống | Số phiếu, giá trị, người tạo, người duyệt | Người duyệt được chỉ định |
| Xóa sổ (write-off) | Ghi nhận mất giá trị vào chi phí | Giá trị theo kỳ kế toán | Kế toán |
| Tổn thất vận chuyển | Mất hoặc hỏng sau khi đã bàn giao cho bên thứ ba | Số vận đơn, giá trị, tỷ lệ thu hồi | Đội đối soát và chăm sóc đối tác |
Một điều chỉnh tồn không phải là thất thoát. Nó chỉ là hành động. Thất thoát là kết luận sau khi loại trừ được các nguyên nhân dữ liệu: đơn chưa xuất, hàng đang trên đường chuyển kho, hoàn chưa nhập, combo chưa tháo, đơn vị tính sai hoặc mapping SKU sai. Nếu doanh nghiệp gọi mọi điều chỉnh là thất thoát, tỷ lệ sẽ bị thổi phồng và đội kho sẽ ngừng hợp tác.
Ngược lại, nếu doanh nghiệp mặc định mọi chênh lệch đều là lỗi dữ liệu, thất thoát thật sẽ bị che. Vì vậy cần một trạng thái trung gian bắt buộc: chênh lệch chưa giải thích được. Chênh lệch nằm ở trạng thái này cho đến khi có người kết luận, có bằng chứng và có reason code.
So sánh nhanh theo mức độ vận hành
| Quy mô minh họa | Rủi ro thất thoát nổi bật | Kiểm soát tối thiểu nên có | Phạm vi hệ thống phù hợp |
|---|---|---|---|
| Dưới 100 đơn/ngày, một kho nhỏ, chủ tự quản | Lấy nhầm, quên ghi nhận hàng tặng, hoàn không nhập | Một người duyệt duy nhất, sổ điều chỉnh có lý do, kiểm kê nhóm SKU giá trị cao hàng tuần | OMS-only thường đủ nếu chủ trực tiếp đối chiếu |
| 100–1.000 đơn/ngày, kho có nhiều nhân sự theo ca | Mất giữa picking và packing, chênh lệch bàn giao carrier, hoàn thất lạc | Reason code bắt buộc, tách tạo và duyệt, đếm theo tín hiệu, đối chiếu bàn giao theo ngày | OMS + WMS cho các khâu cần log theo thao tác |
| Trên 1.000 đơn/ngày, nhiều kho hoặc có 3PL | Mất trong chuyển kho, chênh lệch tồn tại kho đối tác, tranh chấp trách nhiệm | Ngưỡng duyệt theo giá trị, đối soát tồn với 3PL theo chu kỳ, hồ sơ khiếu nại có hạn, review hằng tháng | OMS + WMS kèm hợp đồng dữ liệu với đối tác |
| Hàng giá trị cao, mỹ phẩm, thực phẩm, điện tử | Mất theo món nhỏ, hết hạn, đổi hàng thật lấy hàng lỗi | Serial hoặc lot, khu vực hạn chế, đếm kép, camera có thời hạn lưu đủ dài | OMS + WMS với kiểm soát trạng thái chặt |
Bảng trên là điểm khởi đầu để tự xếp nhóm, không phải chuẩn ngành. Điều quan trọng là quy mô đơn hàng không quyết định mức kiểm soát; giá trị đơn vị và mức độ dễ mang đi của hàng mới quyết định. Một kho 200 đơn/ngày bán phụ kiện điện tử nhỏ gọn cần kiểm soát chặt hơn một kho 2.000 đơn/ngày bán đồ gia dụng cồng kềnh.
1. Khoảng trống nội dung: thị trường nói về nút bấm, buyer cần khung quyền
Lượt nghiên cứu ngày 18/09/2026 đối chiếu tài liệu sản phẩm cạnh tranh, kết quả tìm kiếm tiếng Việt và thảo luận công khai của người bán. Kết quả khá đồng nhất: thị trường mô tả rất rõ có tính năng kiểm kê, điều chỉnh tăng giảm tồn, lịch sử thao tác và phân quyền; nhưng gần như không mô tả cách thiết kế quyền, ngưỡng, bằng chứng và chỉ số để những tính năng đó thực sự chặn được thất thoát.
| Lớp nguồn | Bằng chứng có thể dùng | Khoảng trống còn lại |
|---|---|---|
| Tài liệu đối thủ/adjacent | Trung tâm trợ giúp của BigSeller liệt kê các bài như “Giới thiệu về tính năng kiểm kho”, “Làm thế nào để tăng thêm, giảm thiểu tồn kho”, “Giới thiệu về tính năng nhập/xuất kho thủ công”, “Làm thế nào để mở khóa tồn kho”. | Tài liệu thao tác cho biết bấm ở đâu, không cho biết ai được bấm, ở ngưỡng giá trị nào, cần bằng chứng gì và báo cáo nào phải được đọc sau đó. |
| Kết quả tìm kiếm tiếng Việt | Trang xếp hạng cao chủ yếu là bài tổng hợp phần mềm: “hỗ trợ kiểm kê và điều chỉnh tồn kho linh hoạt”, “quản lý lịch sử nhập, xuất, hủy hàng, trả hàng và điều chỉnh tồn kho theo từng nhân viên”, “phân quyền để hạn chế thất thoát”. | Các cụm “linh hoạt”, “chặt chẽ”, “minh bạch” không kèm công thức đo, mẫu số, ngưỡng duyệt hay tiêu chí nghiệm thu; buyer không thể dùng để so sánh hai hệ thống. |
| Thảo luận người bán công khai | Các nhóm cộng đồng bán hàng Shopee/TikTok Shop nêu tình trạng chỉ kiểm kho một đến hai lần mỗi năm, nhập hàng không có chứng từ đầu vào, “mất hàng không biết”, và nghi ngờ chức năng kiểm kê cho số sai. | Đây là tín hiệu định tính để dựng ca kiểm thử, không phải thống kê thị trường; không dùng để suy ra tỷ lệ thất thoát của ngành. |
| Inventory nội bộ jsterp.vn | Đã có bài về độ chính xác tồn kho, cycle count, khóa vị trí khi kiểm kê, short pick, hàng hoàn và đối soát COD. | Chưa có pillar gom chúng thành mô hình kiểm soát tổn thất theo tiền, theo reason code và theo quyền duyệt. |
Từ bằng chứng đó, chủ đề được chọn không phải “cách kiểm kê kho” mà là thiết kế kiểm soát thất thoát: định lượng bằng tiền, đóng danh mục nguyên nhân, phân tách quyền và thu hồi phần được bồi thường. Bài không chấm điểm đối thủ và không suy diễn năng lực sản phẩm ngoài những gì tài liệu công khai nói.
2. Định lượng: ba công thức tối thiểu và cái bẫy mẫu số
Không thể quản lý thứ chưa được quy ra tiền. Ba công thức dưới đây đủ cho phần lớn doanh nghiệp ecommerce, với điều kiện mẫu số được cố định và ghi rõ trong định nghĩa báo cáo.
Công thức 1 — tỷ lệ thất thoát theo giá trị: Shrink rate = (Giá trị hàng mất theo giá vốn trong kỳ − Giá trị thu hồi được trong kỳ) ÷ Giá vốn hàng bán trong cùng kỳ × 100%.
Công thức 2 — tỷ lệ thất thoát theo đơn vị: Unit shrink = Số đơn vị mất ÷ Tổng số đơn vị xuất kho trong kỳ × 100%. Chỉ số này hữu ích cho kho nhiều SKU giá trị thấp, nơi một con số theo tiền có thể bị một SKU đắt chi phối.
Công thức 3 — mật độ tổn thất theo thao tác: Loss per 1.000 dòng xuất = Số dòng có chênh lệch đã xác nhận mất ÷ Tổng số dòng xuất × 1.000. Chỉ số này chỉ ra khâu vận hành, không chỉ ra tài chính.
Ví dụ minh họa hoàn toàn giả định để đọc công thức: một kho có giá vốn hàng bán 9,0 tỷ đồng trong quý; giá trị hàng mất đã xác nhận là 27 triệu đồng; thu hồi được 9 triệu từ bồi thường carrier. Shrink rate = (27 − 9) ÷ 9.000 × 100% = 0,20%. Cùng quý đó, kho xuất 240.000 đơn vị và mất 480 đơn vị, tức unit shrink 0,20%. Hai con số trùng nhau ở đây là ngẫu nhiên; khi chúng lệch nhau nhiều, điều đó nói rằng hàng mất tập trung ở nhóm giá trị cao hoặc thấp bất thường và cần bóc tách.
Cái bẫy phổ biến nhất là mẫu số. Nếu tháng này dùng doanh thu, tháng sau dùng giá vốn, quý sau dùng giá trị tồn bình quân, mọi so sánh đều vô nghĩa. Nên chọn một mẫu số, ghi vào tài liệu định nghĩa chỉ số, và khi buộc phải đổi thì tính lại toàn bộ chuỗi lịch sử. Bẫy thứ hai là gộp hàng khuyến mại, hàng tặng, hàng mẫu marketing vào thất thoát; những khoản đó có chủ đích và phải có reason code riêng, nếu không đội kho sẽ bị quy trách nhiệm cho quyết định của đội bán hàng.
3. Bản đồ điểm rò rỉ: hàng rơi ở giữa các bước, không rơi trong một bước
Thất thoát hiếm khi xảy ra bên trong một thao tác đã được quét mã. Nó xảy ra ở khoảng trống giữa hai thao tác, nơi hàng đã rời trách nhiệm của người này nhưng chưa vào trách nhiệm của người kia.
| Điểm chuyển giao | Cách hàng biến mất | Bằng chứng nên bắt buộc |
|---|---|---|
| Xe tải → khu nhận hàng | Thiếu so với phiếu nhưng ký nhận theo chứng từ | Đếm mù trước khi so với ASN, ảnh kiện lỗi, biên bản thiếu ký hai bên |
| Khu nhận → vị trí lưu | Đặt sai bin rồi coi như mất, hoặc rơi trong quá trình vận chuyển nội bộ | Scan vị trí đích khi putaway, đối chiếu tồn khu chờ cuối ca |
| Vị trí lưu → giỏ picking | Lấy dư không khai báo, short pick không ghi nhận | Scan SKU và vị trí, quy trình xử lý short pick bắt buộc, kiểm tra giỏ trước khi rời khu |
| Giỏ picking → bàn đóng gói | Hàng nhỏ giá trị cao bị tách khỏi giỏ trên đường | Kiểm đếm độc lập trước đóng gói, cân đối chiếu, giới hạn khu vực đặt giỏ chờ |
| Đóng gói → khu staging | Kiện đã dán nhãn nhưng không bao giờ lên xe | Scan kiện vào staging, đối chiếu số kiện đã đóng và số kiện bàn giao trong ngày |
| Staging → carrier | Kiện bị nhận thiếu nhưng biên bản ký gộp theo tổng | Manifest có mã kiện, scan xác nhận từng kiện hoặc đối chiếu số lượng kèm ký nhận |
| Khách hoàn → kho | Hoàn về nhưng không nhập, hoặc nhập nhưng thiếu món trong kiện | Mở kiện có ghi hình theo mã vận đơn, nhập theo từng SKU thực nhận |
| Kho A → kho B hoặc 3PL | Xuất đi nhưng không nhập đủ, tồn treo ở trạng thái đang chuyển | Đối chiếu tồn đang chuyển theo tuổi, cảnh báo quá hạn, xác nhận nhận hàng hai chiều |
Nguyên tắc thiết kế rút ra: mỗi điểm chuyển giao phải có một lần ghi nhận trách nhiệm. Nếu không có ghi nhận, khi mất hàng sẽ không thể thu hẹp cửa sổ điều tra và mọi cuộc họp sẽ kết thúc bằng phỏng đoán. Chi tiết luồng nhập nằm trong bài quy trình nhập kho: receiving, kiểm đếm, quarantine và putaway; chi tiết xử lý thiếu hàng tại vị trí nằm trong bài xử lý short pick.
4. Reason code: danh mục đóng, không cho nhập tự do
Ô ghi chú tự do là nơi thông tin đi để chết. “Kiểm kê lệch”, “điều chỉnh theo thực tế”, “sếp duyệt” không giúp ai sửa được cơ chế. Danh mục reason code nên là danh sách đóng, số lượng vừa đủ để nhân viên chọn đúng trong vài giây, và mỗi mã phải gắn với bằng chứng bắt buộc cùng nhóm chi phí.
| Mã | Tên | Bằng chứng bắt buộc | Nhóm chi phí | Cần duyệt? |
|---|---|---|---|---|
| ADJ-DMG | Hư hỏng trong kho | Ảnh hàng hỏng, vị trí phát hiện | Hao hụt vận hành | Theo ngưỡng giá trị |
| ADJ-EXP | Hết hạn hoặc cận hạn không bán được | Mã lô, hạn dùng, danh sách SKU | Hao hụt hàng hóa | Có |
| ADJ-CNT | Chênh lệch kiểm kê đã điều tra | Biên bản đếm, kết quả đếm lại | Thất thoát chưa rõ nguyên nhân | Có |
| ADJ-RCV | Nhận thiếu từ nhà cung cấp | Biên bản thiếu ký hai bên, ảnh kiện | Thu hồi từ nhà cung cấp | Có |
| ADJ-CAR | Mất khi bàn giao vận chuyển | Mã vận đơn, manifest, phản hồi carrier | Tổn thất vận chuyển | Có |
| ADJ-RET | Hoàn thiếu món so với đơn | Video mở kiện, mã vận đơn hoàn | Tổn thất hàng hoàn | Có |
| ADJ-SMP | Xuất mẫu, quà tặng, chụp ảnh | Phiếu yêu cầu có người đề nghị | Chi phí marketing | Có |
| ADJ-SYS | Sửa sai dữ liệu đã chứng minh | Chứng từ gốc, ảnh màn hình giao dịch lỗi | Không tính thất thoát | Có, cấp cao hơn |
Hai mã cần để mắt nhất là ADJ-CNT và ADJ-SYS. ADJ-CNT là nơi mọi thứ không giải thích được sẽ dồn về; nếu nó chiếm tỷ trọng lớn và tăng dần, đó là dấu hiệu quy trình điều tra đang bị bỏ qua. ADJ-SYS là mã nguy hiểm vì nó không bị tính vào thất thoát; nếu một tài khoản dùng ADJ-SYS thường xuyên, đó là dấu hiệu cần kiểm tra trước tiên. Một cách kiểm soát đơn giản là giới hạn ADJ-SYS ở cấp duyệt cao hơn và yêu cầu đính kèm chứng từ gốc.
Số lượng mã nên giữ ở mức có thể nhớ được. Danh mục 8–14 mã thường đủ. Khi vượt quá, nhân viên sẽ chọn mã đầu tiên trong danh sách và dữ liệu trở lại vô nghĩa. Nếu cần chi tiết hơn, hãy dùng trường phụ như khu vực phát hiện hay ca làm việc thay vì tăng số mã.
5. Ngưỡng duyệt: dùng giá trị và rủi ro, không dùng chức danh
“Trưởng kho duyệt hết” là một chính sách nghe hợp lý nhưng tạo ra hai vấn đề: người duyệt trở thành nút thắt nên duyệt cho xong, và nếu chính người đó là nguồn rủi ro thì không ai kiểm được. Ngưỡng theo giá trị giải quyết cả hai.
| Giá trị điều chỉnh minh họa | Cấp duyệt đề xuất | Yêu cầu bổ sung | Thời hạn xử lý |
|---|---|---|---|
| Dưới 500.000đ | Giám sát ca (khác người tạo) | Ảnh hoặc log scan | Trong ca |
| 500.000đ – 5 triệu | Quản lý kho | Đếm lại độc lập trước khi duyệt | 24 giờ |
| 5 – 30 triệu | Quản lý kho và tài chính | Biên bản, truy vết giao dịch liên quan | 3 ngày làm việc |
| Trên 30 triệu | Cấp điều hành | Báo cáo điều tra, phương án khắc phục | 7 ngày làm việc |
| SKU trong danh sách rủi ro cao | Luôn nâng lên một cấp | Đếm kép bắt buộc | Theo cấp tương ứng |
Các con số trên là ví dụ để thảo luận nội bộ, không phải khuyến nghị áp dụng nguyên trạng. Cách hiệu chỉnh thực dụng: lấy phân phối giá trị điều chỉnh 3 tháng gần nhất, đặt ngưỡng thấp nhất sao cho khoảng 70–80% số phiếu rơi vào cấp đầu tiên. Nếu đặt quá thấp, người duyệt sẽ ngập trong phiếu vụn và chất lượng duyệt giảm về không.
Một ràng buộc quan trọng nữa: chặn chia nhỏ phiếu. Nếu cùng một SKU, cùng một người tạo, trong cùng 24 giờ phát sinh nhiều phiếu mà tổng giá trị vượt ngưỡng, hệ thống hoặc quy trình phải nâng cấp duyệt theo tổng. Không có ràng buộc này, mọi ngưỡng đều có thể bị lách bằng cách tách phiếu.
6. Phân tách nhiệm vụ: ma trận quyền tối thiểu
Nguyên tắc gốc rất ngắn: người có thể làm hàng biến mất không được là người có thể làm số liệu khớp lại. Từ đó suy ra ma trận quyền.
| Vai trò | Được làm | Không được làm |
|---|---|---|
| Nhân viên kho | Ghi nhận phát hiện lệch, đếm, chụp ảnh, tạo đề nghị điều chỉnh | Duyệt phiếu, đổi reason code sau duyệt, xóa lịch sử |
| Giám sát ca | Duyệt phiếu giá trị nhỏ, yêu cầu đếm lại | Duyệt phiếu do chính mình tạo |
| Quản lý kho | Duyệt mức trung bình, chốt kết luận nguyên nhân | Sửa số liệu trực tiếp không qua phiếu |
| Kế toán kho | Hạch toán, đối chiếu sổ sách, khóa kỳ | Tạo hoặc duyệt điều chỉnh vận hành |
| Quản trị hệ thống | Cấu hình quyền, danh mục mã | Thực hiện giao dịch nghiệp vụ trên tài khoản quản trị |
| Kiểm tra độc lập | Đếm bất chợt, đọc log, chọn mẫu kiểm chứng | Thay đổi bất kỳ số dư nào |
Với kho nhỏ, phân tách hoàn toàn là bất khả thi vì chỉ có vài người. Giải pháp thay thế là bù bằng kiểm soát bù trừ: chủ doanh nghiệp đọc báo cáo điều chỉnh hằng tuần theo người thao tác; đếm bất chợt nhóm SKU giá trị cao; và yêu cầu ảnh cho mọi phiếu bất kể giá trị. Điều tệ nhất là giả vờ có phân quyền trong khi mọi người dùng chung một tài khoản — lúc đó toàn bộ log trở thành vô dụng.
Tài khoản dùng chung là lỗi phổ biến và tốn kém nhất trong nhóm này. Nó rẻ khi triển khai và đắt khi có sự cố, vì không thể quy trách nhiệm, không thể phân tích theo người, và không thể dùng làm bằng chứng trong quy trình nhân sự. Tách tài khoản là việc nên làm trước khi bàn đến bất kỳ tính năng chống gian lận nào.
7. Bằng chứng phải sinh ra tại điểm phát sinh, không sinh ra lúc kiểm kê
Nếu bằng chứng chỉ xuất hiện khi kiểm kê, mọi kết luận đều là hồi tố và không thể chứng minh. Bốn loại bằng chứng có chi phí thấp nhưng giá trị điều tra cao, xếp theo thứ tự nên triển khai:
- Log scan theo thao tác: ai quét mã nào, tại vị trí nào, lúc nào. Đây là xương sống; không có nó thì camera cũng khó dùng vì không biết tua đến phút nào.
- Ghi hình đóng gói theo mã vận đơn: giải quyết tranh chấp “khách nhận thiếu” và cả “nhân viên gói thiếu”. Cách làm chi tiết nằm ở bài quay video đóng gói theo mã vận đơn.
- Ảnh tại thời điểm phát hiện: bắt buộc cho mọi phiếu hư hỏng và thiếu hàng, chụp cả vị trí xung quanh chứ không chỉ món hàng.
- Đối chiếu bàn giao hằng ngày: số kiện đóng, số kiện staging, số kiện carrier nhận phải khớp trong ngày; lệch phải xử lý trong 24 giờ khi còn truy được.
Thời hạn lưu trữ quan trọng không kém việc thu thập. Nếu video lưu 7 ngày mà chu kỳ phát hiện mất hàng là 30 ngày, hệ thống camera chỉ có tác dụng răn đe. Nên đặt thời hạn lưu dài hơn chu kỳ phát hiện trung bình, và rút ngắn chu kỳ phát hiện xuống dưới thời hạn lưu — làm cả hai phía sẽ rẻ hơn là chỉ mua thêm dung lượng.
8. Chu kỳ phát hiện: chỉ số bị bỏ quên nhưng quyết định khả năng thu hồi
Chu kỳ phát hiện là khoảng thời gian từ lúc hàng thực sự mất đến lúc doanh nghiệp biết. Nó quyết định gần như mọi thứ: khả năng tìm ra nguyên nhân, khả năng khiếu nại carrier trong hạn, khả năng quy trách nhiệm và khả năng ngăn tái diễn.
Ví dụ minh họa: một kho kiểm kê toàn bộ mỗi 6 tháng có chu kỳ phát hiện trung bình khoảng 90 ngày với giả định mất rải đều. Nếu hạn khiếu nại carrier là 14–30 ngày tùy hợp đồng, gần như toàn bộ tổn thất vận chuyển sẽ hết hạn đòi trước khi được phát hiện. Cùng kho đó chuyển sang đối chiếu bàn giao hằng ngày và đếm theo tín hiệu rủi ro sẽ đưa chu kỳ phát hiện cho nhóm tổn thất vận chuyển xuống dưới một ngày — phần thu hồi được tăng lên mà không cần thêm nhân sự đếm.
Cách đo thực dụng: với mỗi vụ mất hàng đã xác định được thời điểm, ghi lại khoảng cách giữa ngày xảy ra ước tính và ngày phát hiện. Theo dõi trung vị theo nhóm nguyên nhân. Nhóm nào có trung vị dài hơn thời hạn hành động tương ứng chính là nhóm cần thêm điểm kiểm tra, không phải nhóm cần thêm kiểm kê tổng.
9. Tồn âm và nguyên tắc không bao giờ “sửa cho khớp”
Tồn âm là tín hiệu chẩn đoán quý giá, không phải lỗi hiển thị cần dọn. Nó nói rằng hệ thống đã xuất nhiều hơn số nó biết là có: hàng nhập chưa ghi nhận, hoàn chưa nhập, combo chưa tháo, mapping sai đơn vị, hoặc ai đó đã xuất ngoài quy trình.
Anti-pattern cần loại bỏ là thao tác “đặt lại tồn về số thực tế”. Nó xóa dấu vết của cả nguyên nhân dữ liệu lẫn nguyên nhân vật lý trong một hành động. Thay thế bằng quy trình bốn bước: đóng băng SKU khỏi việc bán nếu rủi ro oversell cao; liệt kê toàn bộ giao dịch trong cửa sổ nghi ngờ; xác định phần chênh có chứng từ và phần không; chỉ điều chỉnh phần không giải thích được, với reason code và người duyệt.
Chính sách cho phép tồn âm hay không nên tùy trạng thái. Cho phép tồn âm tạm thời ở kho nội bộ giúp không chặn vận hành khi chứng từ về chậm, nhưng phải kèm hạn xử lý và cảnh báo theo tuổi. Không nên để tồn âm truyền ra tồn công bố trên sàn; chi tiết cách tách tồn bán được và tồn thực tế nằm trong bài SLA đồng bộ tồn kho đa sàn.
10. Thu hồi: tách phần được bồi thường ra khỏi thất thoát
Một phần đáng kể hàng “mất” thực ra thuộc trách nhiệm của bên khác và có thể đòi được, với điều kiện hồ sơ đủ và trong hạn. Mỗi ngày chậm làm giảm khả năng thu hồi, nên đây là nơi quy trình quan trọng hơn thương lượng.
| Bên chịu trách nhiệm | Tình huống điển hình | Hồ sơ cần có | Điểm cần kiểm tra trong hợp đồng |
|---|---|---|---|
| Nhà cung cấp | Giao thiếu so với PO, hàng lỗi ngay khi nhận | Biên bản thiếu ký hai bên, ảnh kiện nguyên seal, kết quả đếm mù | Thời hạn phản hồi, cách xử lý giao bù |
| Đơn vị vận chuyển | Mất kiện sau khi đã nhận, giao thiếu cho khách | Manifest, bằng chứng bàn giao, video đóng gói, cân nặng ghi nhận | Hạn khiếu nại, mức bồi thường trần, quy tắc chứng minh giá trị |
| 3PL | Chênh lệch tồn tại kho đối tác, hàng hỏng do lưu trữ | Biên bản đối soát tồn định kỳ, ảnh hiện trạng, log nhập xuất hai phía | Chu kỳ đối soát, ngưỡng hao hụt cho phép, cơ chế bồi thường |
| Sàn thương mại điện tử | Hàng trong chương trình fulfillment của sàn, hoàn không về | Mã đơn, trạng thái hệ thống sàn, lịch sử yêu cầu | Chính sách hiện hành và thời hạn khiếu nại theo từng sàn |
Hai chỉ số nên theo dõi: tỷ lệ hồ sơ nộp đúng hạn và tỷ lệ thu hồi trên giá trị đã nộp. Nếu tỷ lệ nộp đúng hạn thấp, vấn đề nằm ở chu kỳ phát hiện chứ không ở kỹ năng đàm phán. Mức bồi thường thực tế phụ thuộc hợp đồng cụ thể và chính sách hiện hành của từng đối tác; không nên giả định một mức chung. Bài SLA 3PL fulfillment mô tả cách đưa các điều khoản này vào scorecard đối tác.
11. Hàng hoàn và COD: vùng thất thoát bị tính nhầm nhiều nhất
Hàng hoàn tạo ra ba loại tổn thất khác nhau thường bị gộp làm một: hàng hoàn không bao giờ về kho; hàng về nhưng thiếu món hoặc thiếu phụ kiện; hàng về đủ nhưng không còn bán được như hàng mới. Ba loại này có nguyên nhân, chủ thể chịu trách nhiệm và cách xử lý hoàn toàn khác nhau.
Nguyên tắc ghi nhận nên là: chỉ tăng tồn khi hàng đã được mở, kiểm và phân loại — không tăng tồn tại thời điểm hệ thống báo hoàn. Trước đó, hàng nằm ở trạng thái đang hoàn với tuổi được theo dõi. Bản ghi quá hạn mà không thấy hàng chính là vùng cần khiếu nại, và nó chỉ hiện ra nếu trạng thái trung gian tồn tại. Chi tiết cách phân loại nằm ở bài quản lý hàng hoàn theo cost-to-recover và phân hạng hàng hoàn.
Về COD, khoản tiền chưa về không phải thất thoát tồn kho, nhưng nó thường được phát hiện cùng lúc và bị trộn vào cùng một cuộc họp. Nên giữ hai sổ riêng: sổ hàng và sổ tiền, đối chiếu bằng mã vận đơn chung. Cách đối soát tiền được mô tả ở bài đối soát dòng tiền bằng 4-way match và đối soát COD, phí sàn và hàng hoàn.
12. Tín hiệu bất thường: dùng để mở điều tra, không dùng để kết tội
Phân tích dữ liệu có thể chỉ ra nơi đáng nhìn kỹ hơn. Nó không chứng minh hành vi. Mọi tín hiệu dưới đây đều có cách giải thích vô hại, nên quy trình phải là mở điều tra chứ không phải xử lý nhân sự.
- Chênh lệch tập trung bất thường vào một ca, một khu vực hoặc một người thao tác so với khối lượng công việc tương ứng.
- Một tài khoản có tỷ lệ dùng mã ADJ-SYS hoặc mã “sửa dữ liệu” cao hơn hẳn mặt bằng.
- Nhiều phiếu điều chỉnh nhỏ ngay dưới ngưỡng duyệt, lặp lại theo chu kỳ.
- SKU giá trị cao có chênh lệch âm nhiều lần trong khi SKU cùng khu vực không có.
- Điều chỉnh phát sinh ngoài giờ làm việc thông thường mà không có yêu cầu vận hành tương ứng.
- Khoảng cách lớn và tăng dần giữa số kiện đóng gói và số kiện được carrier xác nhận.
- Hủy đơn hoặc hoàn nội bộ tập trung vào một nhóm khách hàng hoặc một địa chỉ.
Cách xử lý đúng là quy trình hai lớp: lớp một là kiểm chứng dữ liệu độc lập, ví dụ đếm bất chợt nhóm SKU liên quan và đối chiếu log thao tác với video. Lớp hai, chỉ khi lớp một cho kết quả nhất quán, mới chuyển sang quy trình nhân sự phù hợp quy định pháp luật và nội quy lao động. Kết luận vội dựa trên một biểu đồ vừa không công bằng vừa dễ khiến doanh nghiệp mất người giỏi và mất cả khả năng bảo vệ mình về sau.
13. Hồ sơ xử lý: ghi nhận trước, hạch toán sau
Mất hàng đã xác nhận cuối cùng phải được ghi nhận vào chi phí. Về mặt vận hành, bộ hồ sơ tối thiểu thường gồm: biên bản kiểm kê có chữ ký của những người tham gia đếm; bảng kê chênh lệch theo SKU kèm giá trị; kết luận nguyên nhân theo reason code; phê duyệt theo đúng cấp; và chứng từ liên quan nếu có bên thứ ba.
Về mặt kế toán và thuế, yêu cầu chứng từ, thời điểm ghi nhận và điều kiện được tính vào chi phí được trừ phụ thuộc quy định hiện hành và đặc thù doanh nghiệp. Bài viết này không thay thế tư vấn chuyên môn; hãy để kế toán trưởng hoặc đơn vị tư vấn thuế xác nhận trước khi chốt quy trình. Điều thuộc phạm vi vận hành là: đừng để phần ghi nhận phụ thuộc vào trí nhớ, và đừng để hồ sơ được lập sau nhiều tháng khi không ai còn nhớ chi tiết.
Một thực hành hữu ích là đóng kỳ thất thoát cùng nhịp với đóng kỳ kế toán. Sau ngày chốt, mọi điều chỉnh thuộc kỳ cũ phải đi qua cấp duyệt cao hơn. Điều này ngăn việc dồn tổn thất sang kỳ sau để báo cáo tháng này trông đẹp hơn.
14. OMS-only hay OMS + WMS cho bài toán thất thoát?
Câu hỏi không phải quy mô mà là: bằng chứng cần thiết để tìm ra hàng mất ở đâu có tồn tại không, và nó có sinh ra tự động không?
| Tiêu chí | OMS-only có thể đủ khi | Cần OMS + WMS khi |
|---|---|---|
| Điểm chuyển giao | Hàng đi thẳng từ một khu lưu trữ tới bàn đóng gói, ít bước trung gian | Có nhiều bước, nhiều khu, nhiều ca và nhiều người chạm vào cùng một món |
| Bằng chứng thao tác | Chủ hoặc quản lý trực tiếp quan sát được toàn bộ | Cần log scan theo người, vị trí và thời điểm để thu hẹp cửa sổ điều tra |
| Trạng thái hàng | Chỉ có hàng bán được và hàng lỗi | Có quarantine, chờ kiểm, chờ hoàn, chờ hủy, đang chuyển kho |
| Đối tác | Không dùng 3PL, không chuyển kho | Có 3PL, nhiều kho hoặc kho vệ tinh cần đối soát hai phía |
| Giá trị rủi ro | Giá trị mỗi món thấp, tổn thất một lần không đáng kể | Hàng giá trị cao, nhỏ gọn, dễ mang đi hoặc có serial cần truy vết |
Cần nói rõ giới hạn: WMS không tự làm giảm thất thoát. Nó tạo ra bằng chứng và ràng buộc thao tác để con người có thể phát hiện, điều tra và sửa cơ chế. Nếu doanh nghiệp triển khai WMS nhưng vẫn cho sửa tồn tự do, vẫn dùng tài khoản chung và vẫn không ai đọc báo cáo điều chỉnh, kết quả sẽ không khác trước. Khung so sánh phạm vi hai hệ thống nằm ở bài phần mềm OMS + WMS cho ecommerce Việt Nam, và mô tả năng lực kho nằm ở trang giải pháp vận hành kho.
15. Ví dụ vận hành minh họa: kho 1.500 SKU, 1.200 đơn/ngày
Toàn bộ số liệu dưới đây là giả định để minh họa cách đọc, không phải dữ liệu khách hàng.
Bối cảnh: kho bán mỹ phẩm và phụ kiện trên ba sàn, giá trị đơn trung bình 320.000đ, giá vốn hàng bán 2,4 tỷ đồng mỗi tháng. Tháng đầu tiên sau khi bật reason code bắt buộc, tổng giá trị điều chỉnh âm là 41 triệu đồng. Sau phân loại: 14 triệu thuộc ADJ-SYS đã chứng minh là lỗi dữ liệu do combo chưa tháo; 9 triệu thuộc ADJ-CAR có mã vận đơn; 6 triệu thuộc ADJ-RET hoàn thiếu món; 4 triệu thuộc ADJ-DMG; 8 triệu còn lại thuộc ADJ-CNT chưa rõ nguyên nhân.
Cách đọc: thất thoát thật trong tháng là 41 − 14 = 27 triệu, tương đương 1,13% giá vốn — mức cần hành động. Nhưng cấu trúc mới là điều đáng chú ý: 15 triệu (ADJ-CAR và ADJ-RET) thuộc nhóm có thể thu hồi nếu hồ sơ kịp hạn, tức hơn một nửa. Ưu tiên tháng sau vì vậy không phải tăng tần suất kiểm kê mà là rút ngắn chu kỳ phát hiện ở hai điểm: đối chiếu bàn giao carrier hằng ngày và mở kiện hoàn có ghi hình trong 48 giờ.
Kết quả giả định sau hai tháng điều chỉnh trọng tâm: ADJ-CAR giảm còn 3 triệu nhờ đối chiếu kịp và đòi được phần lớn; ADJ-RET giảm còn 2 triệu; ADJ-CNT giảm còn 5 triệu vì nhiều trường hợp trước đây rơi vào “không rõ” nay được gán đúng nguyên nhân. Điểm quan trọng: phần lớn cải thiện đến từ việc phát hiện sớm hơn, không phải từ việc đếm nhiều hơn.
16. Kế hoạch 30–60–90 ngày
Ngày 1–30 — dựng khung. Tách tài khoản người dùng, bỏ tài khoản dùng chung. Đóng danh mục reason code với 8–14 mã. Bật bắt buộc chọn mã khi điều chỉnh. Ghi lại phân phối giá trị điều chỉnh 3 tháng gần nhất để đặt ngưỡng. Xác định danh sách SKU rủi ro cao theo giá trị và độ dễ mang đi.
Ngày 31–60 — siết quyền và bằng chứng. Áp ngưỡng duyệt và chặn chia nhỏ phiếu. Bắt buộc ảnh cho phiếu hư hỏng và thiếu hàng. Bật đối chiếu bàn giao carrier hằng ngày. Đưa hàng hoàn vào trạng thái trung gian có theo dõi tuổi. Bắt đầu báo cáo thất thoát theo reason code, theo ca và theo người thao tác.
Ngày 61–90 — đóng vòng. Thiết lập nhịp review hằng tháng với đủ vận hành và tài chính. Đo chu kỳ phát hiện theo nhóm nguyên nhân. Đưa hồ sơ khiếu nại vào quy trình có hạn và theo dõi tỷ lệ nộp đúng hạn. Thực hiện ít nhất một lần đếm bất chợt do người ngoài đội kho thực hiện. Rà lại ngưỡng dựa trên dữ liệu thực tế ba tháng.
Thứ tự này có chủ đích: phân loại trước, siết quyền sau, đo sau cùng. Đảo ngược thứ tự — ví dụ mua camera trước khi tách tài khoản — thường tốn tiền mà không đổi được kết quả.
17. Checklist thực thi cho đội ecommerce Việt Nam
- Xuất báo cáo điều chỉnh tồn 90 ngày gần nhất theo người thao tác. Nếu không xuất được theo người, đó là phát hiện đầu tiên và là việc cần sửa trước mọi thứ khác.
- Đóng danh mục reason code và tắt ô ghi chú tự do làm lý do chính. Đặt mục tiêu dưới 20% giá trị điều chỉnh rơi vào nhóm không rõ nguyên nhân sau 90 ngày.
- Đặt ngưỡng duyệt theo giá trị và bắt buộc người duyệt khác người tạo. Kèm quy tắc cộng dồn trong 24 giờ để chặn chia nhỏ phiếu.
- Bật đối chiếu số kiện đóng gói với số kiện carrier nhận theo ngày. Đây là biện pháp rẻ nhất có khả năng chuyển tổn thất sang bên chịu trách nhiệm.
- Lập nhịp review hằng tháng có cả vận hành và tài chính. Mỗi nhóm nguyên nhân phải có một hành động cụ thể hoặc một quyết định chấp nhận rủi ro có ghi nhận.
18. Sai lầm phổ biến cần sửa
“Lắp camera là kiểm soát được thất thoát.” Camera chỉ hữu ích khi biết tua đến đâu. Không có log thao tác theo thời gian và vị trí, việc xem lại hàng chục giờ video gần như không khả thi và sẽ bị bỏ sau vài lần.
“Kiểm kê toàn kho thường xuyên hơn sẽ giảm mất hàng.” Kiểm kê đo lường, không ngăn chặn. Tăng tần suất mà không rút ngắn chu kỳ phát hiện ở các điểm chuyển giao chỉ làm tăng chi phí và làm gián đoạn vận hành.
“Điều chỉnh tồn về khớp thực tế là xong việc.” Đây là hành động xóa bằng chứng phổ biến nhất. Số liệu đẹp trở lại, nguyên nhân vẫn còn, và tháng sau lặp lại.
“Thất thoát là trách nhiệm của kho.” Một phần đáng kể đến từ quyết định ngoài kho: hàng tặng không có phiếu, khuyến mại đổi liên tục, mapping SKU sai, chính sách hoàn dễ dãi. Quy hết cho kho sẽ làm mất hợp tác của chính những người có thông tin tốt nhất.
“Mất trong vận chuyển thì coi như mất luôn.” Nhiều khoản đòi được nếu hồ sơ kịp hạn. Bỏ qua bước này là từ chối một nguồn thu hồi có sẵn.
“Phân quyền nghĩa là cấm nhân viên làm gì cũng phải xin.” Kiểm soát quá chặt ở giá trị nhỏ sẽ sinh ra đường vòng không chính thức. Thiết kế tốt là cho phép nhanh ở mức rủi ro thấp và siết chặt ở mức rủi ro cao.
“Có WMS rồi thì không cần quy trình.” Hệ thống thực thi quy tắc được cấu hình. Nếu quy tắc chưa được quyết định, hệ thống sẽ chỉ ghi lại một cách chính xác các thao tác tùy tiện.
19. Câu hỏi nghiệm thu khi đánh giá OMS + WMS về kiểm soát thất thoát
- Hệ thống có bắt buộc chọn reason code từ danh mục đóng khi thay đổi số dư tồn không, và danh mục có cấu hình được theo doanh nghiệp không?
- Có cấu hình được ngưỡng duyệt theo giá trị và chặn được việc người tạo tự duyệt không?
- Có chặn hoặc cảnh báo được việc chia nhỏ phiếu để lách ngưỡng trong một cửa sổ thời gian không?
- Log thao tác có ghi đủ người, thiết bị, vị trí và thời điểm, và có xuất ra được để đối chiếu không?
- Có báo cáo thất thoát theo reason code, theo ca, theo khu vực và theo người thao tác không?
- Hàng hoàn có trạng thái trung gian với theo dõi tuổi trước khi được tính là tồn bán được không?
- Có đối chiếu được số kiện đóng gói, staging và bàn giao carrier theo ngày không?
- Với 3PL hoặc nhiều kho, có cơ chế đối soát tồn hai phía theo chu kỳ và ghi nhận chênh lệch không?
- Quyền chỉnh sửa hoặc xóa lịch sử có bị giới hạn và ghi log riêng không?
- Dữ liệu điều chỉnh có kết nối được sang hạch toán để tài chính đối chiếu mà không phải nhập tay không?
Mọi câu trả lời nên được kiểm chứng trên dữ liệu và phạm vi thật trong giai đoạn khảo sát, không dựa vào mô tả tính năng. Cách JST ERP Việt Nam xác nhận phạm vi và bàn giao được mô tả tại trang bảo đảm dịch vụ.
20. FAQ triển khai ngắn
Nên bắt đầu từ reason code hay từ phân quyền?
Từ reason code. Nó rẻ, ít gây xung đột nội bộ và tạo ra dữ liệu để thiết kế phân quyền đúng. Siết quyền trước khi biết thất thoát đang tập trung ở đâu thường dẫn đến siết nhầm chỗ và làm chậm vận hành mà không giảm được tổn thất.
Kho nhỏ chỉ có ba người thì phân tách nhiệm vụ thế nào?
Không phân tách hoàn toàn được, nên dùng kiểm soát bù trừ: chủ doanh nghiệp duyệt mọi phiếu vượt một mức thấp, đọc báo cáo điều chỉnh hằng tuần, và đếm bất chợt nhóm SKU giá trị cao. Quan trọng nhất vẫn là mỗi người một tài khoản riêng.
Có nên công bố tỷ lệ thất thoát cho toàn đội kho không?
Nên công bố theo nhóm nguyên nhân và xu hướng, kèm hành động đang làm. Không nên công bố dưới dạng xếp hạng cá nhân khi chưa có điều tra, vì điều đó khuyến khích giấu chênh lệch thay vì báo cáo sớm — và giấu chênh lệch mới là thiệt hại lớn hơn.
Bao lâu thì thấy kết quả?
Phần phân loại và thu hồi thường cho tín hiệu trong 30–60 ngày vì chúng chỉ phụ thuộc quy trình. Phần giảm thất thoát chưa rõ nguyên nhân chậm hơn vì cần sửa cơ chế ở từng điểm chuyển giao. Đặt kỳ vọng theo hai nhịp khác nhau sẽ tránh được kết luận vội rằng dự án thất bại.
Có nên đặt mục tiêu thất thoát bằng không?
Không thực tế và dễ phản tác dụng, vì nó tạo áp lực che giấu. Mục tiêu hợp lý là giảm nhóm chưa rõ nguyên nhân, tăng tỷ lệ thu hồi và rút ngắn chu kỳ phát hiện; ba chỉ số này phản ánh chất lượng kiểm soát tốt hơn một con số tuyệt đối.
21. Kết luận: kiểm soát thất thoát là thiết kế quyền, không phải chiến dịch
Thất thoát giảm khi ba điều kiện cùng tồn tại: mỗi thay đổi số lượng đều mang nguyên nhân và bằng chứng; người tạo và người duyệt là hai người khác nhau ở mức rủi ro tương ứng; và khoảng cách từ lúc mất đến lúc biết đủ ngắn để còn điều tra và còn khiếu nại được. Không điều nào trong ba điều này là tính năng có thể mua rời.
OMS-only phù hợp khi kho đơn giản và người chủ vẫn quan sát trực tiếp được toàn bộ dòng hàng. OMS + WMS cần thiết khi hàng đi qua nhiều điểm chuyển giao, nhiều ca và nhiều đối tác — vì lúc đó chỉ có log thao tác theo vị trí, theo người và theo thời điểm mới đủ để thu hẹp cửa sổ điều tra xuống mức hành động được.
Để đánh giá sát doanh nghiệp Việt Nam, hãy xem phạm vi sản phẩm OMS + WMS, cách xử lý đơn và tồn đa kênh tại giải pháp bán hàng đa kênh, các bước vận hành kho tại giải pháp vận hành kho, cam kết dịch vụ và cách xác nhận phạm vi, đọc câu hỏi thường gặp, rồi đăng ký tư vấn. Đội JST ERP Việt Nam có thể cùng rà báo cáo điều chỉnh, hồ sơ khiếu nại và luồng hàng hoàn; mọi khả năng sản phẩm, tích hợp và thiết bị cần được xác nhận trên phạm vi thật trước khi quyết định.