Replenishment trong WMS: bổ sung hàng từ bulk sang fast-pick đúng lúc

Tóm tắt nhanh

Replenishment giúp kho ecommerce không chờ đến lúc vị trí picking trống mới đi tìm hàng. WMS cần theo dõi tồn theo vị trí, đặt ngưỡng min-max cho từng SKU, ưu tiên SKU bán nhanh, tạo nhiệm vụ bổ sung từ bulk storage sang fast-pick và bắt buộc nhân viên quét barcode bằng PDA. OMS bổ sung dữ liệu đơn hàng, campaign, livestream và SLA để biết SKU nào cần ưu tiên trước. Làm đúng, doanh nghiệp giảm đơn treo, giảm tìm hàng thủ công, giữ năng suất picking ổn định và tránh lệch tồn giữa khu lưu trữ và khu xuất hàng.

• Từ khóa trọng tâm: replenishment WMS, bổ sung hàng fast-pick, bulk storage WMS, tối ưu kho ecommerce.
• JST ERP Việt Nam triển khai ERP/OMS + WMS cho doanh nghiệp ecommerce cần kiểm soát đơn hàng, tồn kho, vị trí, PDA, SKU, barcode, picking, checking, packing và báo cáo vận hành.
• Bối cảnh Việt Nam: đơn từ Shopee, Lazada, TikTok Shop, livestream, social commerce, website, đơn COD và campaign có SLA chặt.
• Quy trình kho liên quan: theo dõi tồn pick face, bulk storage, min-max, tạo nhiệm vụ bổ sung, PDA scan vị trí, điều chuyển nội bộ, checking, packing và xử lý ngoại lệ khi thiếu hàng.

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

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

Replenishment khác gì với picking và putaway?

Putaway là đưa hàng vừa nhập vào vị trí lưu trữ. Picking là lấy hàng theo đơn. Replenishment nằm giữa hai bước này: chuyển hàng từ vị trí dự trữ sang vị trí picking để nhân viên lấy hàng nhanh hơn. Nếu thiếu bước này, WMS có thể biết tổng tồn còn 500 sản phẩm nhưng nhân viên picking vẫn gặp vị trí trống.

Trong kho ecommerce, vị trí picking thường gần tuyến đi chính, gần bàn checking/packing và chỉ chứa lượng hàng đủ xử lý trong một khoảng thời gian. Bulk storage chứa thùng lớn, pallet hoặc hàng dự trữ. Replenishment giúp hai khu này phối hợp thay vì để nhân viên picking tự rời tuyến đi tìm hàng ở khu xa.

• Putaway: nhận hàng và cất vào vị trí lưu trữ.
• Replenishment: bổ sung từ bulk storage sang fast-pick hoặc pick face.
• Picking: lấy hàng từ vị trí picking theo đơn hoặc theo wave.

Vì sao tổng tồn còn nhưng đơn vẫn bị treo?

Một lỗi rất hay gặp là quản lý nhìn báo cáo thấy SKU còn 300 sản phẩm, nhưng kho báo không lấy được hàng. Nguyên nhân thường là 300 sản phẩm nằm ở bulk storage, khu chờ kiểm, khu hàng hoàn hoặc vị trí trên cao; còn pick face mà nhân viên được hướng dẫn lấy hàng lại trống. Nếu WMS không phân biệt tồn theo vị trí và trạng thái, đội vận hành sẽ hiểu nhầm là kho làm chậm.

Vấn đề nặng hơn trong campaign. Một SKU nhóm A bình thường bán 50 sản phẩm/ngày nhưng sau phiên TikTok Shop livestream có thể cần xử lý 400 sản phẩm trong vài giờ. Nếu ngưỡng replenishment vẫn để thấp như ngày thường, vị trí picking sẽ hết hàng liên tục, wave picking bị ngắt và bàn packing phải chờ.

• Tồn vật lý không đồng nghĩa với tồn sẵn sàng để picking.
• Tồn ở khu chờ kiểm, hàng lỗi, hàng hoàn hoặc bulk storage không nên bị tính như pick face.
• Ngưỡng bổ sung cần thay đổi theo tốc độ bán, campaign và năng lực từng ca kho.

OMS giúp WMS biết SKU nào cần bổ sung trước

WMS biết hàng đang nằm ở đâu, nhưng OMS biết đơn nào đang chờ SKU nào, kênh nào sắp hết SLA và campaign nào đang đẩy nhu cầu lên. Khi hai lớp này phối hợp, hệ thống có thể ưu tiên replenishment cho SKU đang có nhiều đơn Shopee cần giao trong ngày hoặc SKU TikTok Shop vừa tăng mạnh sau livestream.

