Giải pháp cảnh báo tồn kho và đề xuất nhập hàng bằng OMS + WMS: không hết SKU bán chạy, không ôm hàng chậm

Tóm tắt nhanh

Doanh nghiệp nên dùng OMS + WMS để cảnh báo tồn kho và đề xuất nhập hàng khi bán đa kênh, nhiều SKU, có campaign, livestream hoặc lead time nhập hàng không ổn định. Hệ thống cần tách tồn vật lý, tồn khả dụng, tồn giữ theo đơn, tồn an toàn, hàng chờ QC và hàng đang điều chuyển; sau đó kết hợp tốc độ bán, đơn chờ, lịch sale, thời gian nhập hàng và MOQ nhà cung cấp để cảnh báo tồn thấp hoặc đề xuất nhập. JST ERP Việt Nam phù hợp cho chủ doanh nghiệp, operations manager, ecommerce team, quản lý kho và mua hàng muốn giảm hết hàng SKU bán chạy nhưng không ôm quá nhiều hàng chậm bán.

• Từ khóa trọng tâm: giải pháp cảnh báo tồn kho, đề xuất nhập hàng OMS WMS, cảnh báo tồn thấp ecommerce.
• 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 tồn khả dụng, kho, vị trí, PDA, barcode, hàng hoàn, campaign và kế hoạch nhập hàng.
• Bối cảnh Vietnam ecommerce: Shopee, Lazada, TikTok Shop, TikTok Shop Live, Shopee Live, website D2C, Facebook, Zalo và livestream tạo biến động nhu cầu rất nhanh theo voucher, flash sale, affiliate và khung giờ live.
• Quy trình kho liên quan: tồn vật lý, tồn khả dụng, tồn giữ đơn, safety stock, reorder point, lead time, purchase suggestion, transfer suggestion, replenishment fast-pick, cycle count và QC hàng hoà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 cảnh báo tồn thấp không thể chỉ dựa vào số lượng tồn?

Một SKU còn 200 sản phẩm có thể là an toàn nếu bán 5 sản phẩm/ngày, nhưng rất rủi ro nếu đang vào chiến dịch TikTok Shop và bán 120 sản phẩm/ngày. Ngược lại, một SKU còn 30 sản phẩm chưa chắc cần nhập nếu đã bán chậm 60 ngày, nhiều hàng hoàn chưa QC và mùa nhu cầu đã qua. Vì vậy ngưỡng tồn thấp phải gắn với tốc độ bán, lead time và kế hoạch bán hàng.

OMS giúp đọc nhu cầu từ đơn thật: đơn đã thanh toán, đơn COD chờ xác nhận, đơn giữ tồn, đơn campaign, đơn livestream và đơn đang có nguy cơ hủy. WMS giúp xác nhận phần tồn nào thật sự bán được: hàng ở vị trí bán, hàng đang chờ QC, hàng lỗi, hàng hoàn, hàng đang điều chuyển hoặc hàng nằm ở bulk chưa được bổ sung vào fast-pick.

• Tồn cảnh báo phải dựa trên tồn khả dụng, không chỉ tồn vật lý.
• Ngưỡng nhập lại nên thay đổi theo tốc độ bán, lead time và lịch campaign.
• SKU bán chậm cần cảnh báo ngược: không nhập thêm dù tồn đang thấp về số lượng.

Dữ liệu nào cần có trước khi hệ thống đề xuất nhập hàng?

Đề xuất nhập hàng tốt bắt đầu từ dữ liệu nền. SKU phải được chuẩn hóa giữa kênh bán, combo, barcode và mã nội bộ. Lead time nhà cung cấp cần được ghi nhận theo thực tế: thời gian đặt hàng, xác nhận, vận chuyển, nhận hàng, QC và putaway. Nếu chỉ dùng lead time lý thuyết, hệ thống sẽ đề xuất quá muộn trong mùa cao điểm.

Doanh nghiệp cũng cần xác định MOQ, bội số đặt hàng, hạn sử dụng, batch, hàng dễ lỗi, hàng cồng kềnh và khả năng lưu kho. Một SKU bán nhanh nhưng chiếm nhiều diện tích hoặc có hạn sử dụng ngắn không nên nhập bằng cùng công thức với phụ kiện nhỏ không có hạn.

