Giải pháp điều chuyển tồn sau campaign bằng OMS + WMS: cân bằng kho, giảm tồn chết, chuẩn bị sale tiếp theo

Tóm tắt nhanh

Doanh nghiệp nên dùng OMS + WMS để điều chuyển tồn sau campaign khi bán đa kênh trên Shopee, Lazada, TikTok Shop, livestream, website hoặc có nhiều kho nội bộ/3PL/showroom. Quy trình đúng cần chốt tồn sạch sau sale, tách hàng hoàn chờ QC khỏi tồn khả dụng, phát hiện SKU thiếu cục bộ và SKU dư chậm, tạo transfer order có quyền duyệt, scan xuất - scan nhận - putaway theo bin location, theo dõi tồn đang đi đường và đo hiệu quả trước campaign tiếp theo. JST ERP Việt Nam có thể hỗ trợ owner, operations manager, warehouse manager và ecommerce team thiết kế luồng tái cân bằng tồn để giảm tồn chết, giảm phí lưu kho và tránh bán vượt tồn ở kho sai.

• Từ khóa trọng tâm: giải pháp điều chuyển tồn sau campaign, OMS WMS chuyển kho sau sale, cân bằng tồn kho ecommerce.
• JST ERP Việt Nam triển khai ERP/OMS + WMS cho doanh nghiệp cần kiểm soát đơn đa kênh, tồn kho, kho 3PL, showroom, SKU, barcode, PDA, hàng hoàn, COD và đối soát vận hành.
• Bối cảnh Vietnam ecommerce: Shopee, Lazada, TikTok Shop, TikTok Shop Live, Shopee Live, website D2C, Facebook, Zalo và social commerce thường tạo lệch tồn lớn sau campaign ngắn.
• Quy trình kho liên quan: stock snapshot sau sale, transfer order, PDA picking, barcode checking, packing chuyển kho, hàng đang đi đường, receiving, return QC, putaway và cycle count sau điều chuyển.

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

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

Vì sao sau campaign tổng tồn không còn đủ để ra quyết định?

Tổng tồn chỉ trả lời doanh nghiệp còn bao nhiêu sản phẩm trên toàn hệ thống. Nó không trả lời sản phẩm đang nằm ở kho nào, có bán được ngay không, có bị giữ cho đơn chưa hoàn tất không, có đang ở khu hàng hoàn chờ QC không, hay có nằm tại kho 3PL đang phát sinh phí lưu kho không. Sau campaign, các trạng thái này thường thay đổi rất nhanh.

Ví dụ một SKU mỹ phẩm bán mạnh trên TikTok Shop Live tại TP.HCM nhưng phần tồn còn lại lại nằm ở kho Hà Nội và kho sàn. Nếu OMS tiếp tục đồng bộ tổng tồn cho mọi kênh, kho TP.HCM có thể hết hàng để giao nhanh, trong khi hàng dư ở nơi khác vẫn nằm lâu. Điều chuyển sau campaign phải dựa trên tồn khả dụng theo kho và nhu cầu bán tiếp theo, không dựa trên con số tổng.

• Tồn sau sale cần tách theo kho, trạng thái, kênh bán và khả năng xuất thật.
• Hàng hoàn, hàng lỗi, hàng chờ QC và hàng đang đi đường không nên tính như tồn bán được.
• Quyết định điều chuyển phải xét cả tốc độ bán, phí lưu kho, SLA và kế hoạch campaign mới.

OMS xác định SKU nào nên chuyển, chuyển từ đâu sang đâu

OMS nên đọc dữ liệu sau campaign theo từng SKU: số bán ra, số đơn hủy, số hàng hoàn, tồn khả dụng theo kho, tốc độ bán từng kênh, đơn chờ xử lý, tồn an toàn và lịch campaign sắp tới. Từ đó hệ thống đề xuất SKU cần chuyển về kho gần nguồn cầu, SKU cần đưa khỏi kho 3PL vì phí cao, hoặc SKU cần giữ lại vì còn nhiều đơn hoàn chưa QC.

