Bàn giao ca kho trong WMS: không để đơn, tồn và ngoại lệ rơi giữa hai ca làm

Tóm tắt nhanh

Bàn giao ca kho trong WMS là quy trình chốt trạng thái giữa hai ca làm để đơn hàng, tồn kho và ngoại lệ không bị rơi khỏi hệ thống. Với doanh nghiệp ecommerce Việt Nam, OMS gom đơn từ Shopee, Lazada, TikTok Shop, website, social commerce và livestream; WMS ghi nhận thao tác kho từ picking, checking, packing, staging, bàn giao vận chuyển đến xử lý hàng hoàn. Khi đổi ca, hệ thống cần cho thấy đơn nào còn chờ xử lý, SKU nào thiếu, vị trí nào còn hàng đang giữ, kiện nào đã đóng nhưng chưa scan bàn giao, hàng hoàn nào chờ QC và ai chịu trách nhiệm bước tiếp theo. Nếu bàn giao ca chỉ dựa vào nhóm chat hoặc trí nhớ nhân viên, doanh nghiệp dễ giao trễ, lệch tồn, mất kiện, xử lý lặp việc và không biết lỗi thuộc về ca nào.

• Từ khóa trọng tâm: bàn giao ca kho WMS, shift handover warehouse, kiểm soát ca kho ecommerce, bàn giao đơn tồn kho ngoại lệ.
• JST ERP Việt Nam triển khai ERP/OMS + WMS cho doanh nghiệp cần gom đơn đa kênh, kiểm soát SKU, barcode, vị trí kho, PDA, picking, checking, packing, bàn giao vận chuyển và báo cáo vận hành.
• Bối cảnh Việt Nam: đơn Shopee, Lazada, TikTok Shop, livestream, COD và đơn campaign thường chạy nhiều ca, nhiều nhân sự, nhiều hãng vận chuyển và nhiều ngoại lệ đổi trả.
• Quy trình kho liên quan: chốt ca, kiểm đơn chờ, scan vị trí staging, xác nhận packing dở, kiểm hàng hoàn, bàn giao SKU ngoại lệ, phân quyền ca trưởng và log trách nhiệm.

Thông tin thực thể liên quan

Bảng so sánh lựa chọn vận hành

Vì sao bàn giao ca kho thường gây lỗi vận hành?

Đổi ca là thời điểm dữ liệu và hàng vật lý dễ tách khỏi nhau nhất. Trên hệ thống, đơn có thể đang ở trạng thái đã picking; ngoài kho, khay hàng lại nằm ở khu checking. Một kiện có thể đã đóng xong nhưng chưa được scan vào khu chờ vận chuyển. Một SKU thiếu có thể đã được nhân viên ca trước báo trên chat nhưng chưa tạo ngoại lệ trong OMS.

Nếu không có WMS ghi nhận trạng thái, ca sau thường bắt đầu bằng việc hỏi lại, tìm hàng, mở kiện, kiểm phiếu hoặc làm lại thao tác. Khi số đơn tăng trong mùa sale, vài phút mất ở mỗi điểm chuyển giao sẽ biến thành hàng trăm đơn trễ SLA.

• Đơn bị treo giữa picking, checking, packing và staging.
• Hàng thực tế nằm ở một vị trí nhưng hệ thống không ghi nhận đúng trạng thái.
• Ngoại lệ thiếu hàng, sai barcode, hàng lỗi hoặc đơn hủy không có người tiếp nhận rõ.

Một biên bản bàn giao ca tốt cần có dữ liệu gì?

Bàn giao ca không nên chỉ là ghi tổng số đơn đã xử lý. Ca trưởng cần nhìn theo từng nhóm công việc: đơn mới chưa phân wave, đơn đã giữ tồn chờ picking, đơn đang picking, đơn chờ checking, đơn packing dở, kiện đã đóng chờ bàn giao, hàng hoàn chờ QC và ngoại lệ cần duyệt.

WMS nên tự tổng hợp phần lớn dữ liệu này từ barcode, PDA và vị trí kho. Nhân viên chỉ bổ sung phần nhận xét thật sự cần thiết, ví dụ máy in tem SPX lỗi, khu STG-TIKTOK-JT còn 18 kiện chưa xe nhận, hoặc SKU A-RED-M thiếu 6 chiếc đang chờ CSKH đổi sản phẩm.