• Chuẩn hóa SKU, barcode, combo và mapping kênh bán trước khi bật đề xuất.
• Lưu lead time thực tế theo nhà cung cấp, nhóm hàng và mùa campaign.
• Tách MOQ, bội số nhập, hạn sử dụng, dung lượng kho và mức tồn an toàn theo từng nhóm SKU.

OMS tính nhu cầu như thế nào trong bán đa kênh?

OMS không nên chỉ cộng doanh số 30 ngày rồi chia trung bình. Với ecommerce Việt Nam, tốc độ bán theo ngày thường, ngày sale, livestream và affiliate có thể khác nhau hoàn toàn. Một SKU có thể bán ít trên Lazada nhưng bùng trên TikTok Shop Live; một combo có thể bán chạy trong live nhưng SKU thành phần lại đang thiếu vì cùng lúc chạy Shopee flash sale.

Cách hợp lý là tính nhu cầu theo lớp: tốc độ bán nền, đơn đang giữ tồn, đơn chờ xác nhận, đơn đã vào campaign, lịch livestream, tồn an toàn và đơn có khả năng hủy. OMS cần cho quản lý nhìn thấy vì sao hệ thống đề xuất nhập 500 thay vì 200: do lead time 7 ngày, campaign sắp tới, tốc độ bán tăng và tồn khả dụng thực tế chỉ còn sau khi trừ đơn đã giữ.

• Tính riêng tốc độ bán nền và tốc độ bán trong campaign/livestream.
• Trừ tồn đã giữ cho đơn và tồn không bán được trước khi tính nhu cầu.
• Cho phép người mua xem lý do đề xuất để không biến hệ thống thành hộp đen.

WMS xác nhận tồn thật trước khi nhập thêm

Một cảnh báo nhập hàng có thể sai nếu kho chưa sạch. Có những SKU hệ thống báo thấp nhưng thực tế còn hàng ở bulk storage, hàng mới nhập chưa putaway, hàng hoàn chưa QC hoặc hàng đặt sai vị trí. Trước khi đặt mua, WMS nên giúp kho kiểm tra nhanh vị trí, trạng thái và khả năng bổ sung hàng.

Với SKU nhóm A, hệ thống có thể đề xuất hai hành động khác nhau: nếu tổng tồn còn nhưng pick face sắp hết, tạo nhiệm vụ replenishment từ bulk sang fast-pick; nếu toàn bộ tồn khả dụng thật sự thấp so với tốc độ bán và lead time, tạo đề xuất nhập hàng. Tách được hai tình huống này giúp doanh nghiệp không nhập thêm chỉ vì vị trí picking đang trống.

• Kiểm tra tồn theo vị trí, không chỉ tồn tổng.
• Tạo cycle count nhanh cho SKU có chênh lệch trước khi duyệt nhập số lượng lớn.
• Tách cảnh báo replenishment nội bộ khỏi đề xuất mua hàng từ nhà cung cấp.

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

Chủ doanh nghiệp nên dùng giải pháp này khi doanh thu bị mất vì SKU bán chạy hết hàng, nhưng dòng tiền lại bị kẹt ở nhiều SKU chậm bán. Operations manager nên dùng khi đội sale, mua hàng và kho thường tranh luận số nào là đúng: tồn trên sàn, tồn ERP, tồn trong kho hay tồn Excel. Quản lý kho nên dùng khi tổng tồn còn nhưng vị trí picking hết hàng, hàng hoàn chưa QC hoặc kiểm kê phát hiện lệch lặp lại.

Ecommerce team nên đặc biệt quan tâm trước các mùa sale như 9.9, 10.10, 11.11, 12.12, Tết, livestream lớn hoặc campaign affiliate. Đây là lúc quyết định nhập hàng muộn vài ngày có thể khiến SKU hot hết hàng, còn nhập theo cảm xúc lại dễ tạo tồn chết sau chiến dịch.

• Có nhiều SKU, nhiều kênh bán và nhu cầu biến động mạnh theo campaign.
• Thường hủy đơn do hết hàng hoặc phải xin khách đổi sản phẩm bán chạy.
• Có kho riêng, hàng hoàn, vị trí fast-pick/bulk và cần phân biệt bổ sung nội bộ với nhập thêm từ nhà cung cấp.

Quy trình duyệt đề xuất nhập hàng nên thiết kế ra sao?