Không phải SKU nào dư cũng nên chuyển. Một SKU bán chậm ở Shopee nhưng vẫn chạy tốt ở showroom có thể nên giữ tại cửa hàng. Một SKU cồng kềnh có phí vận chuyển nội bộ cao có thể nên xả tại kho hiện tại. Một SKU cận date phải xét hạn dùng và FEFO trước khi đưa sang kho khác. Vì vậy đề xuất điều chuyển cần có lý do, không chỉ có số lượng.

• Tính nhu cầu theo kênh: marketplace, livestream, website, showroom, đại lý và kho 3PL.
• Đề xuất chuyển dựa trên tồn khả dụng, tốc độ bán, phí lưu kho, vị trí khách và campaign sắp tới.
• Tách nhóm không nên chuyển: hàng chờ QC, hàng lỗi, hàng cận date không phù hợp, hàng đã giữ cho đơn.

WMS biến phiếu điều chuyển thành thao tác kho có scan

Khi OMS duyệt điều chuyển, WMS cần tạo transfer order rõ: kho xuất, kho nhận, SKU, barcode, số lượng, bin location lấy hàng, người phụ trách, deadline và phương thức vận chuyển nội bộ hoặc 3PL. Nhân viên kho dùng PDA để picking đúng vị trí, scan barcode SKU, kiểm số lượng và đóng kiện chuyển kho có mã kiện riêng.

Trạng thái “đang điều chuyển” rất quan trọng. Khi hàng đã rời kho A nhưng chưa nhập kho B, OMS không nên coi số lượng đó là tồn khả dụng ở cả hai nơi. Nếu không có trạng thái này, doanh nghiệp dễ bán cùng một sản phẩm hai lần hoặc làm báo cáo tồn đẹp hơn thực tế.

• Transfer order cần có kho xuất, kho nhận, SKU, số lượng, barcode, vị trí, deadline và người duyệt.
• WMS bắt scan xuất kho, scan đóng kiện, scan bàn giao và scan nhận hàng.
• Tồn đang đi đường phải được tách khỏi tồn bán được cho đến khi kho nhận putaway xong.

Kho nhận phải QC và putaway trước khi mở bán lại

Điều chuyển không kết thúc khi xe giao hàng tới kho nhận. Kho nhận cần scan mã kiện, đối chiếu transfer order, kiểm số lượng, barcode, tình trạng bao bì, batch/lot hoặc hạn dùng nếu có. Nếu có lệch số lượng, móp hộp, thiếu phụ kiện hoặc sai SKU, WMS phải tạo ngoại lệ thay vì nhập thẳng vào tồn khả dụng.

Sau khi đạt kiểm tra, WMS mới hướng dẫn putaway về đúng bin location. Với SKU hot chuẩn bị sale mới, hệ thống có thể gợi ý đưa vào fast-pick; với SKU chậm, đưa vào khu lưu trữ phù hợp; với hàng cần kiểm thêm, chuyển sang QC hold. OMS chỉ nên đồng bộ tồn lên kênh bán sau khi trạng thái hàng đã đủ điều kiện xuất.

• Receiving điều chuyển cần đối chiếu mã kiện, SKU, barcode, số lượng và tình trạng hàng.
• Putaway theo bin location giúp kho mới tìm được hàng ngay khi campaign tiếp theo bắt đầu.
• Không mở bán hàng điều chuyển nếu chưa scan nhận, chưa QC hoặc chưa putaway xong.

Khi nào owner, operations manager và warehouse manager nên dùng giải pháp này?

Owner nên quan tâm khi sau campaign doanh thu tăng nhưng tồn còn lại rải rác, phí lưu kho tăng, tiền bị kẹt trong SKU chậm và đợt sale tiếp theo vẫn hay hủy đơn do kho gần khách thiếu hàng. Điều chuyển tồn đúng giúp giảm vốn nằm sai chỗ và tăng khả năng bán tiếp mà không nhập thêm quá sớm.

Operations manager và ecommerce team nên dùng khi phải chuẩn bị nhiều campaign liên tiếp, nhiều livestream hoặc nhiều kênh cùng tranh tồn. Warehouse manager nên dùng khi phiếu chuyển kho hiện tại phụ thuộc vào chat, kho nhận thường không biết hàng về để putaway, hoặc hàng đang đi đường làm báo cáo tồn bị lệch.