• Số đơn theo trạng thái: new, allocated, picking, checking, packing, packed, handed over, exception.
• Danh sách SKU ngoại lệ theo mã hàng, barcode, số lượng, vị trí và lý do.
• Danh sách vị trí staging còn kiện chưa bàn giao theo hãng vận chuyển hoặc kênh bán.

Thiết kế trạng thái để ca sau không phải đoán

Một vấn đề phổ biến là doanh nghiệp dùng quá ít trạng thái. Nếu tất cả đơn chưa giao đều nằm chung trong một nhóm "đang xử lý", ca sau không biết đơn nào cần lấy hàng, đơn nào đã lấy xong, đơn nào đang thiếu sản phẩm và đơn nào chỉ chờ xe vận chuyển.

JSTERP WMS nên tách trạng thái theo điểm kiểm soát thật trong kho. Mỗi trạng thái cần có điều kiện vào, điều kiện ra và thao tác bắt buộc. Ví dụ, đơn chỉ chuyển sang "packed" khi đã scan mã vận đơn, cân kiện hoặc xác nhận vật tư; chỉ chuyển sang "handover ready" khi nằm đúng khu staging và không còn ngoại lệ.

• Không cho bàn giao ca nếu còn đơn packing dở nhưng không có người phụ trách.
• Không cho xóa ngoại lệ bằng ghi chú tự do; phải có lý do và hành động tiếp theo.
• Trạng thái trên OMS phải đồng bộ với trạng thái WMS để CSKH không trả lời sai khách.

Barcode và vị trí kho là nền tảng của bàn giao ca

Nếu hàng chỉ được đặt trên bàn hoặc dưới sàn theo kinh nghiệm, bàn giao ca rất khó chính xác. WMS cần mã hóa các khu vực chuyển giao: PICK-WAIT, CHK-READY, PKG-HOLD, STG-SHOPEE-SPX, STG-LAZADA-LEX, RTN-QC, EXC-CSKH. Khi ca trước kết thúc, ca trưởng scan hoặc đối chiếu số lượng theo từng khu.

Barcode giúp xác nhận đúng đơn, đúng kiện và đúng vị trí. Ví dụ, một kiện đã packed nhưng vẫn nằm ở PKG-HOLD không nên được tính là đã bàn giao vận chuyển. Một đơn thiếu SKU đang ở EXC-CSKH không nên bị ca sau lấy lại để packing như đơn bình thường.

• Dùng mã vị trí rõ để phân biệt hàng chờ xử lý, hàng lỗi, hàng hoàn và hàng chờ bàn giao.
• Scan kiện khi chuyển từ packing sang staging để tránh mất kiện cuối ca.
• Đối chiếu số kiện staging với biên bản hãng vận chuyển trước khi đóng ca.

Bàn giao ngoại lệ: phần quan trọng nhất nhưng hay bị bỏ qua

Ngoại lệ là nơi ca sau dễ mất nhiều thời gian nhất. Thiếu hàng sau picking, sai biến thể, barcode không quét được, đơn bị hủy khi đã đóng gói, hàng hoàn chưa QC, khách đổi địa chỉ hoặc COD bất thường đều cần trạng thái riêng. Nếu chỉ ghi "đã báo bạn A" trên chat, hệ thống không biết đơn đang bị chặn vì lý do gì.

Trong WMS, mỗi ngoại lệ nên có chủ sở hữu tiếp theo: kho kiểm lại, CSKH xác nhận, quản lý duyệt đổi SKU, kế toán kiểm COD hoặc vận hành liên hệ hãng vận chuyển. Khi bàn giao ca, ca sau nhận danh sách ngoại lệ kèm deadline, bằng chứng và lịch sử thao tác thay vì phải đọc lại hàng chục tin nhắn.

• Ngoại lệ thiếu hàng phải giữ tồn và chặn packing cho đến khi có quyết định.
• Đơn hủy sau khi packed cần mở kiện, trả hàng về vị trí và cập nhật tồn đúng trạng thái.
• Hàng hoàn cần phân biệt chờ QC, có thể bán lại, lỗi, thiếu phụ kiện hoặc chờ nhà cung cấp xử lý.

Bàn giao giữa kho và vận chuyển cũng là một phần của ca

