Giải pháp replenishment fast-pick trước giờ cao điểm bằng OMS + WMS: không để đơn nóng chờ hàng từ khu bulk

Tóm tắt nhanh

Replenishment fast-pick là điểm nối giữa kế hoạch bán hàng và năng lực kho. Doanh nghiệp nên dùng OMS + WMS khi báo cáo tổng tồn vẫn còn nhưng vị trí fast-pick thường trống, nhân viên phải đi xa để lấy hàng, đơn livestream bị nghẽn trước cut-off hoặc SKU hot bị giữ tồn mà chưa sẵn sàng xuất. JST ERP Việt Nam giúp owner, operations manager, warehouse manager và ecommerce team thiết kế quy trình bổ sung hàng trước giờ cao điểm để giảm lỗi picking, giảm trễ packing và giữ SLA trên marketplace.

• Từ khóa trọng tâm: giải pháp replenishment fast-pick, OMS WMS bổ sung hàng trước giờ cao điểm, replenishment từ bulk sang fast-pick ecommerce.
• JST ERP Việt Nam triển khai ERP/OMS + WMS cho doanh nghiệp cần nối đơn đa kênh, tồn khả dụng, barcode, vị trí kho, PDA, wave picking, packing, vận chuyển và hàng hoàn.
• Bối cảnh Vietnam ecommerce: Shopee, Lazada, TikTok Shop, TikTok Shop Live, website D2C, Facebook, Zalo và livestream thường tạo đỉnh đơn ngắn, khiến khu fast-pick hết hàng trước khi tổng kho hết hàng.
• Quy trình kho liên quan: xác định SKU hot, kiểm tồn bulk và fast-pick, tạo task replenishment, scan barcode khi lấy, scan vị trí putaway, mở khóa tồn khả dụng, picking, checking, packing và bàn giao trước cut-off.

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

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

Vì sao còn tồn nhưng kho vẫn xử lý chậm?

Tổng tồn không đủ để vận hành fulfillment. Một SKU có thể còn 500 sản phẩm trong khu bulk nhưng chỉ còn 5 sản phẩm ở vị trí fast-pick. Khi 200 đơn cùng đổ vào sau livestream, hệ thống bán hàng vẫn báo còn tồn, nhưng kho lại không lấy được hàng theo tuyến picking ngắn. Nhân viên phải rời tuyến, đi sang khu bulk, xin mở pallet, lấy thùng, đếm lại, rồi quay về packing. Mỗi lần như vậy làm mất vài phút, nhưng nhân với hàng trăm đơn sẽ thành nghẽn ca.

Nếu doanh nghiệp chỉ nhìn báo cáo cuối ngày, vấn đề bị hiểu nhầm là thiếu nhân sự. Thực tế có thể là thiếu quy tắc replenishment trước giờ cao điểm. Đội kho bận không phải vì đơn quá khó, mà vì hàng bán nhanh chưa nằm ở đúng vị trí để lấy nhanh.

• Tách rõ tồn tổng, tồn bulk, tồn fast-pick, tồn đang giữ cho đơn và tồn đang chuyển vị trí.
• Theo dõi thời gian picker phải rời tuyến để lấy hàng ngoài vị trí fast-pick.
• Đặt ngưỡng cảnh báo theo tốc độ bán, không chỉ theo số lượng tồn còn lại.

OMS phải nhìn nhu cầu trước khi WMS tạo tác vụ

Một replenishment tốt không chỉ dựa vào min-max cố định. OMS cần đọc đơn đã thanh toán, đơn COD đã xác nhận, đơn livestream đang giữ tồn, lịch campaign, tỷ lệ hủy, cut-off vận chuyển và SLA theo kênh. SKU có 100 sản phẩm ở fast-pick có thể đủ trong ngày thường, nhưng không đủ cho 30 phút flash sale nếu tốc độ bán đang tăng nhanh.

Khi OMS xác định nhóm SKU có nguy cơ thiếu ở fast-pick, hệ thống nên tạo gợi ý bổ sung theo mức ưu tiên: SKU nhiều đơn chờ nhất, SKU sắp quá SLA, SKU nằm trong combo bán chạy, SKU có carrier cut-off sớm hoặc SKU được quảng cáo trong phiên live. Quản lý kho có thể duyệt số lượng trước khi WMS phát task cho nhân viên.

