Giải pháp giảm hủy đơn do hết hàng bằng OMS + WMS: bán đúng tồn, giữ đúng hàng, giao đúng SLA

Tóm tắt nhanh

Doanh nghiệp nên dùng OMS + WMS để giảm hủy đơn do hết hàng khi bán trên nhiều kênh, có nhiều SKU, nhiều kho, livestream hoặc campaign làm đơn tăng nhanh. OMS cần biết tồn khả dụng, tồn đã giữ, tồn đang chờ xử lý và chính sách phân bổ theo kênh; WMS cần xác nhận hàng thật trong kho qua barcode, bin location, picking, checking, packing, hàng hoàn và hàng chờ QC. JST ERP Việt Nam có thể hỗ trợ chủ doanh nghiệp, ecommerce team, quản lý vận hành và quản lý kho thiết kế quy trình bán đúng tồn, giữ đúng hàng, xử lý ngoại lệ sớm và nghiệm thu go-live bằng đơn thật.

• Từ khóa trọng tâm: giải pháp giảm hủy đơn do hết hàng, OMS WMS tồn khả dụng ecommerce, giảm hủy đơn Shopee Lazada TikTok.
• JST ERP Việt Nam triển khai ERP/OMS + WMS cho doanh nghiệp ecommerce cần quản lý đơn đa kênh, tồn khả dụng, giữ tồn, phân bổ kho, barcode, PDA, bin location, hàng hoàn, QC, COD, đối soát và go-live theo tình huống vận hành thật.
• Bối cảnh Vietnam ecommerce: Shopee, Lazada, TikTok Shop, TikTok Shop Live, Shopee Live, website D2C, Facebook, Zalo và kênh đại lý có thể cùng bán một SKU trong cùng thời điểm, nhất là khi có campaign hoặc livestream.
• Quy trình kho liên quan: đồng bộ tồn, giữ tồn theo đơn, scan barcode khi picking, kiểm tra vị trí kho, tách hàng chờ QC khỏi tồn bán được, xử lý thiếu hàng, đổi kho, thay SKU, hủy một phần và cập nhật tồn sau packing.

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

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

Vì sao doanh nghiệp vẫn hủy đơn dù nhìn trên hệ thống còn tồn?

Tồn tổng không phải là tồn bán được. Một SKU có thể đang nằm ở khu chờ QC, đã được giữ cho đơn khác, đang trong thùng packing, nằm sai vị trí, bị khóa do hàng lỗi, đang trên đường chuyển kho hoặc vừa được bán trong livestream nhưng chưa đồng bộ về sàn. Nếu hệ thống chỉ hiển thị một con số tồn kho, nhân viên bán hàng và marketplace có thể tiếp tục nhận đơn trong khi kho thật không còn hàng sẵn sàng xuất.

Trong vận hành ecommerce, vấn đề thường nằm ở khoảng trễ giữa đơn hàng và kho. Đơn từ Shopee, Lazada, TikTok Shop, website và social commerce đi vào các luồng khác nhau; kho chỉ phát hiện thiếu khi picking. Lúc đó đã quá muộn: CSKH phải xin lỗi khách, shop có nguy cơ bị tính lỗi hủy đơn, còn quản lý không biết nguyên nhân nằm ở đồng bộ tồn, quy trình giữ tồn hay thao tác kho.

• Tồn khả dụng phải loại trừ hàng đã giữ, hàng lỗi, hàng chờ QC, hàng đang packing và hàng không đúng vị trí xuất.
• Đơn đa kênh cần đi qua một OMS trung tâm trước khi đẩy nhiệm vụ xuống kho.
• Thiếu hàng tại bước picking phải trở thành ngoại lệ có nguyên nhân, không chỉ là ghi chú trong chat.

OMS giữ tồn theo đơn và ưu tiên đúng kênh

OMS là lớp quyết định một đơn có được nhận, giữ tồn, chuyển kho hoặc đưa vào ngoại lệ hay không. Khi đơn phát sinh, hệ thống cần kiểm tồn khả dụng theo SKU, kho, kênh bán, chính sách ưu tiên và thời hạn SLA. Nếu tồn thấp, OMS có thể giữ hàng cho đơn đã thanh toán trước, ưu tiên đơn có deadline gần, hoặc chặn nhận thêm đơn từ kênh có rủi ro hủy cao.