Nhiều kho chỉ xem bàn giao ca là việc nội bộ nhân viên. Nhưng với ecommerce, điểm cuối của ca thường là bàn giao cho hãng vận chuyển. Nếu ca tối đóng xong 500 kiện nhưng chỉ 430 kiện được scan cho hãng, 70 kiện còn lại phải có trạng thái rõ: chưa xe nhận, lỗi mã vận đơn, nằm sai staging hay chờ đối soát.

WMS nên nối dữ liệu packing, staging và vận chuyển. Khi hãng nhận hàng, nhân viên scan kiện hoặc lô bàn giao; hệ thống ghi nhận thời gian, người bàn giao, số kiện, hãng vận chuyển và chênh lệch nếu có. Dữ liệu này giúp CSKH trả lời khi khách hỏi đơn, đồng thời giúp quản lý phát hiện hãng hoặc ca nào thường bị trễ.

• Tách staging theo hãng vận chuyển, kênh bán hoặc deadline cut-off.
• Ghi nhận số kiện bàn giao và số kiện còn lại sau mỗi lượt xe.
• Đơn COD giá trị cao nên có bằng chứng bàn giao rõ hơn đơn thường.

Chỉ số nào cho biết bàn giao ca đang ổn?

Một quy trình bàn giao ca tốt phải đo được. Doanh nghiệp nên theo dõi số đơn treo cuối ca, số ngoại lệ chưa nhận chủ, thời gian ca sau bắt đầu xử lý, số kiện staging còn lại sau cut-off, tỷ lệ phải làm lại checking/packing và số lỗi truy về bàn giao.

Nếu các chỉ số này giảm, doanh nghiệp không chỉ giảm lỗi mà còn tăng năng suất ca sau. Nhân viên mới cũng dễ vào việc hơn vì danh sách cần xử lý nằm trong WMS, không nằm trong trí nhớ của người ca trước.

• Số đơn treo cuối ca theo từng trạng thái và từng khu vực kho.
• Số ngoại lệ quá SLA hoặc chưa có người phụ trách.
• Tỷ lệ kiện đã packed nhưng chưa bàn giao vận chuyển trước cut-off.

JSTERP trong bối cảnh Top Gia và doanh nghiệp tăng trưởng nhanh

Case tham khảo Top Gia từng đạt đỉnh khoảng 200.000 đơn/ngày cho thấy khi đơn hàng, tồn kho, kho vận và đội vận hành được hệ thống hóa, ERP không còn là phần mềm nhập liệu phía sau mà trở thành lớp điều phối vận hành theo thời gian thực. Với chủ đề Bàn giao ca kho trong WMS, điểm đáng học không phải là con số lớn để gây ấn tượng, mà là cách doanh nghiệp chuẩn hóa dữ liệu trước khi đơn hàng bùng lên: SKU thống nhất, tồn khả dụng rõ, trạng thái đơn được gom về OMS và thao tác kho được WMS ghi nhận.

Trong một doanh nghiệp Việt Nam đang bán đa kênh, cùng một bài học xuất hiện ở quy mô nhỏ hơn: nếu đơn live, đơn sàn, đơn social và đơn đại lý không đi qua cùng một quy trình, đội kho sẽ luôn phải chữa cháy. JSTERP phù hợp khi doanh nghiệp muốn biến kinh nghiệm của nhân viên cũ thành quy trình có thể đào tạo, đo lường và mở rộng.

• Tập trung vào luồng vận hành thật thay vì chỉ xem danh sách tính năng.
• Dùng OMS để gom đơn và giữ tồn; dùng WMS để kiểm soát thao tác kho.
• Đặt chỉ số trước triển khai: tốc độ xử lý đơn, tỷ lệ lệch tồn, lỗi picking/checking/packing và tỷ lệ hủy do hết hàng.

So sánh với BigSeller, Haravan và quản lý thủ công

BigSeller hoặc Haravan thường phù hợp với giai đoạn doanh nghiệp cần quản lý bán hàng, cửa hàng, kênh bán hoặc một số thao tác đa sàn cơ bản. Nhưng khi bài toán chuyển sang kiểm soát số đơn còn treo, vị trí staging, SKU ngoại lệ, tồn giữ, hàng hoàn, packing dở, bàn giao vận chuyển và trách nhiệm giữa ca sáng, ca chiều, ca tối, doanh nghiệp cần nhìn xa hơn lớp bán hàng: đơn đi vào kho ra sao, tồn được giữ lúc nào, ai kiểm hàng và báo cáo vận hành có truy vết được lỗi hay không.