Không phải SKU nào gần min cũng cần bổ sung ngay. Nếu SKU bán chậm và chưa có đơn chờ, nhiệm vụ đó có thể xếp sau. Ngược lại, một SKU vừa vượt ngưỡng cảnh báo do đơn live tăng nhanh cần được đẩy vào danh sách ưu tiên để tránh đội picking phải dừng giữa wave.

• OMS cung cấp đơn chờ, SLA, kênh bán, campaign, combo và tốc độ bán gần nhất.
• WMS cung cấp tồn theo vị trí, trạng thái tồn và năng lực bổ sung của từng ca.
• Quy tắc ưu tiên nên kết hợp min-max, số đơn chờ, tốc độ bán và thời hạn bàn giao.

Thiết kế ngưỡng min-max cho fast-pick

Ngưỡng min-max không nên đặt cùng một kiểu cho mọi SKU. SKU nhóm A bán nhanh có thể cần min 80 và max 300 ở pick face; SKU nhóm B có thể chỉ cần min 20 và max 80; SKU nhóm C nên nằm xa hơn hoặc chỉ bổ sung khi có đơn thật. Với hàng cồng kềnh, ngưỡng còn phải tính theo diện tích vị trí, không chỉ theo số lượng.

Một cách làm thực tế là bắt đầu bằng dữ liệu 14-30 ngày gần nhất: số bán trung bình/ngày, số bán trong campaign, thời gian từ tạo nhiệm vụ bổ sung đến hoàn tất, số lượng mỗi thùng và năng lực nhân viên. Sau go-live, quản lý nên điều chỉnh ngưỡng dựa trên lỗi thật: vị trí nào hết hàng quá nhiều, vị trí nào tồn quá đầy, SKU nào nhân viên hay lấy nhầm.

• SKU nhóm A: ngưỡng cao hơn, gần bàn checking/packing và có bổ sung trước campaign.
• SKU dễ nhầm biến thể: không đặt quá sát nhau nếu barcode hoặc bao bì giống nhau.
• SKU cồng kềnh: tính theo không gian vị trí và an toàn thao tác, không chỉ theo số lượng.

PDA phải kiểm soát cả vị trí lấy và vị trí đặt

Replenishment thủ công rất dễ tạo lệch tồn: nhân viên lấy một thùng ở bulk storage, đặt vào pick face nhưng quên cập nhật vị trí; cuối ngày hệ thống vẫn nghĩ hàng ở bulk, còn thực tế hàng đã bán hết ở pick face. Vì vậy PDA cần bắt buộc quét vị trí nguồn, SKU/barcode, số lượng và vị trí đích.

Nếu nhân viên quét sai SKU, sai vị trí hoặc số lượng vượt nhiệm vụ, WMS nên cảnh báo ngay. Với hàng có hạn sử dụng, batch hoặc serial, hệ thống còn cần kiểm tra quy tắc FEFO hoặc truy vết để không đưa lô sai vào vị trí bán được. Một nhiệm vụ replenishment chỉ nên hoàn tất khi cả tồn nguồn và tồn đích được cập nhật đúng.

• Quét vị trí nguồn: ví dụ BULK-A03-02 hoặc PALLET-12.
• Quét SKU/barcode và số lượng theo nhiệm vụ đã tạo.
• Quét vị trí đích: ví dụ PICK-B01-01, sau đó cập nhật tồn pick face.

Replenishment trong mùa sale và livestream

Mùa sale không nên đợi hệ thống báo min rồi mới bổ sung. Trước chiến dịch, OMS có thể dùng lịch campaign và danh sách SKU trọng điểm để đề xuất pre-replenishment: đưa một lượng hàng hợp lý vào fast-pick trước khi đơn tăng. Điều này đặc biệt quan trọng với Shopee flash sale, TikTok Shop livestream và Lazada campaign có khung giờ rõ.

Sau phiên livestream, doanh nghiệp cũng cần kiểm tra tồn còn lại ở pick face. Nếu SKU bán vượt dự kiến, WMS tạo nhiệm vụ bổ sung tiếp; nếu SKU không bán như dự kiến, quản lý có thể trả bớt hàng về bulk storage hoặc chuyển vị trí cho SKU khác đang cần không gian. Replenishment tốt không chỉ là đưa hàng ra, mà còn là giữ layout kho luôn phù hợp với nhu cầu thật.