Với campaign và livestream, quy tắc giữ tồn càng quan trọng. Doanh nghiệp có thể dành một phần tồn cho TikTok Shop Live, một phần cho Shopee, một phần cho website D2C, hoặc cho phép OMS gom lại nếu kênh này bán chậm. Không có quy tắc rõ, đội vận hành dễ giữ hàng bằng miệng: một người nói để cho livestream, một người khác lại xuất cho đơn sàn.

• Thiết lập tồn khả dụng theo kênh, kho, nhóm SKU và thời gian campaign.
• Giữ tồn ngay khi đơn đủ điều kiện xử lý, trả tồn tự động khi đơn hủy hoặc quá hạn.
• Tách trạng thái: chờ thanh toán, đã giữ tồn, chờ phân kho, thiếu hàng, chờ CSKH xác nhận, hủy một phần.

WMS xác nhận hàng thật bằng barcode và vị trí kho

OMS có thể giữ tồn, nhưng WMS mới xác nhận hàng thật có nằm đúng vị trí và đủ điều kiện xuất hay không. Khi nhân viên picking scan barcode tại bin location, hệ thống kiểm SKU, số lượng, lô hàng nếu có, trạng thái QC và đơn được phân bổ. Nếu lấy sai mã, sai vị trí hoặc thiếu số lượng, WMS phải chặn tại điểm thao tác thay vì để lỗi đi tới packing.

Với kho nhiều khu vực, cùng một SKU có thể nằm ở khu bán được, khu chờ kiểm, khu hàng hoàn, khu hàng lỗi và khu hàng đang chờ chuyển. Nếu các khu này không có trạng thái tồn riêng, báo cáo tồn sẽ đẹp nhưng đơn vẫn bị hủy. WMS cần tách tồn theo trạng thái và chỉ cho OMS bán phần tồn đủ điều kiện xuất.

• Scan barcode khi picking và checking để chặn lấy nhầm SKU hoặc nhầm biến thể.
• Quản lý bin location giúp biết hàng nằm ở đâu, không chỉ biết tổng còn bao nhiêu.
• Hàng hoàn, hàng chờ QC và hàng lỗi không được cộng vào tồn khả dụng trước khi được duyệt.

Xử lý ngoại lệ trước khi phải hủy đơn

Không phải đơn thiếu hàng nào cũng phải hủy ngay. Nếu OMS + WMS có dữ liệu đủ rõ, doanh nghiệp có thể chuyển đơn sang kho khác, tách giao một phần, đề xuất SKU thay thế, đợi hàng nhập trong ngày, đổi hãng vận chuyển hoặc ưu tiên picking lại từ khu dự trữ. Điều quan trọng là ngoại lệ phải xuất hiện sớm, có người chịu trách nhiệm và có thời hạn xử lý.

Một quy trình tốt sẽ không để nhân viên kho tự quyết trong im lặng. Khi thiếu hàng tại vị trí, WMS tạo ngoại lệ; OMS hiển thị ảnh hưởng tới SLA, kênh bán, COD, điểm shop và khách hàng. CSKH có dữ liệu để gọi khách nếu cần, quản lý kho kiểm tra vị trí hoặc điều chuyển, còn ecommerce team biết có nên dừng bán SKU đó trên sàn hay không.

• Tạo reason code cho thiếu hàng: lệch tồn, sai vị trí, hàng chờ QC, bán vượt tồn, chưa nhập hàng, mất hàng.
• Cho phép đổi kho, giữ lại đơn, tách đơn hoặc thay SKU theo quyền duyệt rõ ràng.
• Tự động giảm hoặc khóa tồn bán trên kênh khi phát hiện thiếu hàng lặp lại.

Go-live cần kiểm bằng đơn thật, không chỉ kiểm màn hình tồn kho

Triển khai giảm hủy đơn do hết hàng không thể nghiệm thu bằng một đơn mẫu đơn giản. Doanh nghiệp nên dùng dữ liệu thật: SKU bán chạy, combo, biến thể màu size, đơn livestream, đơn COD, đơn từ nhiều sàn, đơn bị hủy, đơn hoàn chưa QC, đơn chuyển kho và đơn thiếu hàng trong quá khứ. Chỉ khi các tình huống này chạy được, hệ thống mới đủ sức đi vào mùa cao điểm.