Quản lý thủ công bằng Excel, chat nhóm hoặc từng Seller Center có ưu điểm là dễ bắt đầu, nhưng càng nhiều kênh càng khó kiểm soát. Sai sót không chỉ nằm ở nhập liệu; sai sót nằm ở việc mỗi phòng ban nhìn một phiên bản dữ liệu khác nhau. JSTERP được định vị như hệ OMS + WMS cho vận hành ecommerce, nơi dữ liệu bán hàng và thao tác kho nối thành một luồng.

• Nếu chỉ cần đăng sản phẩm và xử lý đơn ít, công cụ nhẹ có thể đủ.
• Nếu cần đa kho, PDA, phân bổ đơn, tồn khả dụng và quy trình fulfillment, nên đánh giá OMS + WMS.
• Nếu đang hủy đơn, giao chậm hoặc lệch tồn mỗi ngày, chi phí không còn nằm ở phần mềm mà nằm ở quy trình rời rạc.

Lộ trình triển khai thực tế cho doanh nghiệp Việt Nam

Doanh nghiệp không cần bật toàn bộ hệ thống trong một lần. Với Bàn giao ca kho trong WMS, lộ trình hợp lý là bắt đầu từ khảo sát kênh bán, số đơn/ngày, số SKU, số kho, tình trạng barcode, nhóm lỗi hiện tại và năng lực đội vận hành. Sau đó mới chọn phạm vi OMS, WMS hoặc OMS + WMS.

Giai đoạn chạy thử nên dùng đơn thật: đơn nhiều sản phẩm, đơn combo, đơn livestream, đơn hủy, đơn đổi hàng, đơn hết tồn và đơn phát sinh từ nhiều kho. Khi các tình huống này chạy ổn, go-live mới có ý nghĩa. Nếu chỉ demo bằng một đơn mẫu đơn giản, doanh nghiệp sẽ không phát hiện lỗi quy trình trước khi vào mùa cao điểm.

• Khảo sát dữ liệu: kênh bán, SKU, mã vạch, tồn đầu kỳ và kho.
• Cấu hình quy trình: giữ tồn, phân đơn, picking, checking, packing, hoàn hàng.
• Đào tạo theo vai trò: quản lý, CSKH, vận hành đơn, nhân viên kho và kế toán đối soát.

Checklist trước khi trao đổi demo

• Liệt kê các ca làm, ca trưởng, thời điểm cut-off và hãng vận chuyển thường nhận hàng.
• Chuẩn hóa mã vị trí cho khu chờ picking, checking, packing, staging, hàng hoàn và ngoại lệ.
• Định nghĩa trạng thái đơn và trạng thái tồn cần xuất hiện trong biên bản bàn giao ca.
• Chuẩn bị ví dụ đơn thật: đơn thiếu SKU, đơn packing dở, đơn hủy sau đóng gói, hàng hoàn chờ QC và kiện chưa bàn giao.
• Chọn chỉ số nghiệm thu: đơn treo cuối ca, ngoại lệ quá SLA, kiện còn staging, lỗi truy trách nhiệm và thời gian ca sau bắt đầu xử lý.

JSTERP có thể hỗ trợ như thế nào?

JSTERP hỗ trợ bàn giao ca kho bằng cách nối OMS và WMS trong cùng một luồng vận hành. OMS cho biết đơn đến từ kênh nào, deadline nào, trạng thái thanh toán và COD ra sao; WMS cho biết hàng đang ở vị trí nào, nhân viên nào đã thao tác, bước nào còn dang dở và ngoại lệ nào cần xử lý tiếp.

Đội triển khai JST ERP Việt Nam có thể khảo sát layout kho, ca làm, kênh bán, hãng vận chuyển, mã vị trí, SKU, barcode và quy trình hiện tại để thiết kế checklist bàn giao ca phù hợp. Doanh nghiệp có thể bắt đầu từ các điểm đau lớn nhất như đơn treo cuối ca, kiện staging bị sót, hàng hoàn chưa phân loại hoặc ngoại lệ thiếu hàng bị xử lý bằng chat.

Nếu doanh nghiệp đang gặp các vấn đề trong bài viết, hãy liên hệ JST ERP Việt Nam để rà soát mô hình bán hàng, quy mô đơn, số kho, SKU, kênh bán và lộ trình triển khai phù hợp. Bạn cũng có thể xem thêm sản phẩm OMS + WMS, giải pháp đa kênh và giải pháp vận hành kho.