• Dùng dữ liệu đơn thật để tính nhu cầu trong 1-3 giờ tới, không chỉ tồn cuối ngày.
• Ưu tiên SKU theo SLA, cut-off, số đơn chờ, lịch live và campaign.
• Không release wave picking lớn nếu fast-pick chưa đủ hàng cho SKU chính.
• Ghi nhận lý do replenishment để sau campaign biết bổ sung đúng hay quá tay.

WMS cần kiểm soát từng bước chuyển từ bulk sang fast-pick

Sau khi có kế hoạch, WMS phải biến replenishment thành thao tác có kiểm soát. Nhân viên nhận task trên PDA, đi tới vị trí bulk, scan bin location, scan barcode hoặc thùng, nhập số lượng, di chuyển hàng và scan vị trí fast-pick khi putaway. Nếu SKU có lô, hạn sử dụng, serial hoặc hàng cần QC, hệ thống phải chặn chuyển sai trạng thái.

Điểm quan trọng là tồn khả dụng chỉ nên mở đúng lúc hàng đã nằm ở vị trí có thể picking. Nếu OMS đã giữ tồn nhưng WMS chưa putaway xong, đơn có thể bị release quá sớm và tiếp tục nghẽn. Với hàng bán nhanh, vài phút sai trạng thái cũng đủ làm cả ca kho phải xử lý ngoại lệ.

• PDA hướng dẫn lấy đúng vị trí bulk và đặt đúng vị trí fast-pick.
• Scan barcode để tránh đưa nhầm biến thể màu, size, combo hoặc lô sản xuất.
• Tách trạng thái: đang chờ bổ sung, đang chuyển vị trí, đã sẵn sàng picking.
• Chặn đưa hàng hoàn chờ QC hoặc hàng lỗi vào fast-pick bán lại.

Thiết kế min-max theo nhịp bán, không theo cảm giác

Nhiều kho đặt min-max theo kinh nghiệm: SKU A luôn để 20 cái, SKU B luôn để 50 cái. Cách này ổn khi nhu cầu ổn định, nhưng ecommerce Việt Nam thường có nhịp bán thay đổi theo ngày lương, campaign 7.7, 8.8, khung giờ live, voucher sàn và ngân sách ads. Một rule tốt cần tính tốc độ bán theo thời điểm, thể tích vị trí, số lần bổ sung tối đa trong ca và công suất packing.

Ví dụ, SKU mỹ phẩm nhỏ có thể đặt fast-pick đủ 300 đơn vì chiếm ít diện tích, trong khi một thùng bỉm lớn chỉ đủ 20 đơn vì vị trí kệ hạn chế. Nếu cả hai dùng cùng một tỷ lệ phần trăm tồn, kho sẽ hoặc thiếu hàng hot, hoặc lãng phí mặt bằng cho SKU chậm.

• Tính min-max theo tốc độ bán, kích thước sản phẩm, dung lượng vị trí và cut-off.
• Đặt rule khác nhau cho ngày thường, campaign, livestream và cuối tuần.
• Theo dõi số lần replenishment mỗi SKU trong ca để phát hiện vị trí quá nhỏ.
• Gắn KPI replenishment với tỷ lệ đơn chờ hàng tại vị trí, không chỉ số task hoàn thành.

Khi nào nên dùng giải pháp này?

Owner nên dùng giải pháp này khi doanh nghiệp không thiếu hàng tổng nhưng vẫn trễ đơn vì hàng không nằm ở đúng vị trí. Operations manager nên triển khai khi mỗi campaign phải lập nhóm chat riêng để nhắc kho bổ sung SKU hot. Warehouse manager nên ưu tiên khi picker thường xuyên rời tuyến, fast-pick trống trong giờ cao điểm, packing chờ hàng hoặc hàng từ bulk được đưa lên kệ không scan rõ.