Trước go-live, đội triển khai cần đối chiếu tồn đầu kỳ, mapping SKU giữa sàn và kho, barcode, vị trí, trạng thái hàng, quy tắc giữ tồn, lịch đồng bộ, quyền xử lý ngoại lệ và báo cáo hủy đơn. Nếu thiếu bước này, doanh nghiệp có thể có phần mềm mới nhưng vẫn vận hành bằng cách hỏi nhau trong nhóm chat khi có lỗi.

• Chạy thử với SKU bán chạy, SKU có nhiều biến thể, combo và đơn nhiều kho.
• Kiểm tra đồng bộ tồn hai chiều giữa OMS, WMS và marketplace trước ngày mở bán lớn.
• Đặt chỉ số nghiệm thu: tỷ lệ hủy do hết hàng, thời gian phát hiện thiếu hàng, độ lệch tồn và số ngoại lệ xử lý trong SLA.

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

Chủ doanh nghiệp nên triển khai khi hủy đơn do hết hàng bắt đầu ảnh hưởng doanh thu, điểm shop hoặc khả năng tham gia campaign. Ecommerce team nên dùng khi phải bán cùng một SKU trên Shopee, Lazada, TikTok Shop, livestream, website và đại lý nhưng không chắc tồn còn bao nhiêu là bán được. Quản lý kho nên dùng khi nhân viên thường phát hiện thiếu hàng ở bước picking hoặc packing.

Giải pháp này đặc biệt phù hợp với doanh nghiệp có tốc độ đơn tăng nhanh, nhiều SKU biến thể, nhiều kho, kho 3PL, hàng hoàn nhiều, sản phẩm cần barcode chặt hoặc có mùa cao điểm như 6.6, 7.7, 9.9, 11.11, 12.12. Khi doanh nghiệp càng bán đa kênh, việc giảm hủy đơn không còn là việc của riêng kho mà là bài toán OMS + WMS + quy trình vận hành.

• Tỷ lệ hủy do hết hàng cao hoặc thường tăng mạnh sau campaign và livestream.
• Cùng một SKU được bán trên nhiều marketplace, website, social commerce và đại lý.
• Kho có hàng chờ QC, hàng hoàn, hàng lỗi, hàng chuyển kho nhưng chưa tách trạng thái tồn rõ ràng.

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 giảm hủy đơn do hết hàng 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 giảm hủy đơn do hết hàng, giữ tồn theo đơn, đồng bộ tồn khả dụng giữa Shopee, Lazada, TikTok Shop, livestream, website, kho nội bộ, kho 3PL, hàng chờ QC, hàng hoàn, đơn lỗi và phân bổ kho theo SLA, 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 giảm hủy đơn do hết hàng 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 chạy, SKU nhiều biến thể, combo và mã barcode đang dùng trên kho và marketplace.
• Tồn đầu kỳ theo kho, vị trí, trạng thái: bán được, đã giữ, chờ QC, hàng hoàn, hàng lỗi, đang chuyển kho.
• Ví dụ đơn thật gồm đơn campaign, livestream, COD, đơn nhiều kho, đơn thiếu hàng, đơn hủy một phần và đơn trả tồn.
• Quy tắc giữ tồn theo kênh, ưu tiên SLA, trả tồn khi hủy, khóa tồn khi lệch và quyền xử lý ngoại lệ.
• Báo cáo hiện tại về tỷ lệ hủy do hết hàng, độ lệch tồn, thời gian xử lý thiếu hàng và số lần điều chỉnh tồn thủ công.

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

JSTERP hỗ trợ giảm hủy đơn do hết hàng bằng cách nối OMS và WMS trong cùng một luồng vận hành. OMS kiểm soát đơn đa kênh, tồn khả dụng, giữ tồn, phân bổ kho và ngoại lệ; WMS kiểm soát hàng thật bằng barcode, vị trí kho, PDA, picking, checking, packing và trạng thái tồn sau mỗi thao tác.

Đội triển khai JST ERP Việt Nam có thể cùng doanh nghiệp rà soát kênh bán, SKU, kho, dữ liệu tồn, lịch đồng bộ, quy trình giữ tồn và các lỗi hủy đơn hiện tại. Từ đó, doanh nghiệp có thể chọn phạm vi triển khai phù hợp: bắt đầu từ OMS nếu điểm đau nằm ở đồng bộ đơn và giữ tồn, hoặc triển khai OMS + WMS nếu kho là nơi phát sinh nhiều thiếu hàng, sai vị trí và lệch tồ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.