• Tạo danh sách SKU campaign và ngưỡng replenishment riêng cho từng khung giờ.
• Ưu tiên bổ sung SKU có nhiều đơn đã xác nhận và gần hạn bàn giao.
• Sau campaign, đo lại tồn pick face, hàng dư, lỗi picking và số lần hết vị trí.

Những lỗi thường gặp khi triển khai replenishment

Lỗi đầu tiên là dùng tổng tồn để quyết định bổ sung. Tổng tồn không cho biết hàng đang ở pick face, bulk, QC hay return. Lỗi thứ hai là để nhân viên tự bổ sung bằng kinh nghiệm, không có nhiệm vụ và không có log. Khi sai lệch xảy ra, quản lý không biết hàng mất ở bước điều chuyển, picking hay packing.

Lỗi thứ ba là không gắn replenishment với checking và packing. Nếu pick face được bổ sung sai biến thể, bước checking sẽ phát hiện nhiều lỗi, bàn packing bị chờ và nhân viên phải trả hàng lại vị trí. Vì vậy quy trình replenishment cần được xem như một phần của fulfillment, không phải việc phụ của kho.

• Không dùng tồn tổng thay cho tồn pick face.
• Không để điều chuyển nội bộ đi ngoài WMS hoặc ngoài PDA.
• Không bổ sung hàng chờ kiểm, hàng hoàn chưa QC hoặc hàng lỗi vào vị trí bán được.

Checklist go-live cho replenishment trong WMS

Trước khi go-live, doanh nghiệp nên thử bằng một nhóm SKU bán nhanh. Kịch bản kiểm thử nên có ít nhất: SKU nhóm A sắp hết pick face nhưng bulk còn hàng, SKU nhóm B không cần bổ sung, SKU hàng hoàn chưa được phép bán, SKU có hai biến thể dễ nhầm và một SKU campaign cần bổ sung trước giờ live.

Khi chạy thử, đừng chỉ xem nhiệm vụ có tạo được không. Cần kiểm tra đủ đường đi: OMS đọc đơn và nhu cầu, WMS tạo nhiệm vụ, nhân viên PDA quét đúng, tồn nguồn giảm, tồn đích tăng, picking tiếp tục lấy được hàng, checking không tăng lỗi và báo cáo cuối ca giải thích được số lượng đã bổ sung.

• Chuẩn hóa SKU, barcode, đơn vị thùng/lẻ và bin location trước khi đặt ngưỡng.
• Định nghĩa khu fast-pick, bulk storage, QC, RETURN, DAMAGE và HOLD rõ ràng.
• Chạy thử bằng đơn thật từ Shopee, Lazada, TikTok Shop hoặc livestream trước khi mở rộng toàn kho.

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ủ đề replenishment trong WMS cho kho ecommerce, đ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 tự động phát hiện vị trí picking sắp hết hàng, tạo nhiệm vụ bổ sung từ bulk storage, bắt buộc quét SKU/barcode/vị trí bằng PDA và giữ picking không bị đứt nhịp trong mùa campaign, 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 replenishment trong WMS cho kho ecommerce, 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

• Xuất danh sách SKU bán nhanh, SKU campaign và SKU hay làm wave picking bị chậm.
• Kiểm tra layout kho: vị trí fast-pick, bulk storage, khu QC, khu hàng hoàn và bàn checking/packing.
• Thiết lập ngưỡng min-max theo SKU, tốc độ bán, kích thước hàng và số lượng mỗi thùng.
• Chuẩn bị PDA scan cho vị trí nguồn, SKU/barcode, số lượng và vị trí đích.
• Định nghĩa chỉ số nghiệm thu: số lần hết pick face, thời gian picking, lỗi checking, số nhiệm vụ bổ sung hoàn tất đúng hạn.

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

JST ERP Việt Nam có thể hỗ trợ doanh nghiệp thiết kế replenishment trong mô hình OMS + WMS: từ khảo sát layout kho, chuẩn hóa SKU/barcode, cấu hình vị trí, đặt ngưỡng min-max đến đào tạo nhân viên dùng PDA và đo chỉ số sau go-live.

Đội triển khai có thể bắt đầu bằng một nhóm SKU nhóm A hoặc một khu fast-pick trọng điểm. Khi quy trình chạy ổn, doanh nghiệp mở rộng sang nhiều khu, nhiều kho, nhiều campaign và kết hợp với wave picking, slotting ABC, checking, packing và báo cáo năng suất kho.

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.