Giải pháp đặc biệt phù hợp với shop có nhiều SKU bán nhanh theo mùa, nhiều combo, nhiều kênh, livestream đều đặn hoặc có kho lớn tách bulk và fast-pick. Nếu doanh nghiệp chuẩn bị tăng ngân sách ads hoặc mở thêm phiên live, nên thiết kế replenishment trước khi tăng đơn.

• Báo cáo tổng tồn còn nhưng đơn vẫn chậm vì vị trí picking hết hàng.
• SKU hot thay đổi theo campaign, livestream, voucher hoặc ads.
• Kho có khu bulk, khu fast-pick, nhiều ca làm và cần giảm quãng đường picking.
• Đơn Shopee, Lazada, TikTok Shop bị trễ cut-off do chờ chuyển hàng nội bộ.

Checklist go-live cho replenishment fast-pick

Trước go-live, doanh nghiệp nên lấy dữ liệu đơn thật của các ngày cao điểm gần nhất: SKU bán nhanh, giờ phát sinh đơn, số lần picker báo hết kệ, thời gian packing chờ hàng, đơn trễ cut-off, vị trí fast-pick quá tải và SKU bị chuyển nhầm. Những dữ liệu này giúp cấu hình rule đúng hơn một buổi demo đơn giản.

Nghiệm thu nên chạy bằng một kịch bản sát thực tế: đơn đổ vào từ nhiều kênh, OMS giữ tồn, hệ thống tạo gợi ý bổ sung, WMS phát task PDA, nhân viên scan chuyển hàng, tồn fast-pick được mở và wave picking tiếp tục. Nếu thiếu bước đo thời gian chờ hàng, doanh nghiệp sẽ khó biết giải pháp đã thật sự giảm nghẽn hay chỉ thêm một màn hình mới.

• Chuẩn hóa SKU, barcode, đơn vị thùng/lẻ, vị trí bulk, vị trí fast-pick và tồn đầu kỳ.
• Đặt rule min-max theo nhóm SKU, mùa vụ, campaign, livestream và dung lượng vị trí.
• Phân quyền ai được duyệt replenishment khẩn cấp và ai được điều chỉnh tồn.
• Kiểm thử hàng hoàn chờ QC, hàng lỗi, hàng cận date và hàng combo trước khi cho vào fast-pick.

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ủ đề Giải pháp replenishment fast-pick trước giờ cao điểm bằng OMS + 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 dự báo SKU bán nhanh, chuyển hàng từ khu bulk sang fast-pick, giữ tồn khả dụng, ưu tiên wave picking, tránh thiếu hàng tại vị trí lấy, kiểm soát barcode, PDA, cut-off vận chuyển, packing và SLA marketplace, 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 Giải pháp replenishment fast-pick trước giờ cao điểm bằng OMS + 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

• Danh sách SKU bán nhanh theo từng kênh trong 30-60 ngày gần nhất.
• Số lượng tồn bulk, tồn fast-pick, tồn đang giữ cho đơn và tồn đang chuyển vị trí.
• Dữ liệu cut-off vận chuyển, SLA marketplace, lịch livestream và lịch campaign.
• Sơ đồ bin location, dung lượng vị trí, tuyến picking và khu packing.
• Danh sách lỗi hiện tại: hết kệ, nhầm barcode, chuyển sai vị trí, packing chờ hàng và đơn trễ cut-off.

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

JSTERP hỗ trợ replenishment fast-pick bằng cách nối dữ liệu nhu cầu trong OMS với thao tác kho trong WMS. Doanh nghiệp không chỉ biết SKU nào đang bán nhanh, mà còn biết hàng đó đang ở bulk hay fast-pick, đã được giữ cho đơn nào, ai đang chuyển, khi nào sẵn sàng picking và đơn nào có nguy cơ trễ SLA.

Đội triển khai JST ERP Việt Nam có thể khảo sát kênh bán, số đơn/ngày, số SKU, cấu trúc kho, dung lượng vị trí, quy trình PDA, lịch campaign và lỗi vận hành hiện tại để đề xuất phạm vi triển khai. Doanh nghiệp có thể bắt đầu bằng nhóm SKU hot trước, sau đó mở rộng sang toàn bộ khu fast-pick khi dữ liệu đã ổn.

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.