• Có nhiều kho nội bộ, kho 3PL, showroom hoặc kho sàn cùng giữ một nhóm SKU.
• Sau sale thường có SKU thiếu cục bộ, SKU dư chậm, hàng hoàn chờ QC hoặc phí lưu kho tăng.
• Cần chuẩn bị tồn cho campaign tiếp theo nhưng không muốn nhập thêm khi hàng còn nằm sai kho.

Checklist go-live cho điều chuyển tồn sau campaign

Trước khi chạy thật, doanh nghiệp nên dùng dữ liệu campaign vừa kết thúc để kiểm thử. Bộ dữ liệu cần có SKU bán nhanh, SKU bán chậm, SKU hoàn nhiều, SKU ở kho 3PL, SKU nằm showroom, hàng chờ QC, hàng đang giữ cho đơn chưa hoàn tất và một vài phiếu chuyển kho có lệch thực tế.

Một luồng điều chuyển chỉ đủ chắc khi đi hết vòng: OMS đề xuất chuyển, quản lý duyệt, WMS scan xuất, tồn chuyển sang đang đi đường, kho nhận scan nhận, QC, putaway, OMS mở tồn khả dụng và báo cáo sau điều chuyển cho thấy tồn theo kho đã khớp. Nếu chỉ tạo phiếu chuyển mà không kiểm kho nhận, dữ liệu vẫn chưa đủ tin cậy.

• Chuẩn hóa mã kho, mã vị trí, SKU, barcode, đơn vị tính và trạng thái tồn.
• Định nghĩa quyền duyệt transfer order, quyền sửa số lượng và quyền xử lý lệch khi kho nhận.
• Đo chỉ số nghiệm thu: thời gian chuyển kho, tỷ lệ lệch nhận hàng, tồn đang đi đường, SKU hết cục bộ và giá trị tồn chậm sau campaign.

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 điều chuyển tồn sau campaign 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 tái cân bằng tồn giữa kho nội bộ, kho 3PL, showroom và marketplace sau campaign; xử lý SKU hot thiếu cục bộ, SKU chậm dư tồn, hàng hoàn chờ QC, phiếu chuyển kho, barcode, bin location, tồn đang đi đường, putaway và chuẩn bị quota cho đợt sale tiếp theo, 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 điều chuyển tồn sau campaign 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 kho nội bộ, kho 3PL, showroom, kho sàn và mã kho đang dùng.
• Báo cáo sau campaign theo SKU: bán ra, hủy, hoàn, tồn khả dụng, tồn chờ QC, tồn ở từng kho và tốc độ bán theo kênh.
• Quy tắc điều chuyển: ngưỡng tồn thấp/cao, phí lưu kho, SLA khu vực, tồn an toàn, SKU không được chuyển và quyền duyệt.
• Sơ đồ bin location tại kho xuất và kho nhận, gồm fast-pick, bulk, QC hold, return, staging và khu hàng đang đi đường.
• Kịch bản kiểm thử: chuyển đủ, chuyển thiếu, sai barcode, hàng móp, hàng hoàn chưa QC, SKU cận date, kho nhận putaway trễ và hủy phiếu chuyển.

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

JSTERP hỗ trợ điều chuyển tồn sau campaign bằng cách nối OMS và WMS trong cùng một luồng dữ liệu. OMS phân tích nhu cầu, tồn khả dụng, campaign và đề xuất điều chuyển; WMS kiểm soát hàng thật bằng transfer order, PDA, barcode, bin location, scan xuất, scan nhận, QC và putaway.

Đội triển khai JST ERP Việt Nam có thể khảo sát mô hình kho, dữ liệu campaign, nhóm SKU hot/chậm, phí 3PL, quy trình hàng hoàn và cách doanh nghiệp chuẩn bị sale tiếp theo. Từ đó doanh nghiệp có thể bắt đầu với một nhóm SKU rủi ro cao, sau đó mở rộng sang nhiều kho, nhiều kênh và dashboard tái cân bằng tồn định kỳ.

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.