Hệ thống nên đề xuất, nhưng quyết định cuối vẫn cần quyền duyệt phù hợp. Với SKU giá trị thấp và bán đều, doanh nghiệp có thể cho phép đề xuất tự động tạo phiếu mua nháp. Với SKU giá trị cao, hàng hạn sử dụng, hàng theo mùa hoặc SKU đang có tồn chậm, hệ thống nên yêu cầu quản lý duyệt và hiển thị cảnh báo rủi ro.

Mỗi đề xuất nên có đủ dữ liệu: tồn khả dụng, tồn vật lý, tồn giữ đơn, hàng chờ QC, tốc độ bán 7/14/30 ngày, tốc độ campaign, lead time, MOQ, số lượng đề xuất, ngày dự kiến hết hàng và ngày dự kiến hàng về. Khi người duyệt thay đổi số lượng, lý do cũng nên được lưu lại để cải thiện công thức sau vài vòng vận hành.

• Tạo phiếu đề xuất nhập theo SKU, nhà cung cấp, lead time và mức độ ưu tiên.
• Lưu lý do duyệt, giảm số lượng hoặc từ chối để cải tiến rule.
• Đo sau nhập: SKU có hết hàng không, có nhập dư không, lead time thực tế có lệch không.

Checklist go-live cho cảnh báo tồn kho và đề xuất nhập

Trước go-live, doanh nghiệp nên chạy thử bằng nhóm SKU thật: SKU bán nhanh, SKU bán chậm, SKU theo mùa, combo, SKU có hàng hoàn nhiều và SKU có lead time dài. Nếu chỉ test bằng một sản phẩm đơn giản, hệ thống sẽ không lộ ra lỗi mapping, lỗi tồn giữ đơn hoặc lỗi hàng chờ QC.

Sau go-live, cần theo dõi trong vài tuần đầu để chỉnh ngưỡng. Một số SKU cần tồn an toàn cao hơn vì nhà cung cấp giao chậm; một số SKU cần giảm đề xuất vì campaign không lặp lại; một số SKU cần chuyển vị trí kho trước khi nhập thêm. Đây là quá trình tối ưu vận hành, không phải một công thức cố định mãi mãi.

• Đối chiếu SKU, barcode, combo, tồn đầu kỳ và tồn theo vị trí.
• Nhập lead time, MOQ, bội số đặt hàng, tồn an toàn và lịch campaign mẫu.
• Test đề xuất với SKU bán nhanh, SKU chậm bán, SKU có hàng hoàn và SKU nhiều 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ủ đề giải pháp cảnh báo tồn kho và đề xuất nhập hàng, đ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 đọc tốc độ bán theo kênh, tồn khả dụng, tồn giữ theo đơn, hàng hoàn chờ QC, lead time nhà cung cấp, lịch campaign, ngưỡng tồn thấp, nhu cầu điều chuyển kho, replenishment fast-pick và quyết định nhập hàng trước khi SKU bán chạy hết hàng hoặc SKU chậm bán bị nhập dư, 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 cảnh báo tồn kho và đề xuất nhập hàng, 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ê 20 SKU bán chạy nhất, 20 SKU thường hết hàng và 20 SKU đang tồn chậm.
• Chuẩn bị dữ liệu bán theo kênh: Shopee, Lazada, TikTok Shop, livestream, website và social commerce.
• Kiểm tra tồn vật lý, tồn khả dụng, tồn giữ theo đơn, hàng chờ QC và hàng đang điều chuyển.
• Cập nhật lead time nhà cung cấp, MOQ, bội số nhập, hạn sử dụng và dung lượng kho.
• Định nghĩa chỉ số nghiệm thu: giảm hủy do hết hàng, giảm tồn chết, tăng tỷ lệ SKU hot có hàng trước campaign.

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

JSTERP hỗ trợ cảnh báo tồn kho và đề xuất nhập hàng bằng cách nối dữ liệu OMS và WMS. OMS đọc đơn đa kênh, tốc độ bán, campaign và tồn giữ; WMS kiểm soát tồn thật theo kho, vị trí, trạng thái, barcode, PDA, hàng hoàn và replenishment.

Đội triển khai JST ERP Việt Nam có thể khảo sát số SKU, số đơn/ngày, kênh bán, lead time nhà cung cấp, dữ liệu tồn hiện tại và lỗi hết hàng/tồn chậm để thiết kế quy tắc cảnh báo phù hợp. Doanh nghiệp có thể bắt đầu với nhóm SKU trọng điểm, sau đó mở rộng sang toàn bộ danh mục khi dữ liệu đã sạch hơ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.