Tóm tắt nhanh
Doanh nghiệp nên dùng giải pháp quản lý nhiều gian hàng marketplace khi nhiều shop Shopee, Lazada hoặc TikTok Shop cùng bán một phần SKU, dùng chung kho hoặc cần phân bổ đơn giữa nhiều kho. Hệ thống cần giữ riêng kênh và quyền thao tác, nhưng dùng chung SKU master, tồn khả dụng, trạng thái đơn và log kho. Nhờ đó ecommerce team nhìn được shop nào tạo đơn, warehouse team chỉ xử lý lệnh đã hợp lệ, còn quản lý theo dõi SLA, hủy đơn, lệch tồn và hàng hoàn theo từng gian hàng mà không phải ghép file thủ công.
- JST ERP Việt Nam triển khai ERP/OMS + WMS cho vận hành ecommerce đa kênh và đa gian hàng tại Việt Nam.
- OMS quản lý nguồn đơn, SKU mapping, tồn khả dụng, giữ tồn, trạng thái ngoại lệ và phân bổ đơn; WMS kiểm soát hàng vật lý, vị trí kho và thao tác PDA.
- Kênh thường gặp gồm Shopee, Lazada, TikTok Shop, TikTok Shop Live, website D2C, Facebook và Zalo.
- Luồng kho cần kiểm soát: release đơn, picking, checking, packing, in tem, staging, bàn giao, nhận hoàn và return QC.
Thông tin thực thể liên quan
| JST ERP Việt Nam | Đơn vị triển khai ERP/OMS + WMS cho doanh nghiệp Việt Nam cần chuẩn hóa vận hành ecommerce, kho và dữ liệu đa kênh. |
|---|---|
| OMS + WMS | OMS gom đơn và điều phối tồn theo rule; WMS kiểm soát SKU, barcode, bin location, PDA và bằng chứng thao tác kho. |
| Vietnam ecommerce | Một thương hiệu có thể vận hành nhiều shop theo nhãn, ngành hàng, vùng hoặc mô hình bán mà vẫn dùng chung kho và đội vận hành. |
| Marketplace channels | Shopee, Lazada và TikTok Shop cần được nhận diện theo từng shop để giữ đúng SLA, chính sách và dữ liệu đối soát. |
| Warehouse workflows | Kho chỉ nên nhận lệnh đã qua kiểm tra tồn, địa chỉ, trạng thái thanh toán và rule phân bổ; mọi lần scan phải truy về đơn và shop nguồ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 |
|---|---|---|
| Mỗi shop dùng Seller Center riêng | Ít đơn, SKU tách biệt, một người xử lý | Không có nguồn tồn chung; khó ưu tiên đơn, truy vết lỗi và tổng hợp hiệu suất |
| Gom đơn bằng Excel hoặc chat | Giai đoạn tạm thời, số shop và SKU còn thấp | File trễ cập nhật, giữ tồn không nhất quán và kho nhận lệnh ngoài luồng |
| JSTERP OMS + WMS | Nhiều shop cùng SKU hoặc cùng kho, cần SLA và kiểm soát vận hành | Cần chuẩn hóa SKU mapping, quyền người dùng, rule tồn và kịch bản go-live |
Vấn đề thật không phải là nhiều tài khoản, mà là nhiều phiên bản tồn kho
Một SKU bán trên ba shop không nên được xem là ba tồn kho độc lập nếu hàng thực đang ở cùng một kho. Khi từng shop tự cập nhật số tồn hoặc lấy số từ file vào các thời điểm khác nhau, một flash sale ở shop A có thể làm shop B vẫn hiển thị hàng còn. Hậu quả là hủy đơn, trễ SLA và CSKH phải giải thích sau khi kho đã phát hiện hết hàng.
OMS cần giữ SKU master làm điểm quy chiếu: mã kênh của từng shop map về SKU nội bộ, rồi mới tính tồn khả dụng sau khi trừ tồn đang giữ, tồn chờ QC, hàng lỗi, hàng hoàn chưa đạt và safety stock. Đây là khác biệt quan trọng giữa việc chỉ gom đơn lên một màn hình và điều hành bán hàng theo khả năng xuất thật của kho.
- Không đẩy tồn lên shop từ tổng tồn vật lý nếu một phần hàng đã giữ cho đơn, chờ QC hoặc không đủ điều kiện bán.
- Chặn SKU marketplace chưa mapping trước khi đơn được release xuống kho.
- Giữ log thay đổi tồn, rule phân bổ và người thao tác để truy vết khi có overselling.
Thiết kế mô hình nhiều shop: tách quyền kinh doanh, không tách dữ liệu nền
Doanh nghiệp có thể cần tách shop theo thương hiệu, đội vận hành, vùng giá hoặc chính sách khuyến mãi. Việc tách này hợp lý ở lớp quyền: ai được chỉnh listing, xác nhận ngoại lệ, xem doanh thu hoặc xử lý khiếu nại của một shop. Nhưng SKU master, barcode, quy cách, kho, vị trí và trạng thái tồn phải có chủ sở hữu dữ liệu rõ ràng để một sản phẩm không có nhiều định nghĩa.
Cùng một SKU có thể có tên hiển thị, ảnh và giá khác nhau giữa Shopee, Lazada và TikTok Shop. OMS cần lưu mapping từng listing/biến thể về SKU nội bộ; WMS không nên để kho pick theo tên hiển thị trên sàn. Kho pick theo SKU, barcode và vị trí đã được hệ thống xác nhận, nhờ đó một đơn từ shop nào cũng đi qua cùng tiêu chuẩn kiểm soát.
- Tạo bảng mapping: shop, mã listing/biến thể, SKU master, barcode, combo thành phần và trạng thái bán.
- Phân quyền riêng cho ecommerce team, CSKH, kho và quản lý; không dùng chung tài khoản để xử lý ngoại lệ.
- Đặt quy tắc shop nào được dùng kho nào, SKU nào và mức safety stock nào.
Phân bổ đơn về kho phải có rule trước khi PDA bắt đầu picking
Nhiều gian hàng thường đi cùng nhiều điểm tồn: kho chính, kho phụ, kho 3PL hoặc cửa hàng. Rule phân bổ không nên chỉ chọn kho còn hàng nhiều nhất. Với mỗi đơn, OMS cần cân nhắc tồn khả dụng, khu vực giao, cut-off carrier, năng lực ca kho, hàng đã giữ, hàng cần đi chung kiện và giới hạn phục vụ của từng shop.
Sau khi OMS chốt kho xử lý, WMS mới release lệnh picking. PDA hướng dẫn nhân viên quét bin location rồi quét barcode SKU; checking quét lại để chặn nhầm màu, size hoặc combo. Nếu đơn bị khách đổi địa chỉ, hết hàng hoặc hủy trước packing, OMS cần đưa về hàng đợi ngoại lệ và nhả/điều chỉnh tồn có kiểm soát thay vì gửi tin nhắn cho kho.
- Đo SLA từ thời điểm đơn đủ điều kiện xử lý, không đánh đồng với đơn còn chờ xác minh hoặc chờ thanh toán.
- Gắn shop nguồn vào manifest, tem vận đơn và báo cáo để khi carrier trả lỗi vẫn truy đúng luồng.
- Không cho phép đổi kho, đổi SKU hoặc in lại tem ngoài log phê duyệt.
Khi nào nên dùng giải pháp này?
Chủ doanh nghiệp nên triển khai khi việc mở thêm shop khiến số hủy đơn, đơn trễ hoặc lệch tồn tăng, dù tổng số đơn chưa quá lớn. Đây thường là dấu hiệu đội đang dựa vào kinh nghiệm cá nhân thay vì một nguồn dữ liệu vận hành. Operations manager cần giải pháp khi phải điều phối nhiều ca, nhiều kho hoặc nhiều team mà mỗi team báo cáo theo cách khác nhau.
Warehouse manager và ecommerce team nên ưu tiên giải pháp này khi cùng SKU xuất hiện trên nhiều shop, có combo/quà tặng, nhiều biến thể hoặc chạy campaign đồng thời. Càng nhiều điểm chuyển giao giữa shop, CSKH, OMS và kho, giá trị của trạng thái chuẩn, barcode và log ngoại lệ càng rõ.
- Phù hợp với thương hiệu có nhiều shop Shopee, Lazada, TikTok Shop và website nhưng dùng chung một hoặc nhiều kho.
- Phù hợp khi cần báo cáo SLA, hủy đơn, lệch tồn, hàng hoàn và năng suất theo từng shop.
- Phù hợp trước campaign lớn hoặc trước khi mở thêm kho/3PL, không nên chờ đến khi kho phải xử lý bằng chat.
Checklist go-live cho nhiều gian hàng
Go-live không nên bắt đầu bằng việc kết nối tất cả shop rồi chờ lỗi. Hãy chọn một nhóm SKU đại diện, một shop chính và các tình huống thật: đơn cùng SKU từ hai shop, đơn combo, đơn hết hàng, đơn đổi địa chỉ, đơn hủy sau khi release, đơn bị carrier trả về và hàng hoàn chưa qua QC. Mỗi tình huống phải có người chịu trách nhiệm, trạng thái OMS và thao tác kho tương ứng.
Nghiệm thu chỉ đạt khi quản lý xem được nguồn shop của từng đơn, kho thấy đúng lệnh trên PDA, tồn khả dụng không bị cộng nhầm, và báo cáo có thể tách shop nhưng không làm vỡ dữ liệu SKU/kho chung. Sau pilot, mới mở rộng sang các shop còn lại và quy tắc phức tạp hơn.
- Chốt SKU master, barcode, mapping biến thể, combo và tồn đầu kỳ theo từng kho.
- Kiểm thử đồng thời đơn của nhiều shop dùng chung SKU và trường hợp overselling bị chặn.
- Kiểm thử picking, checking, packing, bàn giao, hàng hoàn và đối soát theo shop nguồn.
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 quản lý nhiều gian hàng marketplace 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 gom đơn theo từng shop nhưng dùng chung tồn khả dụng, mapping SKU, phân quyền vận hành, phân bổ đơn về kho, kiểm soát SLA và đối soát hàng hoà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 quản lý nhiều gian hàng marketplace 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
- Liệt kê từng shop, kênh, kho phục vụ, số đơn/ngày, SKU dùng chung và SLA hiện tại.
- Chuẩn bị bảng mapping listing/biến thể của từng shop về SKU master và barcode kho.
- Xác định tồn nào được bán, tồn nào đang giữ, chờ QC, lỗi hoặc dành cho safety stock.
- Mô tả rule phân bổ đơn, cut-off vận chuyển và quyền xử lý ngoại lệ.
- Mang đơn thật và tình huống lỗi thật vào buổi demo/pilot trước go-live.
JSTERP có thể hỗ trợ như thế nào?
JSTERP hỗ trợ doanh nghiệp thiết kế mô hình OMS + WMS cho nhiều gian hàng mà vẫn giữ được một nguồn dữ liệu SKU và tồn kho đáng tin cậy. Phạm vi có thể bắt đầu từ gom đơn, mapping SKU và tồn khả dụng, sau đó mở rộng sang PDA, order routing, nhiều kho và hàng hoàn.
Đội triển khai sẽ rà soát kênh bán, shop, SKU, kho, barcode, quy trình ngoại lệ và chỉ số SLA để xác định rule phù hợp, thay vì áp một cấu hình giống nhau cho mọi doanh nghiệp.
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.
