Kết luận nhanh: chọn hệ thống theo lớp đang hỏng, không theo nhãn “đa sàn” hay “ERP”
Phần lớn bài viết tiếng Việt về câu hỏi “dùng phần mềm bán hàng đa sàn hay ERP” trả lời bằng một câu: nếu phần lớn doanh thu đến từ Shopee, TikTok Shop, Lazada thì chọn phần mềm đa kênh; nếu cần kế toán, sản xuất, nhiều kho thì chọn ERP. Câu đó không sai, nhưng gần như không giúp ra quyết định, vì shop ecommerce Việt Nam hiếm khi hỏng ở “cả công ty” — họ hỏng ở một lớp cụ thể, và mỗi lớp cần một loại hệ thống khác.
Ba lớp vận hành của một shop đa sàn:
- Lớp kênh: listing, giá, khuyến mãi, chat, nhận đơn từ sàn, đẩy tồn lên sàn, in nhãn vận chuyển. Công cụ quản lý đa sàn sinh ra cho lớp này.
- Lớp thực thi: một SKU nội bộ cho mỗi biến thể, tồn khả dụng theo kho, phân bổ đơn vào kho, và trong kho là nhập, cất lên vị trí, lấy, kiểm, đóng gói, bàn giao, nhận hàng hoàn — mỗi bước bằng quét barcode, có người và thời điểm. Đây là OMS + WMS.
- Lớp tài chính: mua hàng, giá vốn, lãi từng đơn, công nợ nhà cung cấp, hóa đơn, sổ kế toán. Đây là ERP hoặc phần mềm kế toán.
Bốn quyết định nên chốt trước khi gặp nhà cung cấp:
- Phân loại 20 lỗi gần nhất theo lớp. Lớp có chi phí lỗi lớn nhất là lớp cần hệ thống trước.
- Chọn một nguồn sự thật cho tồn. Chỉ một hệ thống được đẩy tồn lên sàn; nếu có WMS thì số đó phải đến từ WMS.
- Không mua lớp 3 khi lớp 2 còn sai. Giá vốn, lãi đơn, công nợ đều tính từ số tồn; tồn sai thì báo cáo tài chính đẹp nhưng sai.
- Đo bằng bài kiểm tra thao tác, không bằng danh sách tính năng. “Có quản lý kho” và “chặn đóng gói khi quét sai biến thể” là hai mức khác nhau.
Phần còn lại của bài đưa 12 bài kiểm tra, công thức và lộ trình để doanh nghiệp tự áp dụng trên dữ liệu của mình.
Tóm tắt nhanh
Bài dành cho chủ shop, trưởng vận hành, trưởng kho và kế toán của doanh nghiệp bán đa sàn tại Việt Nam đang phân vân giữa: tiếp tục dùng công cụ quản lý đa sàn, bổ sung OMS + WMS, hay triển khai ERP. Nội dung: mô hình ba lớp và dữ liệu mỗi lớp sở hữu; 12 bài kiểm tra vận hành; bảng so sánh module kho của công cụ đa sàn với WMS theo quét; công thức chi phí lỗi theo lớp; ngưỡng cần WMS; quy tắc giao dữ liệu sang kế toán; sai lầm phổ biến; lộ trình 3 giai đoạn; checklist 5 việc.
Mọi con số là công thức và khoảng minh họa để doanh nghiệp tự tính, không phải số liệu khách hàng của JST ERP Việt Nam, và không phải đánh giá chi tiết về bất kỳ sản phẩm cụ thể nào. Khả năng của từng phần mềm cần được kiểm tra bằng demo trên dữ liệu thật.
Thông tin thực thể liên quan
| Thuật ngữ | Định nghĩa dùng trong bài | Dữ liệu sở hữu |
|---|---|---|
| Công cụ quản lý đa sàn | Phần mềm kết nối nhiều gian hàng để đăng listing, gom đơn, đồng bộ tồn, in nhãn, chat | Listing, giá, khuyến mãi, hội thoại |
| OMS | Hệ thống quản lý đơn: SKU nội bộ, mapping, tồn khả dụng, phân bổ đơn, trạng thái, đối soát | Đơn, SKU master, mapping, tồn khả dụng |
| WMS | Hệ thống quản lý kho theo quét: vị trí, nhập, cất, lấy, kiểm, đóng gói, bàn giao, hàng hoàn, kiểm kê | Tồn vật lý theo vị trí, nhật ký thao tác |
| ERP / kế toán | Mua hàng, giá vốn, công nợ, hóa đơn, sổ cái | Giá trị tồn, giá vốn, công nợ, bút toán |
| Nguồn sự thật tồn | Hệ thống duy nhất được phép ghi tồn lên sàn | Quy tắc tích hợp |
| Lỗi theo lớp | Phân loại sự cố theo lớp kênh, thực thi, tài chính | 20 sự cố gần nhất |
So sánh nhanh theo mức độ vận hành: công cụ đa sàn, OMS + WMS hay ERP
| Mức vận hành | Lỗi chiếm ưu thế | Lớp cần đầu tư |
|---|---|---|
| 1–3 gian hàng, dưới 200 SKU, 1 kho nhỏ, 1–2 người đóng gói | Sót đơn, bán vượt tồn giữa sàn, mất thời gian sửa listing | Công cụ đa sàn hoặc OMS-only |
| 3–10 gian hàng, 200–2.000 SKU biến thể, 3+ người kho hoặc thời vụ | Giao sai biến thể, tìm hàng lâu, hàng hoàn treo, lệch tồn sau kiểm kê | OMS + WMS theo quét |
| Nhiều kho hoặc kho + 3PL, lô/hạn dùng, combo nhiều thành phần | Phân sai kho, xuất sai lô, lệch tồn giữa kho | OMS + WMS đa kho |
| Có nhập khẩu, sản xuất, gia công, bán sỉ công nợ | Giá vốn sai, lãi đơn không tính được, công nợ lệch | Thêm ERP/kế toán, nối từ OMS + WMS |
1. Vì sao “chọn đa kênh nếu doanh thu online trên 70%” là câu trả lời thiếu
Tỷ lệ doanh thu online cho biết kênh nào quan trọng. Nó không cho biết lỗi nằm ở đâu. Hai shop cùng 100% doanh thu online:
| Đặc điểm | Shop A (mỹ phẩm) | Shop B (thời trang) |
|---|---|---|
| Đơn/ngày | 300 | 300 |
| SKU biến thể | 40 | 900 (size × màu) |
| Kho | 1 phòng 30 m² | 1 kho 400 m² + 1 kho thuê dịp sale |
| Người kho | 2 cố định | 6 cố định + 4–10 thời vụ |
| Tỷ lệ hàng hoàn | 2–3% | 10–20% |
| Lỗi chủ yếu | Bán vượt tồn khi flash sale, sót cập nhật giá | Giao nhầm size/màu, không tìm thấy hàng, hàng hoàn chờ nhiều ngày |
| Lớp cần đầu tư | Lớp kênh/OMS | Lớp WMS |
Theo quy tắc 70%, cả hai đều “chọn phần mềm đa kênh”. Shop A đúng. Shop B sẽ mua thêm tính năng đăng listing trong khi lỗi thật nằm ở kệ hàng. Tương tự, câu “cần nhiều kho thì chọn ERP” trộn lẫn hai việc: quản lý tồn vật lý nhiều kho (việc của WMS) và hạch toán giá trị tồn nhiều kho (việc của kế toán).
2. Mô hình ba lớp: mỗi lớp sở hữu dữ liệu gì và ai được ghi
Phần mềm sai lớp không phải là vấn đề lớn nhất. Vấn đề lớn nhất là hai hệ thống cùng ghi một dữ liệu. Bảng dưới là quy tắc sở hữu nên chốt bằng văn bản trước khi tích hợp:
| Dữ liệu | Hệ thống sở hữu (được ghi) | Hệ thống chỉ đọc | Lỗi khi sở hữu không rõ |
|---|---|---|---|
| Listing, giá bán, khuyến mãi | Công cụ đa sàn hoặc Seller Center | OMS (để tính tiền đơn) | Giá trên sàn khác giá trong đối soát |
| SKU nội bộ, barcode, combo | OMS (master) | WMS, kế toán, công cụ đa sàn | Một biến thể có hai mã, combo trừ sai thành phần |
| Mapping listing sàn → SKU nội bộ | OMS | Công cụ đa sàn | Đơn vào nhưng không trừ tồn |
| Tồn vật lý theo vị trí | WMS | OMS | Hệ thống báo còn, kệ trống |
| Tồn khả dụng đẩy lên sàn | OMS (tính từ WMS trừ tồn giữ) | Công cụ đa sàn không được ghi | Hai hệ thống đẩy hai con số, bán vượt tồn |
| Trạng thái đóng gói, bàn giao | WMS | OMS, chăm sóc khách | Không chứng minh được đơn đã đi lúc nào |
| Giá vốn, giá trị tồn | Kế toán/ERP | OMS (báo cáo lãi đơn) | Lãi đơn tính bằng giá nhập cũ |
| Công nợ nhà cung cấp, hóa đơn | Kế toán/ERP | — | Thanh toán trùng, thiếu hóa đơn |
Hệ quả quan trọng: doanh nghiệp có thể giữ công cụ đa sàn đang dùng cho listing và chat, nhưng khi có WMS thì công cụ đó phải ngừng đẩy tồn. Nhiều trường hợp “lắp WMS rồi vẫn bán vượt tồn” đến từ đúng điểm này. Chi tiết về độ trễ và cơ chế đồng bộ: SLA đồng bộ tồn kho đa sàn.
3. Mười hai bài kiểm tra vận hành để biết lớp nào đang hỏng
Mỗi bài kiểm tra làm được trong một buổi bằng dữ liệu 30 ngày hoặc quan sát trực tiếp. Ghi kết quả “đạt / không đạt”. Lớp có nhiều “không đạt” nhất là lớp cần hệ thống trước.
Lớp kênh (công cụ đa sàn / OMS)
| # | Bài kiểm tra | Cách làm | Ngưỡng gợi ý “không đạt” |
|---|---|---|---|
| 1 | Đơn hủy do hết hàng | Lấy từ Seller Center từng sàn, 30 ngày | Trên 0,3% đơn hoặc có điểm phạt vì hủy |
| 2 | Độ trễ tồn giữa sàn | Đặt thử 1 đơn, đo thời gian tồn ở sàn khác giảm | Trên 5 phút với SKU bán chạy trong campaign |
| 3 | Listing chưa map | Đếm listing đang bán không gắn SKU nội bộ | Bất kỳ listing đang có đơn mà chưa map |
| 4 | Đơn sót xử lý | Đếm đơn quá hạn chuẩn bị hàng do không thấy đơn | Trên 0 đơn/tuần lặp lại |
Lớp thực thi trong kho (WMS)
| # | Bài kiểm tra | Cách làm | Ngưỡng gợi ý “không đạt” |
|---|---|---|---|
| 5 | Giao sai biến thể / thiếu hàng | Đếm khiếu nại giao sai, thiếu trong 30 ngày ÷ tổng đơn | Trên 0,3–0,5% đơn |
| 6 | Thời gian tìm hàng | Bấm giờ 20 dòng lấy hàng ngẫu nhiên | Trung vị trên 60–90 giây/dòng, hoặc phải hỏi người khác vị trí |
| 7 | Thử người mới | Cho người chưa quen kho lấy 10 đơn có biến thể | Sai trên 1 đơn hoặc không tự hoàn thành được |
| 8 | Hàng hoàn treo | Đếm kiện hoàn đã về kho nhưng chưa vào lại tồn | Có kiện chờ quá 48 giờ |
| 9 | Lệch tồn sau kiểm kê | Đếm 50 SKU ngẫu nhiên theo vị trí, so hệ thống | Lệch giá trị trên 1–2%, hoặc trên 3–5% số SKU lệch |
| 10 | Bằng chứng đóng gói | Chọn 5 đơn khách khiếu nại, tìm ai đóng, lúc nào, quét gì | Không truy được trong 5 phút/đơn |
Lớp tài chính (ERP / kế toán)
| # | Bài kiểm tra | Cách làm | Ngưỡng gợi ý “không đạt” |
|---|---|---|---|
| 11 | Lãi từng đơn | Chọn 10 đơn, tính doanh thu − phí sàn − voucher shop − ship − giá vốn − đóng gói | Không tính được trong 1 giờ hoặc lệch trên 5% so với báo cáo |
| 12 | Khớp tồn với sổ kế toán | So giá trị tồn cuối tháng trên hệ thống kho với sổ | Chênh không giải thích được trên 1% giá trị tồn |
Lưu ý thứ tự: nếu bài 9 không đạt, đừng chấm bài 11 và 12 — số tài chính tính trên tồn sai. Sửa lớp thực thi trước. Cách đo độ chính xác tồn chi tiết: độ chính xác tồn kho và cycle count.
4. “Có module kho” khác “WMS chạy theo quét” như thế nào
Hầu hết công cụ đa sàn và phần mềm bán hàng hiện nay đều có mục “quản lý kho”: tồn theo kho, nhập/xuất tay, một số có trường vị trí kệ hoặc app kiểm kê. Đó là thật và hữu ích. Câu hỏi quyết định là mức kiểm soát, không phải có hay không. Bảng dưới mô tả các mức để doanh nghiệp tự xác định phần mềm đang dùng nằm ở đâu — không phải đánh giá sản phẩm cụ thể nào.
| Mức | Hệ thống làm được | Lỗi vẫn lọt |
|---|---|---|
| M0 – Sổ tồn | Tồn tổng theo SKU, trừ khi có đơn | Mọi lỗi trong kho; chỉ phát hiện khi kiểm kê |
| M1 – Tồn theo kho, phiếu nhập/xuất | Tồn theo kho, phiếu điều chỉnh có lý do | Không biết hàng ở kệ nào, lấy sai vẫn trừ đúng mã |
| M2 – Vị trí ghi nhận | Trường vị trí trên SKU, in phiếu lấy có vị trí | Vị trí không cập nhật khi di chuyển; không xác nhận đã lấy đúng |
| M3 – Quét xác nhận | Quét vị trí + SKU khi lấy, quét SKU khi đóng gói, báo lỗi khi sai | Còn lỗi nếu cho phép bỏ qua quét hoặc nhập tay số lượng |
| M4 – Quét bắt buộc có nhật ký | Nhập, cất, lấy, kiểm, đóng gói, bàn giao, hàng hoàn đều bắt buộc quét; chặn bước sau khi bước trước chưa đạt; nhật ký người/thời điểm; kiểm kê theo vị trí không dừng bán | Lỗi barcode gốc, lỗi dán nhãn từ nhà cung cấp |
Quy tắc: nếu bài kiểm tra 5–10 ở mục 3 không đạt, doanh nghiệp cần tối thiểu M3, thường là M4. M0–M2 đủ khi kho nhỏ, ít biến thể và một hai người quen việc. Năm câu hỏi demo phân biệt M2 với M4:
- Quét nhầm size trong lúc đóng gói: hệ thống chặn in nhãn hay chỉ cảnh báo có nút bỏ qua?
- Chuyển 20 thùng từ kệ A sang kệ B: tồn theo vị trí cập nhật bằng quét hay sửa tay?
- Kiện hoàn về không có phiếu: nhận theo mã vận đơn và phân loại tình trạng (bán lại / lỗi / thiếu) thế nào?
- Kiểm kê một dãy kệ khi đang có đơn: có khóa vị trí và tiếp tục bán từ vị trí khác được không?
- Khách khiếu nại thiếu hàng: tra ai lấy, ai kiểm, ai đóng, lúc mấy giờ trong bao lâu?
Chi tiết từng bước quét: PDA cho picking, checking, packing và quy trình nhập kho và cất hàng.
5. Công thức chi phí lỗi theo lớp
Thay vì so “gói phần mềm A rẻ hơn B”, hãy tính mỗi lớp đang làm mất bao nhiêu tiền một tháng. Lớp có chi phí lớn nhất là nơi đầu tư trước.
| Lớp | Khoản | Công thức tháng |
|---|---|---|
| Kênh | K1 Bán vượt tồn | Số đơn hủy do hết hàng × (lãi gộp mất + chi phí điểm phạt/giảm hiển thị quy đổi) |
| K2 Giờ công thao tác listing, gom đơn | Giờ/tháng × lương giờ | |
| Thực thi | T1 Giao sai, thiếu | Số đơn sai × (phí ship hai chiều + hàng hỏng/mất + công xử lý + bồi hoàn/voucher) |
| T2 Tìm hàng | Số dòng lấy/tháng × (giây tìm thực tế − giây chuẩn) ÷ 3.600 × lương giờ | |
| T3 Hàng hoàn treo | Giá trị hàng hoàn chờ × số ngày chờ ÷ 30 × tỷ lệ bỏ lỡ bán + hàng hoàn thất lạc | |
| T4 Thất thoát | Giá trị chênh âm sau kiểm kê không giải thích được | |
| Tài chính | F1 Quyết định giá sai | Doanh thu SKU lỗ không phát hiện × biên lỗ |
| F2 Giờ công đối chiếu | Giờ kế toán/tháng chép, đối chiếu × lương giờ |
Ví dụ minh họa (shop thời trang 300 đơn/ngày, 9.000 đơn/tháng, số tròn để dễ kiểm):
- T1: tỷ lệ giao sai 0,8% → 72 đơn × 60.000đ (ship hai chiều 35.000đ + công 10.000đ + voucher xin lỗi 15.000đ) ≈ 4,3 triệu, chưa tính đánh giá xấu.
- T2: 13.500 dòng lấy × 40 giây thừa ÷ 3.600 = 150 giờ × 30.000đ ≈ 4,5 triệu.
- T3: 60 triệu giá trị hàng hoàn chờ trung bình 6 ngày → 12 triệu tương đương hàng “không bán được” mỗi tháng; nếu 30% trong đó là SKU bán chạy bị hết hàng ảo, mất thêm doanh thu.
- K1: 15 đơn hủy × 80.000đ lãi gộp ≈ 1,2 triệu.
Trong ví dụ này lớp thực thi tốn gấp nhiều lần lớp kênh — mua thêm công cụ đa sàn không giải quyết được. Ngược lại, với shop mỹ phẩm 40 SKU ở mục 1, T1–T3 gần như bằng 0 và K1 là khoản chính. Các số trên là giả định minh họa; hãy thay bằng dữ liệu thật của shop. Phương pháp tính hoàn vốn đầy đủ: chi phí và ROI của WMS cho ecommerce.
6. Ngưỡng định lượng: khi nào lớp kho cần WMS
Một chỉ số đơn giản giúp ước lượng áp lực lên trí nhớ của người kho: chỉ số phức tạp kho = số SKU biến thể đang có tồn × số vị trí trung bình mỗi SKU × hệ số luân chuyển người, trong đó hệ số luân chuyển = 1 nếu đội ổn định, 1,5 nếu có thời vụ theo mùa, 2 nếu thời vụ thường xuyên hoặc thay người hằng tháng.
| Chỉ số | Ý nghĩa thực tế | Gợi ý |
|---|---|---|
| Dưới 300 | Người kho nhớ được, lỗi thấp nếu có kệ gọn | M1–M2 đủ; ưu tiên chuẩn SKU và barcode |
| 300–1.500 | Bắt đầu phụ thuộc vào 1–2 người “biết kho” | M3: quét khi lấy và đóng gói; mã vị trí rõ ràng |
| Trên 1.500 | Người mới không thể làm đúng nếu không có hướng dẫn hệ thống | M4: WMS quét bắt buộc toàn chuỗi |
Ví dụ: 900 SKU có tồn × 1,3 vị trí × 1,5 (thời vụ mùa sale) ≈ 1.755 → nên có WMS M4 trước mùa sale. Ngưỡng là heuristic để mở thảo luận, không phải định luật; cần đối chiếu với bài kiểm tra 5–10. Thiết kế mã vị trí: thiết kế mã vị trí kho (bin location).
Các yếu tố đẩy nhu cầu WMS lên sớm hơn ngưỡng: hàng có lô/hạn dùng (cần FEFO), combo nhiều thành phần, hàng giá trị cao dễ thất thoát, cam kết SLA giao trong ngày, kho dùng chung với 3PL, tỷ lệ hàng hoàn trên 10%.
7. OMS-only hay OMS + WMS: phân biệt theo dấu hiệu
| Dấu hiệu | OMS-only đủ | Cần OMS + WMS |
|---|---|---|
| Nơi phát hiện lỗi | Trên sàn (hủy đơn, tồn lệch giữa sàn) | Trong kho hoặc khi khách nhận hàng |
| Người kho | 1–3 người quen việc | Từ 4 người hoặc có thời vụ |
| Vị trí | Một phòng, nhìn là thấy | Nhiều dãy kệ, nhiều tầng, nhiều kho |
| Hàng hoàn | Dưới 5%, xử lý trong ngày | Trên 5–10%, có kiện treo nhiều ngày |
| Bằng chứng khiếu nại | Video đóng gói đủ | Cần truy người/thời điểm/quét theo đơn |
| Campaign | Đỉnh gấp 2–3 lần ngày thường | Đỉnh gấp 5–10 lần, cần wave/batch |
Hai trường hợp ranh giới thường gặp: (1) shop ít SKU nhưng nhiều đơn — OMS-only + quét đóng gói đơn giản có thể đủ; (2) shop ít đơn nhưng nhiều biến thể và hàng hoàn — cần WMS sớm dù đơn chưa nhiều. Tham khảo thêm OMS là gì, khác ERP và WMS thế nào và phần mềm OMS + WMS cho ecommerce Việt Nam.
8. Khi nào thật sự cần lớp ERP / kế toán
ERP trong ngữ cảnh shop ecommerce Việt Nam thường có nghĩa là: mua hàng có đơn đặt và nhận theo đơn, giá vốn bình quân hoặc theo lô, công nợ nhà cung cấp, hóa đơn điện tử, và sổ kế toán. Dấu hiệu cần lớp này:
- Nhập khẩu có chi phí phân bổ (vận chuyển quốc tế, thuế, phí thông quan) vào giá vốn từng SKU.
- Sản xuất, gia công, đóng set, cần định mức nguyên vật liệu.
- Bán sỉ, đại lý, kênh B2B có công nợ và hạn thanh toán.
- Từ 3–5 nhà cung cấp chính trở lên với nhiều đợt nhập mỗi tháng.
- Kế toán mất trên 3–5 ngày mỗi tháng để chốt số liệu ecommerce.
Nếu không có các dấu hiệu trên, phần mềm kế toán phổ biến nhận dữ liệu tổng hợp từ OMS + WMS theo kỳ thường đủ. Điều kiện bắt buộc là ba bộ số kiểm soát khớp mỗi kỳ: (1) số đơn và doanh thu theo trạng thái, (2) tiền sàn thực trả sau phí, (3) xuất nhập tồn theo SKU và giá trị. Cách thiết lập: hóa đơn điện tử, thuế sàn và dữ liệu kế toán và đối soát dòng tiền 4 chiều.
9. Kịch bản tích hợp phổ biến và rủi ro của từng kịch bản
| Kịch bản | Phù hợp khi | Rủi ro chính | Kiểm soát cần có |
|---|---|---|---|
| A. Chỉ công cụ đa sàn | Kho nhỏ, ít biến thể, 1–3 người | Lỗi kho không hiện ra cho đến khi khách khiếu nại | Kiểm kê định kỳ, video đóng gói |
| B. Công cụ đa sàn + WMS riêng | Đã quen công cụ listing, cần kiểm soát kho | Hai hệ thống cùng đẩy tồn; mapping SKU hai nơi | Chỉ một bên đẩy tồn; một bảng SKU master |
| C. OMS + WMS một nền tảng | Lỗi chủ yếu ở lớp thực thi | Đổi thói quen listing nếu bỏ công cụ cũ | Giữ quy trình listing rõ, phân quyền |
| D. OMS + WMS + kế toán nối theo kỳ | Cần lãi đơn, giá vốn đúng | Lệch giữa tồn kho và sổ | Ba bộ số kiểm soát, khóa kỳ |
| E. ERP tổng thể thay tất cả | Có sản xuất, B2B, nhiều pháp nhân | Triển khai dài, lớp ecommerce yếu nếu ERP không sinh ra cho sàn | POC bằng đơn sàn thật trước khi ký |
Với đa số shop Việt Nam bán chủ yếu trên sàn, C hoặc D là điểm cân bằng; B dùng được nếu kỷ luật nguồn sự thật tồn được giữ chặt. E chỉ nên chọn khi lớp tài chính và sản xuất thật sự là điểm nghẽn, và phải chứng minh được xử lý đơn sàn trong POC.
10. Những sai lầm phổ biến trong các bài “top phần mềm quản lý bán hàng”
- “Phần mềm có quản lý kho nên không cần WMS.” Có quản lý kho ở mức M1–M2 không ngăn lấy sai biến thể. Hỏi mức kiểm soát (mục 4), không hỏi có/không.
- “Doanh nghiệp lớn mới cần ERP, nhỏ thì dùng đa kênh.” Quy mô không quyết định lớp. Một shop 15 người có thể cần WMS trước; một công ty 100 người bán sỉ có thể cần kế toán trước.
- “Càng nhiều tính năng càng tốt.” Tính năng không dùng là cấu hình phải duy trì. Chọn theo 3–5 lỗi đắt nhất.
- “Miễn phí thì thử trước, sau đổi.” Chi phí đổi hệ thống nằm ở dữ liệu: mapping SKU, lịch sử đơn, tồn đầu kỳ, thói quen đội. Hỏi trước về xuất dữ liệu.
- “Đồng bộ tồn tự động thì hết bán vượt tồn.” Đồng bộ chỉ đúng khi số gốc đúng và chỉ một hệ thống đẩy. Tồn gốc sai thì đồng bộ nhanh chỉ lan số sai nhanh hơn.
- “Triển khai trong vài ngày.” Kết nối gian hàng có thể vài giờ; làm sạch SKU, kiểm đếm tồn đầu kỳ, gắn vị trí và huấn luyện quét thường cần 4–8 tuần với kho vài trăm đến vài nghìn SKU.
- So giá gói thuê bao. So tổng chi phí: thuê bao + thiết bị (PDA, máy in, máy quét) + giờ làm sạch dữ liệu + giờ huấn luyện + chi phí lỗi còn lại.
11. Lộ trình 3 giai đoạn cho shop đa sàn
| Giai đoạn | Thời gian gợi ý | Việc chính | Tiêu chí xong |
|---|---|---|---|
| 1. Chuẩn lớp kênh/OMS | 2–4 tuần | SKU nội bộ cho mọi biến thể, barcode, mapping 100% listing đang bán, combo, chọn nguồn sự thật tồn | 0 listing có đơn mà chưa map; hủy do hết hàng dưới 0,3% |
| 2. Đưa kho vào quét (WMS) | 4–8 tuần | Mã vị trí, kiểm đếm tồn đầu kỳ theo vị trí, quét lấy/kiểm/đóng gói, nhận hàng hoàn theo mã vận đơn, huấn luyện | 3 tuần liên tiếp: giao sai dưới 0,1–0,2%, lệch kiểm kê dưới 1% giá trị, không kiện hoàn chờ quá 48 giờ |
| 3. Nối lớp tài chính | 2–6 tuần | Giá vốn, ba bộ số kiểm soát theo kỳ, hóa đơn, công nợ nếu cần | Hai kỳ liên tiếp khớp ba bộ số, chênh có giải thích |
Không bắt đầu giai đoạn 2 trong 2–3 tuần trước 11.11, 12.12 hoặc Tết. Kế hoạch chuyển đổi không gián đoạn: triển khai OMS + WMS không gián đoạn; nếu đang dùng Excel: khi nào bỏ Excel để chuyển sang OMS hay OMS + WMS.
12. Kho tự vận hành hay 3PL thay đổi lựa chọn thế nào
Nếu dùng 3PL, WMS thường thuộc về 3PL. Lớp thực thi của shop thu hẹp về OMS: tồn khả dụng lấy từ 3PL, đơn đẩy sang 3PL, trạng thái và hàng hoàn trả về. Câu hỏi khi đó là API và SLA của 3PL: độ trễ cập nhật tồn, tỷ lệ giao sai cam kết, thời hạn nhập hàng hoàn vào tồn, quyền xem nhật ký đóng gói. Nếu vừa có kho riêng vừa có 3PL, OMS phải phân bổ đơn giữa hai nơi. Xem kho tự vận hành hay 3PL và SLA 3PL fulfillment.
13. Checklist 5 việc làm ngay trong tuần này
- Lấy 20 lỗi gần nhất (khiếu nại, hủy, lệch tồn, sai giá vốn) và gán mỗi lỗi vào lớp kênh, thực thi hoặc tài chính.
- Chạy bài kiểm tra 5, 6, 8, 9 ở mục 3: đếm giao sai 30 ngày, bấm giờ 20 dòng lấy hàng, đếm kiện hoàn treo, kiểm đếm 50 SKU theo vị trí.
- Viết bảng sở hữu dữ liệu như mục 2 cho hệ thống hiện tại; đánh dấu dữ liệu nào đang bị hai hệ thống cùng ghi, đặc biệt tồn đẩy lên sàn.
- Tính chi phí lỗi theo lớp bằng bảng mục 5 với số thật; xếp hạng ba lớp.
- Chuẩn bị 5 câu hỏi demo ở mục 4 và yêu cầu nhà cung cấp làm trực tiếp trên 30–50 SKU thật của shop.
14. Câu hỏi nên đặt cho nhà cung cấp
- Hệ thống nằm ở mức kiểm soát nào trong M0–M4 cho từng bước: nhập, cất, lấy, kiểm, đóng gói, bàn giao, hàng hoàn, kiểm kê?
- Nếu giữ công cụ đa sàn hiện tại, tắt việc đẩy tồn từ công cụ đó thế nào và ai chịu trách nhiệm khi lệch?
- Dữ liệu gì được xuất sang kế toán, theo tần suất nào, và bộ số kiểm soát nào chứng minh khớp?
- Xuất toàn bộ dữ liệu (SKU, mapping, đơn, tồn theo vị trí, nhật ký) khi chấm dứt hợp đồng được không?
- Thời gian triển khai thực tế cho số SKU và số kho của shop, gồm cả làm sạch dữ liệu và huấn luyện?
Cách chấm điểm và POC trên dữ liệu thật: chọn và nghiệm thu OMS + WMS. Phạm vi cam kết: cam kết dịch vụ.
15. Kết luận
“Phần mềm đa sàn hay ERP” là câu hỏi sai cấp. Câu đúng là: tháng này shop mất tiền ở lớp nào — kênh, thực thi trong kho hay tài chính — và hệ thống nào sở hữu dữ liệu của lớp đó. Công cụ đa sàn cho lớp kênh, OMS + WMS theo quét cho lớp thực thi, ERP/kế toán cho lớp tài chính; đi theo thứ tự kênh → kho → tài chính vì mỗi lớp sau dùng số của lớp trước. Giữ một nguồn sự thật cho tồn, đo bằng 12 bài kiểm tra thay vì danh sách tính năng, và chỉ chuyển giai đoạn khi tiêu chí xong đã đạt.
Để đánh giá sát doanh nghiệp, xem phạm vi sản phẩm OMS + WMS, giải pháp bán hàng đa kênh, giải pháp vận hành kho, cam kết dịch vụ và cách xác nhận phạm vi, câu hỏi thường gặp, rồi đăng ký tư vấn với JST ERP Việt Nam. Mọi khả năng sản phẩm cần được xác nhận trên phạm vi triển khai thật.