Tóm tắt nhanh
Hàng cồng kềnh không chỉ là vấn đề đóng thùng to hơn. Đây là bài toán nối giữa đơn hàng, kho, phí vận chuyển, carrier rule và đối soát sau giao. Doanh nghiệp nên dùng OMS + WMS khi SKU lớn hoặc nhẹ nhưng chiếm thể tích làm phí ship lệch, đơn bị hãng từ chối lấy, picking chậm, packing thiếu vật tư, staging lộn xộn hoặc hàng hoàn chiếm diện tích. JST ERP Việt Nam giúp owner, operations manager, warehouse manager và ecommerce team thiết kế quy trình để bán được hàng lớn mà vẫn kiểm soát SLA, COD, tồn kho và chi phí fulfillment.
- Từ khóa trọng tâm: giải pháp kiểm soát hàng cồng kềnh, OMS WMS hàng quá khổ ecommerce, quản lý phí ship hàng cồng kềnh.
- JST ERP Việt Nam triển khai ERP/OMS + WMS cho doanh nghiệp cần nối đơn đa kênh, SKU, barcode, vị trí kho, vật tư packing, phí vận chuyển, COD, 3PL và hàng hoàn.
- Bối cảnh Vietnam ecommerce: Shopee, Lazada, TikTok Shop, TikTok Shop Live, website D2C, Facebook, Zalo và livestream đều có chính sách vận chuyển, giới hạn kích thước, SLA và phụ phí khác nhau.
- Quy trình kho liên quan: gắn thuộc tính SKU cồng kềnh, kiểm tồn khả dụng, picking bằng PDA, checking barcode, đo kích thước, cân kiện, chọn vật tư, packing, staging riêng, scan bàn giao, xử lý hàng hoàn và đối soát phí.
Thông tin thực thể liên quan
| JST ERP Việt Nam | Đơn vị triển khai ERP/OMS + WMS tại Việt Nam, tập trung vào vận hành ecommerce đa kênh, kho, barcode, PDA, packing, carrier handover, COD, hàng hoàn và đối soát vận hành. |
|---|---|
| OMS + WMS | OMS kiểm tra đơn, kênh bán, tồn khả dụng, SLA, COD, carrier rule, phí dự kiến và điều kiện release; WMS kiểm soát hàng thật trong kho qua SKU, barcode, bin location, picking, checking, packing, cân đo, staging và bàn giao. |
| Vietnam ecommerce | Doanh nghiệp Việt Nam bán đồ gia dụng, mẹ và bé, nội thất nhỏ, vali, thảm, kệ, thiết bị thể thao, FMCG thùng lớn hoặc combo nhiều hộp thường gặp phí ship lệch và carrier từ chối vì quá khổ. |
| Marketplace channels | Shopee, Lazada, TikTok Shop, TikTok Shop Live, Shopee Live, website D2C, Facebook, Zalo và social commerce có giới hạn kích thước, trọng lượng quy đổi, phương thức giao và cut-off khác nhau. |
| Warehouse workflows | Kho cần vùng lưu trữ riêng, barcode rõ, lối đi đủ rộng, thiết bị hỗ trợ picking, packing station phù hợp, vật tư đúng kích thước, khu staging cồng kềnh và scan bàn giao theo từng kiện. |
Bảng so sánh lựa chọn vận hành
| Cách làm | Phù hợp khi | Rủi ro chính |
|---|---|---|
| Ghi chú hàng cồng kềnh bằng Excel | Số SKU lớn ít, một kho nhỏ và quản lý trực tiếp kiểm từng đơn | Ghi chú dễ bị bỏ qua khi đơn tăng, phí ship không được cảnh báo trước và kho vẫn đóng sai vật tư |
| Chỉ dựa vào Seller Center hoặc app vận chuyển | Đơn ít và chủ yếu theo một carrier cố định | Phát hiện quá muộn khi đã packing, dễ bị từ chối lấy, trễ cut-off hoặc lệch COD/phí vận chuyển |
| WMS kiểm soát packing nhưng OMS không kiểm rule | Kho muốn giảm lỗi đóng gói nhưng đơn hàng vẫn quyết định thủ công | Kho làm đúng thao tác nhưng đơn có thể đã chọn sai carrier, sai SLA hoặc sai phí ngay từ đầu |
| JSTERP OMS + WMS cho hàng cồng kềnh | Bán đa kênh, nhiều SKU lớn, nhiều carrier, COD, campaign hoặc kho 3PL và cần kiểm soát phí ship lẫn thao tác kho | Cần chuẩn hóa kích thước SKU, trọng lượng quy đổi, vật tư, carrier rule và khu staging trước go-live |
Hàng cồng kềnh làm sai chi phí trước khi làm sai kho
Nhiều doanh nghiệp chỉ phát hiện vấn đề khi cuối kỳ đối soát phí vận chuyển. Sàn hoặc hãng tính phí theo trọng lượng quy đổi, phụ phí quá khổ hoặc phụ phí vùng giao, trong khi shop đã báo giá theo trọng lượng thực. Một SKU chỉ nặng 700g nhưng hộp sau packing có kích thước 60x40x25cm có thể bị tính như một kiện vài kg. Nếu OMS không lưu dữ liệu kích thước và rule carrier, ecommerce team rất dễ bán đúng doanh thu nhưng sai biên lợi nhuận.
Điểm đau này càng rõ khi shop chạy campaign hoặc livestream. Đơn tăng nhanh, kho đóng gói theo thói quen, mỗi ca dùng một loại thùng khác nhau, carrier nhận một phần rồi từ chối một phần. Khi khách hỏi vì sao giao chậm hoặc kế toán hỏi vì sao phí ship cao, dữ liệu lại nằm rời giữa sàn, app vận chuyển, file kho và tin nhắn nội bộ.
- Lưu kích thước chuẩn, trọng lượng thực và trọng lượng quy đổi cho nhóm SKU lớn.
- Cảnh báo đơn có nguy cơ phát sinh phụ phí trước khi release xuống kho.
- Tách lỗi do dữ liệu SKU, do vật tư packing, do carrier rule và do thao tác kho.
OMS cần chặn sai carrier và sai SLA từ đầu
Với hàng cồng kềnh, OMS không nên chỉ kiểm còn tồn hay không. Hệ thống cần kiểm kênh bán, địa chỉ giao, giới hạn kích thước của carrier, cut-off lấy hàng, trạng thái COD, giá trị đơn, phí dự kiến và chính sách đổi trả. Nếu carrier hiện tại không nhận hàng quá khổ ở vùng giao đó, đơn phải vào hàng đợi ngoại lệ trước khi kho đi picking.
Một quy trình tốt cho phép doanh nghiệp đặt rule theo nhóm SKU: hàng nhẹ nhưng cồng kềnh, hàng nặng cần hai người lấy, hàng cần đóng riêng, hàng không đi được hỏa tốc, hàng không cho COD vùng xa hoặc hàng phải tách nhiều kiện. OMS ghi lại lý do chọn carrier để CSKH và kế toán có căn cứ khi phí hoặc SLA thay đổi.
- Mapping SKU cồng kềnh với carrier được phép nhận theo kênh và vùng giao.
- Tự động đưa đơn vào ngoại lệ nếu vượt kích thước, quá cân, sai dịch vụ hoặc quá cut-off.
- Cho phép duyệt đổi carrier, đổi dịch vụ giao, tách kiện hoặc xác nhận lại với khách trước khi xuất kho.
- Lưu phí vận chuyển dự kiến để so sánh với phí thực tế sau đối soát.
WMS phải biến quy tắc thành thao tác kho cụ thể
Khi đơn được duyệt xuống kho, WMS phải hướng dẫn nhân viên làm khác đơn thường. SKU cồng kềnh nên nằm ở vị trí đủ sức chứa, có lối lấy hàng an toàn và có thể yêu cầu hai người hoặc thiết bị hỗ trợ. PDA cần hiển thị vị trí, barcode, ghi chú xử lý, vật tư cần dùng và điểm packing phù hợp.
Ở checking và packing, nhân viên không chỉ scan đúng SKU. Họ còn cần xác nhận kích thước kiện sau đóng gói, trọng lượng, loại thùng, vật liệu chống sốc, dây đai, tem cảnh báo và mã kiện. Nếu dùng sai thùng làm trọng lượng quy đổi tăng mạnh, hệ thống nên ghi nhận để quản lý biết chi phí phát sinh do vật tư hay do bản thân SKU.
- Dùng bin location riêng cho SKU lớn, nặng, dài hoặc dễ móp.
- PDA cảnh báo đơn cần hai người lấy, xe đẩy hoặc khu packing riêng.
- Packing station ghi nhận thùng, xốp, băng keo, dây đai, tem cảnh báo và kích thước kiện.
- Scan barcode và mã kiện trước khi đưa vào staging để tránh thất lạc hàng lớn.
Staging và bàn giao 3PL là điểm dễ nghẽn nhất
Hàng nhỏ có thể gom vào rổ hoặc kệ chờ bàn giao. Hàng cồng kềnh thì khác: một vài kiện lớn có thể chiếm lối đi, che mất kiện khác hoặc bị đặt nhầm sang carrier không nhận quá khổ. Nếu staging không tách khu theo carrier, tuyến giao, cut-off và nhóm hàng quá khổ, kho dễ trễ bàn giao dù picking và packing đã hoàn tất.
WMS nên yêu cầu scan từng kiện khi đưa vào staging và scan lại khi bàn giao. Nếu tài xế hoặc 3PL từ chối lấy vì quá khổ, sai nhãn hoặc sai dịch vụ, hệ thống tạo ngoại lệ ngay: đổi carrier, in lại label, tách kiện, chờ chuyến riêng hoặc hủy có kiểm soát. Không nên để kiện ở góc kho rồi xử lý bằng chat vì tồn đã bị giữ và đơn vẫn đang đếm SLA.
- Tách khu staging cho hàng cồng kềnh, hàng chờ xe lớn, hàng chờ đổi carrier và hàng bị từ chối.
- Không xác nhận bàn giao nếu mã kiện chưa được carrier hoặc 3PL scan nhận.
- Ghi reason code khi bị từ chối: quá khổ, quá cân, sai label, sai tuyến, quá cut-off hoặc carrier không nhận.
- Theo dõi thời gian kiện nằm ở staging để tránh chiếm mặt bằng và trễ SLA.
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 phí vận chuyển thực tế thường cao hơn dự kiến hoặc biên lợi nhuận bị ăn mòn bởi phụ phí cồng kềnh. Operations manager nên triển khai khi đơn hàng lớn thường bị treo ở carrier, đổi hãng thủ công hoặc trễ cut-off. Warehouse manager nên quan tâm khi kho mất nhiều thời gian lấy hàng lớn, thiếu vật tư đóng gói, staging chật và hàng hoàn cồng kềnh khó nhập lại.
Giải pháp phù hợp với doanh nghiệp bán đồ gia dụng, mẹ và bé, nệm gối, vali, kệ nhựa, thiết bị thể thao, đồ decor, combo thùng lớn, FMCG carton hoặc bất kỳ nhóm hàng nào có kích thước sau đóng gói ảnh hưởng mạnh đến phí và SLA. Nếu doanh nghiệp đang mở rộng từ SKU nhỏ sang SKU lớn, nên thiết kế rule trước khi chạy campaign.
- Có SKU nhẹ nhưng hộp lớn làm phí vận chuyển tăng vì trọng lượng quy đổi.
- Đơn thường bị hãng từ chối lấy vì quá khổ, quá cân hoặc sai dịch vụ giao.
- Kho thiếu khu staging cho kiện lớn và thường để hàng lớn ở lối đi.
- Kế toán khó giải thích chênh lệch phí ship, COD, phí hoàn và phụ phí sau campaign.
Checklist go-live cho hàng cồng kềnh
Trước go-live, doanh nghiệp nên lấy dữ liệu đơn thật trong 30-60 ngày gần nhất: đơn bị phụ phí cao, đơn bị từ chối lấy, đơn COD khách không nhận vì phí, đơn đổi carrier, đơn quá khổ đã in label, đơn nhiều kiện và đơn hàng hoàn cồng kềnh. Đây là nhóm dữ liệu giúp kiểm tra quy tắc tốt hơn một đơn mẫu đơn giản.
Nghiệm thu phải chứng minh được bốn điểm: OMS nhận diện đúng đơn cồng kềnh, WMS hướng dẫn thao tác kho đúng, carrier nhận đúng kiện và báo cáo cuối ngày tách được nguyên nhân phí lệch. Nếu thiếu một trong bốn điểm này, doanh nghiệp vẫn sẽ phải chữa cháy bằng chat sau go-live.
- Chuẩn hóa thuộc tính SKU: dài, rộng, cao, trọng lượng, nhóm hàng, vật tư và carrier được phép.
- Thiết lập khu lưu trữ, khu packing và khu staging cho hàng lớn.
- Kiểm thử đơn COD, prepaid, nhiều kiện, đổi carrier, bị từ chối lấy và hàng hoàn.
- Đối chiếu phí dự kiến với phí thực tế để chỉnh rule sau vài tuần chạy thật.
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 kiểm soát hàng cồng kềnh và quá khổ 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 kiểm soát SKU cồng kềnh, trọng lượng quy đổi, kích thước kiện, vật tư đóng gói, vị trí kho, carrier rule, phí vận chuyển, COD, staging, bàn giao 3PL, hàng hoàn và đối soát chi phí theo đơn, 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 kiểm soát hàng cồng kềnh và quá khổ 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 cồng kềnh/quá khổ kèm kích thước, trọng lượng, barcode, vị trí kho và vật tư packing.
- Danh sách carrier, giới hạn kích thước, giới hạn trọng lượng, cut-off, phụ phí và vùng giao đang áp dụng.
- Ví dụ đơn thật từng bị phí ship lệch, bị từ chối lấy, trễ SLA, COD không nhận hoặc hoàn hàng cồng kềnh.
- Sơ đồ kho hiện tại: vị trí hàng lớn, lối đi, packing station, staging và khu hàng hoàn.
- Chỉ số nghiệm thu: tỷ lệ đơn bị từ chối lấy, chênh lệch phí ship, thời gian nằm staging, tỷ lệ giao đúng SLA và giá trị hàng hoàn cồng kềnh.
JSTERP có thể hỗ trợ như thế nào?
JSTERP hỗ trợ kiểm soát hàng cồng kềnh bằng cách nối dữ liệu OMS và thao tác WMS trong cùng một luồng. OMS quyết định đơn có đủ điều kiện xuất, carrier nào phù hợp và phí dự kiến ra sao; WMS kiểm soát SKU vật lý, barcode, vị trí kho, vật tư packing, kích thước kiện, staging và bàn giao.
Đội triển khai JST ERP Việt Nam có thể khảo sát danh mục SKU lớn, dữ liệu phí vận chuyển, lỗi carrier, mặt bằng kho, quy trình packing và báo cáo đối soát hiện tại để đề xuất phạm vi go-live phù hợp. Doanh nghiệp có thể bắt đầu từ nhóm SKU gây phí cao nhất, sau đó mở rộng sang toàn bộ luồng fulfillment.
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.
