Kết luận nhanh: bỏ Excel theo chi phí lỗi và số điểm chạm dữ liệu, không theo một con số đơn
Hầu hết bài viết về câu hỏi này đưa một ngưỡng duy nhất — 20–30 đơn/ngày, 50–70 đơn/ngày, hoặc “khi file chạy chậm”. Ngưỡng đó đúng với một shop một kênh, vài chục SKU, một người làm. Nó sai với phần lớn shop ecommerce Việt Nam hiện nay: bán đồng thời Shopee, TikTok Shop, Lazada, Facebook/Zalo, có combo, có hàng hoàn và có từ hai người trở lên chạm vào cùng một dữ liệu tồn.
Excel không hỏng vì số dòng. Excel hỏng vì mỗi đơn phải được chép (từ sàn vào file), trừ (tồn ở file chung), đồng bộ (cập nhật lại tồn lên các sàn khác), tìm (hàng ở đâu trong kho), đối soát (tiền về có khớp không) — và mỗi điểm chạm thủ công là một cơ hội sai, cộng một khoảng trễ trong đó các kênh khác vẫn bán trên số tồn cũ.
Bốn quyết định nên chốt:
- Đo điểm chạm, không đo đơn: đơn/ngày × số kênh dùng chung tồn × số lần chép tay mỗi đơn. Khi đơn/ngày × số kênh vượt khoảng 150–200, độ trễ cập nhật tồn bằng tay bắt đầu tạo bán vượt tồn đều đặn trên SKU bán chạy.
- Đo chi phí lỗi thật trong 30 ngày: bán vượt tồn, giao sai, sót đối soát, giờ công chép. Nếu tổng lớn hơn phí phần mềm hàng tháng, Excel đang đắt hơn.
- Phân loại lỗi để chọn OMS hay OMS + WMS: lỗi ở đơn và tồn giữa các kênh → OMS. Lỗi ở trong kho (lấy sai, không tìm thấy, hàng hoàn, nhiều vị trí) → cần thêm WMS.
- Chuyển đổi có kế hoạch 4–6 tuần, không “mua xong dùng luôn”: làm sạch SKU và mapping, kiểm đếm tồn đầu kỳ, chạy song song ngắn có tiêu chí dừng, rồi khóa file.
Phần còn lại của bài giải thích từng bước bằng công thức, bảng và ví dụ có thể kiểm tra lại với dữ liệu của chính shop.
Tóm tắt nhanh
Bài dành cho chủ shop, trưởng vận hành và trưởng kho ecommerce tại Việt Nam đang quản lý đơn và tồn bằng Excel hoặc Google Sheet cho Shopee, TikTok Shop, Lazada và kênh social. Nội dung: bảng ngưỡng theo bốn biến, công thức chi phí lỗi C1–C4, phép tính độ trễ cập nhật tồn, phân loại lỗi để chọn OMS-only hay OMS + WMS, dữ liệu cần làm sạch, kế hoạch 6 tuần và 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 trên dữ liệu của mình, không phải số liệu khách hàng của JST ERP Việt Nam.
Thông tin thực thể liên quan
| Thuật ngữ | Định nghĩa dùng trong bài | Dữ liệu cần có |
|---|---|---|
| OMS | Hệ thống quản lý đơn hàng: gom đơn đa kênh, tồn khả dụng, mapping SKU, đồng bộ tồn, in nhãn, đối soát | Kết nối gian hàng, master SKU |
| WMS | Hệ thống quản lý kho: vị trí, nhập, lấy, kiểm, đóng gói, hàng hoàn bằng quét barcode/PDA | Mã vị trí, barcode SKU |
| Kênh dùng chung tồn | Số gian hàng/kênh bán cùng một tồn vật lý | Danh sách gian hàng |
| Độ trễ cập nhật tồn (T) | Thời gian từ khi có đơn đến khi các kênh khác thấy tồn mới | Tần suất cập nhật thực tế |
| Chi phí lỗi C1–C4 | Bán vượt tồn, giao sai, sót đối soát, giờ công chép | Dữ liệu 30 ngày từ Seller Center và file nội bộ |
| Mapping SKU | Liên kết mã listing trên sàn với SKU nội bộ | Danh sách listing mọi gian hàng |
So sánh nhanh theo mức độ vận hành: Excel, OMS-only hay OMS + WMS
| Mức vận hành | Rủi ro chính | Công cụ phù hợp |
|---|---|---|
| 1 kênh, dưới 100 SKU, 1 người, đơn × kênh dưới 80 | Chép đơn mất thời gian | Excel + Seller Center vẫn ổn |
| 2–5 kênh, 100–300 SKU, 2 người | Bán vượt tồn, lệch tồn giữa sàn, sót đối soát | OMS-only |
| Trên 300 SKU biến thể, trên 3 người kho, có thời vụ hoặc hàng hoàn trên 5% | Lấy sai, không tìm thấy hàng, hàng hoàn treo | OMS + WMS |
| Nhiều kho, kho thuê/3PL, lô/hạn dùng | Chọn sai kho xuất, lệch tồn giữa kho, xuất sai hạn | OMS + WMS đa kho |
1. Vì sao “X đơn/ngày” là câu trả lời sai
So sánh hai shop:
| Đặc điểm | Shop A | Shop B |
|---|---|---|
| Đơn/ngày | 150 | 40 |
| Kênh/gian hàng dùng chung tồn | 1 (một gian Shopee) | 5 (2 Shopee, 1 TikTok Shop, 1 Lazada, Facebook) |
| SKU đang bán | 25 | 600 (thời trang, size × màu) |
| Người cùng sửa tồn | 1 | 3 |
| Combo | Không | Có, 40 combo |
| Nguy cơ bán vượt tồn | Thấp — sàn tự trừ tồn của chính nó | Cao — một biến thể còn 2 có thể bán 2 lần trên 2 kênh trong khoảng trễ cập nhật |
Theo ngưỡng “50–70 đơn/ngày”, shop A cần phần mềm còn shop B chưa. Thực tế ngược lại: shop A có thể vận hành ổn bằng Seller Center và một file tồn, còn shop B gần như chắc chắn đang bán vượt tồn mỗi tuần và mất giờ công đối chiếu mỗi ngày.
Lý do là rủi ro đến từ số lần cùng một đơn vị tồn được “hiển thị” ở nhiều nơi và số người có thể thay đổi nó, không phải từ số dòng trong file. Một SKU còn 3 cái đang hiển thị trên 5 gian hàng thực chất là 15 lời hứa bán cho 3 cái hàng.
2. Bốn biến quyết định, và ngưỡng gợi ý cho từng biến
Thay vì một con số, đánh giá bốn biến. Mỗi biến vượt ngưỡng là một tín hiệu; từ hai tín hiệu trở lên nên lập kế hoạch chuyển đổi.
| Biến | Còn dùng Excel được | Vùng cảnh báo | Nên chuyển |
|---|---|---|---|
| Đơn/ngày × số kênh dùng chung tồn | < 80 | 80–150 | > 150–200 |
| SKU đang bán (tính theo biến thể) | < 100 | 100–300 | > 300, hoặc có combo/bộ quà |
| Người cùng cập nhật tồn hoặc trạng thái đơn | 1 | 2 | ≥ 3, hoặc có thời vụ |
| Thời gian cập nhật tồn từ khi có đơn đến khi các kênh khác thấy | Trong vài phút, liên tục | 1–2 lần/giờ | Vài lần/ngày hoặc cuối ngày |
Các ngưỡng này là khoảng hợp lý để bắt đầu đánh giá, không phải định luật. Cách kiểm chứng đơn giản nhất là đếm số lần bán vượt tồn và giao sai trong 30 ngày gần nhất (mục 3). Nếu con số đó gần bằng 0 dù vượt ngưỡng, shop có thể đang có kỷ luật thủ công rất tốt — hoặc đang không ghi nhận lỗi.
Biến thứ năm: kho
Bốn biến trên quyết định cần OMS. Câu hỏi có cần WMS hay không phụ thuộc vào kho: số vị trí lưu trữ, số người lấy hàng, tỷ lệ nhân viên mới, có hàng lô/hạn dùng, có nhiều kho, có hàng hoàn cần phân loại. Mục 5 tách riêng phần này.
3. Công thức tính chi phí lỗi của Excel mỗi tháng
Lý do thường bị bỏ qua khi quyết định là shop chỉ so phí phần mềm với “Excel miễn phí”. Excel không miễn phí; chi phí của nó nằm rải rác trong phạt sàn, ship hoàn, hàng hỏng, tiền chưa đối soát và lương. Dùng công thức dưới đây trên dữ liệu 30 ngày gần nhất:
Chi phí lỗi/tháng = C1 + C2 + C3 + C4
C1 Bán vượt tồn = số đơn phải hủy do hết hàng
× (giá trị đơn × biên lợi nhuận gộp // lợi nhuận mất
+ chi phí xử lý khiếu nại/hủy)
+ ảnh hưởng điểm vận hành/phạt (nếu có)
C2 Giao sai/thiếu = số đơn khách báo sai/thiếu
× (phí ship gửi bù + phí ship hoàn
+ giá vốn hàng không thu hồi được
+ 15–30 phút công xử lý)
C3 Sót đối soát = tiền COD, phí sàn, phí vận chuyển lệch
chưa giải thích được trong tháng
× tỷ lệ không đòi lại được
C4 Giờ công chép = giờ/ngày dùng để chép đơn, trừ tồn, cập nhật
tồn lên sàn, đối chiếu file × số ngày × lương giờVí dụ minh họa (số giả định, thay bằng số của shop)
| Khoản | Giả định | Chi phí/tháng |
|---|---|---|
| C1 | 20 đơn hủy do hết hàng × (lợi nhuận mất 60.000đ + xử lý 20.000đ) | 1.600.000đ |
| C2 | 15 đơn giao sai × (ship bù 30.000đ + ship hoàn 30.000đ + hàng hỏng 50.000đ + công 25.000đ) | 2.025.000đ |
| C3 | 8.000.000đ lệch chưa giải thích × 30% không đòi lại | 2.400.000đ |
| C4 | 3 giờ/ngày × 26 ngày × 35.000đ/giờ | 2.730.000đ |
| Tổng | 8.755.000đ |
Chưa tính chi phí khó đo: điểm phạt vận hành làm giảm hiển thị, đánh giá 1 sao từ đơn giao sai, và thời gian chủ shop dành để “chữa cháy”. Nếu tổng trên đã lớn hơn phí phần mềm hàng tháng cộng chi phí triển khai chia 12, quyết định gần như đã rõ.
Cách lấy số nhanh: C1 lấy từ danh sách đơn hủy với lý do “hết hàng” trong Seller Center từng sàn; C2 từ yêu cầu trả hàng/khiếu nại lý do “giao sai/thiếu”; C3 từ báo cáo thanh toán sàn so với file doanh thu; C4 bằng cách hỏi trực tiếp từng người làm việc với file trong một tuần và ghi lại thời gian.
4. Mười dấu hiệu Excel đã vượt sức, xếp theo mức nghiêm trọng
| Dấu hiệu | Ý nghĩa vận hành | Nghiêm trọng |
|---|---|---|
| Bán vượt tồn trên SKU bán chạy hơn 1 lần/tuần | Độ trễ cập nhật tồn lớn hơn khoảng cách giữa hai đơn của SKU đó | Cao |
| Phải “giữ lại” một phần tồn trên từng sàn để tránh bán vượt | Tồn bị chia nhỏ, sàn này hết khi sàn kia còn — mất doanh thu | Cao |
| Khách báo giao sai biến thể hằng tuần | Lấy hàng dựa vào trí nhớ/tên, không quét mã | Cao — đây là lỗi kho, cần WMS |
| Không trả lời được “tiền đơn X đã về chưa” | Không có liên kết đơn ↔ thanh toán ↔ hoàn | Cao |
| Hàng hoàn nằm đống chờ nhập lại tồn quá 3 ngày | Tồn hệ thống thấp hơn thực tế, mất bán | Trung bình–cao |
| Nhiều phiên bản file, ghi đè dữ liệu nhau | Không có nguồn sự thật duy nhất | Trung bình |
| Kiểm kê cuối tháng lệch không giải thích được | Không có lịch sử giao dịch tồn theo từng lần thay đổi | Trung bình |
| Nhân viên mới mất trên 1 tuần mới lấy hàng đúng | Vị trí hàng chỉ nằm trong đầu người cũ | Trung bình — tín hiệu WMS |
| Chép đơn và cập nhật tồn chiếm trên 2 giờ/ngày | Chi phí C4 lớn, và mỗi giờ trễ là giờ tồn sai | Trung bình |
| File chậm, treo | Triệu chứng muộn; thường đã có các dấu hiệu trên từ trước | Thấp (tự thân) |
Đáng chú ý: “file chạy chậm” — dấu hiệu được nhắc nhiều nhất — là dấu hiệu yếu nhất. File chậm có thể sửa bằng cách tách sheet; bán vượt tồn và giao sai thì không.
5. OMS-only hay OMS + WMS: phân loại lỗi trước khi chọn hệ thống
Đây là chỗ các bài so sánh phần mềm hay gộp làm một: “phần mềm quản lý bán hàng đa kênh” giải quyết lỗi ở tầng đơn và tồn tổng, nhưng không tự nó làm cho kho lấy đúng hàng. Chuyển từ Excel sang một OMS rồi vẫn giao sai là kết quả rất thường gặp.
| Lỗi đang gặp | Nằm ở tầng | Cần |
|---|---|---|
| Đơn rải rác nhiều sàn, phải đăng nhập từng nơi | Đơn | OMS |
| Bán vượt tồn giữa các sàn | Tồn tổng / đồng bộ | OMS (mapping SKU + đồng bộ tồn) |
| In nhãn từng sàn mất thời gian | Đơn / vận chuyển | OMS |
| Đối soát COD, phí sàn, hoàn tiền | Đơn / tài chính | OMS (+ dữ liệu kho nếu hoàn hàng) |
| Lấy sai biến thể, sai size màu | Kho — lấy hàng | WMS (quét barcode khi lấy/kiểm) |
| Không tìm thấy hàng dù hệ thống còn tồn | Kho — vị trí | WMS (bin location) |
| Hàng hoàn không vào lại tồn đúng tình trạng | Kho — nhận hoàn | WMS (nhận hoàn theo mã vận đơn, phân loại) |
| Nhiều kho, cần chọn kho xuất | Đơn + kho | OMS + WMS |
| Hàng có lô/hạn dùng | Kho | WMS (FEFO) |
| Thời vụ campaign, người mới | Kho — quy trình | WMS (PDA hướng dẫn từng bước) |
Quy tắc quyết định
- OMS-only đủ khi: một kho nhỏ, dưới khoảng vài trăm vị trí, 1–2 người kho làm lâu năm, lỗi chủ yếu là bán vượt tồn và chép đơn; sai sót kho đã được bắt bằng quét mã khi đóng gói.
- Cần OMS + WMS khi: có từ hai trong số — trên 300 SKU biến thể, trên 3 người lấy hàng, có thời vụ, có nhiều kho hoặc kho thuê, có lô/hạn, hàng hoàn trên 5% đơn, hoặc khách báo giao sai đều đặn mỗi tuần.
- Lộ trình hai bước hợp lý: OMS trước cho đơn và tồn đa kênh; WMS sau 1–3 tháng khi master data SKU và barcode đã sạch. Không nên làm WMS trước khi có mã SKU nội bộ thống nhất.
Xem thêm: Phần mềm OMS + WMS cho ecommerce Việt Nam và giải pháp vận hành kho.
6. Khoảng trễ cập nhật tồn: phép tính cho thấy vì sao Excel bán vượt tồn
Một SKU có tốc độ bán v đơn/giờ trên tổng các kênh. Nếu tồn được cập nhật lên các sàn mỗi T giờ một lần, số đơn có thể phát sinh trên số tồn cũ trong một khoảng là khoảng v × T. Khi tồn còn lại nhỏ hơn v × T, xác suất bán vượt tồn tăng nhanh.
Ví dụ: áo thun size M màu đen
v = 3 đơn/giờ (tổng 5 gian hàng, giờ cao điểm tối)
Cập nhật tồn bằng tay: 2 lần/ngày → T ≈ 6 giờ
v × T = 18 → bất cứ lúc nào tồn thực ≤ 18, có rủi ro bán vượt
Cập nhật tự động qua OMS: T ≈ vài phút (phụ thuộc API sàn)
v × T ≈ 0,1–0,3 → rủi ro chỉ còn ở vài đơn cuốiTrong campaign, v có thể tăng 5–10 lần trong 0h–2h, và cách làm thủ công gần như chắc chắn bán vượt tồn trên SKU chạy. Đó cũng là lý do shop dùng Excel thường phải “chia tồn” cố định cho từng sàn — giảm bán vượt nhưng lại để hàng nằm im ở sàn bán chậm trong khi sàn bán nhanh hết.
Lưu ý: ngay cả với OMS, đồng bộ tồn không tức thời; độ trễ phụ thuộc API từng sàn, tần suất đồng bộ, và cách hệ thống giữ tồn (reservation) khi đơn mới về. Chi tiết: SLA đồng bộ tồn kho đa sàn.
7. Những sai lầm phổ biến trong lời khuyên “chuyển từ Excel”
Sai lầm 1: “Đơn vượt 50 thì chuyển”
Đúng một phần cho shop một kênh. Như mục 1, số kênh dùng chung tồn và số SKU biến thể quyết định nhiều hơn. Hãy dùng đơn/ngày × số kênh, cộng ba biến còn lại.
Sai lầm 2: “Mua phần mềm là hết lệch tồn”
Phần mềm chỉ đồng bộ đúng khi mapping SKU đúng. Nếu một biến thể trên Shopee có mã “AT-DEN-M”, trên TikTok Shop là “ao thun den size M”, trên Lazada không có mã, hệ thống không thể tự biết đó là cùng một hàng. Làm sạch SKU và mapping là việc của shop, phần mềm chỉ cung cấp công cụ. Xem chuẩn hóa master data SKU, barcode và mapping đa sàn.
Sai lầm 3: “Nhập tồn từ file Excel sang là xong”
Tồn trong file Excel cũ gần như chắc chắn đã lệch thực tế. Nhập con số sai vào hệ thống mới chỉ chuyển lỗi sang chỗ mới, và đội sẽ kết luận “phần mềm cũng sai”. Tồn đầu kỳ phải được kiểm đếm thực tế, ít nhất với SKU chiếm 80% đơn.
Sai lầm 4: “Phần mềm bán hàng đa kênh = quản lý kho”
Quản lý tồn tổng theo kho khác với quản lý hàng theo vị trí, theo lần lấy, theo người. Nếu lỗi là lấy sai, cần quét barcode khi lấy/kiểm/đóng gói và vị trí kệ — đó là WMS.
Sai lầm 5: “Chạy song song vài tháng cho chắc”
Chạy song song dài khiến đội nhập hai lần, rồi tin file Excel hơn vì quen, rồi quay lại. Chạy song song nên 1–2 tuần với tiêu chí dừng viết trước (mục 9).
Sai lầm 6: “Đợi qua mùa sale rồi mới chuyển” — hoặc ngược lại “chuyển ngay trước sale”
Không go-live trong 2–3 tuần trước một campaign lớn. Nhưng chờ “qua mùa sale” mãi thì mùa sale lúc nào cũng có. Chọn cửa sổ 4–6 tuần giữa hai đợt lớn và lập kế hoạch ngược từ đó. Xem kế hoạch vận hành kho mùa sale 11.11, 12.12.
Sai lầm 7: “Doanh thu 1 tỷ thì mới cần”
Ngưỡng doanh thu liên quan đến nghĩa vụ hóa đơn và thuế, không phải độ phức tạp vận hành. Một shop doanh thu thấp nhưng 5 gian hàng và 600 SKU vẫn gặp lệch tồn. Ngược lại, nghĩa vụ hóa đơn điện tử cũng là lý do riêng để cần dữ liệu đơn chuẩn: hóa đơn điện tử và dữ liệu kế toán cho ecommerce.
8. Dữ liệu cần chuẩn bị trước khi bỏ Excel
| Dữ liệu | Tiêu chuẩn tối thiểu | Kiểm tra |
|---|---|---|
| Mã SKU nội bộ | Một mã duy nhất cho mỗi biến thể; không dấu, không khoảng trắng; quy tắc đặt mã viết ra | Không có hai biến thể cùng mã, không có biến thể thiếu mã |
| Barcode | Mỗi SKU có barcode (của nhà sản xuất hoặc nội bộ); một barcode chỉ thuộc một SKU | Quét thử 20 SKU ngẫu nhiên ra đúng tên |
| Mapping SKU sàn | Mọi listing trên mọi gian hàng trỏ về SKU nội bộ | Tỷ lệ listing chưa map = 0 với SKU đang bán |
| Combo/bộ | Danh sách combo với thành phần và số lượng | Bán thử một combo, tồn thành phần giảm đúng |
| Tồn đầu kỳ | Kiểm đếm thực tế theo kho (và vị trí nếu dùng WMS) | Ưu tiên SKU chiếm 80% đơn |
| Vị trí kho (nếu WMS) | Mã kệ/ô dán nhãn quét được | Mỗi SKU bán chạy có vị trí lấy hàng cố định |
| Trạng thái đơn và quyền | Ai được hủy, sửa, điều chỉnh tồn | Ghi thành bảng phân quyền |
| Quy trình hàng hoàn | Nhận theo mã vận đơn, phân loại bán lại/lỗi/chờ | Thử 5 kiện hoàn thật |
Thời gian làm sạch thực tế: shop vài trăm SKU thường cần 1–2 tuần nếu có người phụ trách riêng; shop vài nghìn SKU với nhiều listing trùng có thể cần lâu hơn. Đây là phần đáng đầu tư nhất của cả quá trình chuyển đổi. Chi tiết: làm sạch dữ liệu trước go-live.
9. Kế hoạch chuyển đổi 6 tuần
| Tuần | Việc chính | Người chịu trách nhiệm | Đầu ra |
|---|---|---|---|
| 1 | Đo chi phí lỗi 30 ngày, phân loại lỗi đơn/kho, chọn phạm vi (OMS hay OMS + WMS) | Chủ shop + trưởng vận hành | Bảng C1–C4, danh sách lỗi theo tầng |
| 2 | Chuẩn hóa mã SKU, gán barcode, danh sách combo | Người phụ trách sản phẩm | File master SKU sạch |
| 3 | Kết nối gian hàng, mapping SKU sàn, cấu hình kho và quyền; dán mã vị trí nếu dùng WMS | Đối tác triển khai + vận hành | 100% listing đang bán đã map |
| 4 | Kiểm đếm tồn đầu kỳ (cuối ngày, sau chuyến xe cuối), nhập tồn, đào tạo theo vai trò | Trưởng kho | Biên bản kiểm đếm, danh sách người đã qua bài thực hành |
| 5 | Chạy song song: hệ thống là nguồn chính, Excel chỉ đọc ra để so | Trưởng vận hành | Nhật ký chênh lệch hằng ngày |
| 6 | Khóa file Excel (chỉ đọc), rà soát sau 7 ngày | Chủ shop | Quyết định chính thức, chỉ số sau go-live |
Tiêu chí bỏ file Excel (viết trước khi chạy song song)
- 3–5 ngày liên tiếp không có đơn nào từ sàn không về hệ thống.
- Kiểm đếm mẫu 20–30 SKU bán chạy mỗi ngày: chênh lệch tồn bằng 0 hoặc có lý do ghi nhận.
- Không có đơn bán vượt tồn do lỗi mapping.
- Đối soát ngày giữa đơn đã giao và báo cáo sàn khớp, chênh lệch có giải thích.
- Mọi người trong ca thao tác được bằng hệ thống mà không cần hỏi lại file.
Không go-live trong 2–3 tuần trước campaign lớn. Kế hoạch triển khai không gián đoạn chi tiết: triển khai OMS + WMS không gián đoạn.
10. Những gì nên giữ lại Excel làm
Bỏ Excel không có nghĩa là xóa Excel. Excel vẫn tốt cho:
- Phân tích tạm, mô hình giá, kế hoạch campaign — dữ liệu xuất ra từ hệ thống.
- Báo cáo đặc thù chưa có trong hệ thống, miễn là đọc ra chứ không ghi ngược vào.
- Nhập hàng loạt có kiểm soát (danh mục SKU mới, giá) qua chức năng import của hệ thống.
Nguyên tắc: hệ thống là nguồn sự thật cho đơn, tồn và trạng thái; Excel chỉ là nơi đọc và phân tích. Khi có ai đó sửa tồn trong Excel rồi “nhập lại”, quá trình chuyển đổi đã thất bại một phần.
11. Ước tính chi phí và hoàn vốn: cách so đúng
So tổng chi phí sở hữu năm đầu với chi phí lỗi cộng giờ công tiết kiệm được:
Chi phí năm đầu = phí phần mềm × 12
+ phí triển khai/đào tạo
+ thiết bị (máy quét, PDA, máy in nhãn) nếu dùng WMS
+ giờ công nội bộ cho làm sạch dữ liệu và kiểm đếm
Lợi ích năm = (C1 + C2 + C3 + C4) × 12 × tỷ lệ giảm kỳ vọng
+ doanh thu thêm do không phải chia tồn cố định“Tỷ lệ giảm kỳ vọng” nên lấy thận trọng (ví dụ 50–70% cho C1, C4 khi có đồng bộ tự động; C2 chỉ giảm mạnh nếu có quét mã trong kho). Không dùng số 90–100% trong các tài liệu marketing. Phân tích sâu hơn về hoàn vốn WMS: chi phí và ROI WMS cho ecommerce Việt Nam.
Ghi chú minh bạch: bài viết không đưa số liệu khách hàng cụ thể. Mọi con số là giả định minh họa để thay bằng dữ liệu của shop.
12. Checklist 5 việc làm ngay trong tuần này
- Tính đơn/ngày × số kênh dùng chung tồn và đếm số SKU biến thể đang bán. Đặt hai con số cạnh bảng ngưỡng ở mục 2.
- Lấy số đơn hủy do hết hàng và đơn giao sai trong 30 ngày từ Seller Center từng sàn; điền bảng C1–C4.
- Phân loại 10–20 lỗi gần nhất vào “tầng đơn/tồn” hay “tầng kho” để biết cần OMS hay OMS + WMS.
- Kiểm tra mã SKU: lọc file xem có biến thể nào thiếu mã, trùng mã, hoặc listing trên sàn không có mã. Đó là khối lượng làm sạch thật.
- Chọn cửa sổ chuyển đổi 4–6 tuần không trùng 2–3 tuần trước campaign lớn, và người chịu trách nhiệm cho từng tuần.
13. Câu hỏi nên đặt cho nhà cung cấp khi rời Excel
- Đồng bộ tồn lên từng sàn theo cơ chế nào, độ trễ điển hình bao lâu, xử lý thế nào khi API sàn lỗi?
- Mapping SKU sàn làm hàng loạt được không, cảnh báo listing chưa map ra sao?
- Combo trừ tồn thành phần thế nào?
- Hàng hoàn nhận theo mã vận đơn và cộng lại tồn theo tình trạng ra sao?
- Có quét barcode khi lấy, kiểm, đóng gói không — hay chỉ in nhãn?
- Xuất toàn bộ dữ liệu khi cần (đơn, tồn, lịch sử) được không?
Cách chấm điểm và thử nghiệm trên dữ liệu thật: chọn và nghiệm thu OMS + WMS bằng POC. Phạm vi cam kết dịch vụ: cam kết dịch vụ.
14. Kết luận
Câu hỏi đúng không phải “shop bao nhiêu đơn thì bỏ Excel”, mà là “mỗi tháng Excel đang làm shop mất bao nhiêu, và lỗi nằm ở tầng nào”. Khi đơn/ngày × số kênh vượt khoảng 150–200, có từ 2–3 người cùng sửa tồn, hoặc chi phí lỗi vượt phí phần mềm, hãy chuyển sang OMS. Khi lỗi nằm trong kho — lấy sai, không tìm thấy, hàng hoàn, người mới — hãy tính OMS + WMS. Và dù chọn gì, phần quyết định thành công là làm sạch SKU, kiểm đếm tồn đầu kỳ và chạy song song ngắn có tiêu chí dừng.
Để đánh giá sát doanh nghiệp, hãy 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 câu hỏi thường gặp, rồi đăng ký tư vấn. 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.