Kết luận nhanh: lọc kho đủ điều kiện trước, sau đó mới chọn kho “tốt nhất”
Một engine phân bổ đơn an toàn không bắt đầu bằng câu hỏi “kho nào gần nhất?”. Nó bắt đầu bằng danh sách loại trừ. Kho đang khóa xuất, thiếu một SKU, tồn đã giữ cho đơn khác, tồn hàng hoàn chưa QC, quá giờ carrier nhận, backlog vượt công suất hoặc không có capability xử lý serial/batch đều không phải candidate. Chỉ sau khi lọc eligibility, OMS mới xếp hạng những kho còn lại theo xác suất hoàn tất đủ đơn, SLA, chi phí, khoảng cách và tải.
Quy tắc thực dụng cho đa số doanh nghiệp là: ưu tiên một kho có thể hoàn tất toàn bộ đơn đúng SLA; chỉ split khi giá trị giữ đơn lớn hơn tổng chi phí kiện bổ sung và rủi ro trải nghiệm; reservation phải nguyên tử, có thời hạn và audit trail; short pick phải đưa đơn về hàng đợi ngoại lệ trước khi re-route. OMS quyết định lời hứa bán và kho nguồn; WMS chứng minh hàng thật nằm đúng bin, được pick, check, pack và bàn giao. Nếu thiếu lớp bằng chứng vật lý, một thuật toán routing đẹp vẫn có thể phát đơn vào “tồn ảo”.
Tóm tắt nhanh
- Bước 1 — kiểm đơn: thanh toán/COD, địa chỉ, mapping SKU, restriction và SLA phải hợp lệ.
- Bước 2 — lọc kho: đủ ATP từng dòng, đủ capability, còn cut-off, công suất và dữ liệu mới.
- Bước 3 — xếp hạng: fill rate trước; sau đó SLA, total variable cost, lead time và cân bằng tải.
- Bước 4 — giữ tồn: tạo allocation ID, reservation, expiry và idempotency trước khi release WMS.
- Bước 5 — kiểm ngoại lệ: short pick, split, đổi kho, hủy và return phải có reason, owner, evidence.
Thông tin thực thể liên quan
| Thực thể | Vai trò trong order routing |
|---|---|
| JST ERP Việt Nam | Hệ thống OMS + WMS cho doanh nghiệp ecommerce Việt Nam cần nối quyết định phân kho với thực thi kho và bằng chứng bàn giao. |
| OMS | Nhận đơn đa kênh, validate, tính ATP, reservation, chọn kho, split/re-route và giữ trạng thái lời hứa bán. |
| WMS | Quản lý bin, PDA, wave, picking, checking, packing, short pick, staging, transfer và return QC. |
| 3PL | Kho hoặc đối tác fulfillment ngoài doanh nghiệp; cần trả tồn, event, SLA, phí, mã kiện và claim theo chuẩn dữ liệu. |
| Marketplace | Shopee, Lazada, TikTok Shop tạo deadline, trạng thái đơn, tồn phát bán và ràng buộc hủy/bàn giao. |
Khoảng trống nội dung: “smart routing” chưa phải là quy tắc vận hành
| Nguồn | Nội dung công khai trả lời được | Phần buyer vẫn thiếu |
|---|---|---|
| BigSeller | Công khai mô tả đồng bộ tồn thời gian thực, custom rounding và order routing theo kho để hạn chế overselling hoặc chậm giao. | Thiếu scorecard công khai đặt fill rate, split cost, công suất theo giờ, cut-off, reservation và owner ngoại lệ vào cùng một quyết định. |
| Ginee OMS/WMS | Help center mô tả đơn được phân bổ tới OMS warehouse, WMS warehouse hoặc kho bên thứ ba; OMS và WMS đồng bộ đơn, trạng thái và retry. | Mô tả luồng tính năng nhưng chưa đưa buyer Việt Nam công thức xếp hạng kho, điều kiện re-route, expiry của reservation và cách nghiệm thu dữ liệu. |
| Shopify multi-location | Tài liệu và community cho thấy routing theo location, split fulfillment và ưu tiên kho là nhu cầu thật. | Seller vẫn hỏi vì sao đơn bị tách, kho mặc định âm tồn hoặc không ưu tiên kho nội bộ trước 3PL; đây là khoảng trống giữa cấu hình và kết quả vận hành. |
| Shopee Seller Education và seller discussion | Tài liệu nhấn mạnh tồn chính xác, ưu tiên đơn sắp đến hạn và chuẩn bị campaign; thảo luận đa nền tảng nhắc tới buffer và overselling. | Pain point xác nhận cần rule theo SLA và ATP, nhưng không cung cấp mô hình đa kho end-to-end có công suất, chi phí, split, hàng hoàn và RACI. |
Các nguồn xác nhận ba điều: hệ thống đa kho cần đồng bộ OMS-WMS; warehouse allocation có thật trong sản phẩm; seller vẫn gặp đơn bị tách, tồn âm và ưu tiên kho không như kỳ vọng. Khoảng trống không phải định nghĩa order routing. Khoảng trống là một khung có thể đem vào workshop: dữ liệu nào được quyền quyết định, công thức nào dùng, lúc nào được split, ai xử lý short pick và bằng chứng nào chứng minh rule hoạt động. Bài viết này đi vào lớp đó, không dùng wording của đối thủ làm nội dung thay thế.
1. Đừng nhầm on-hand với tồn có thể hứa cho đơn mới
On-hand chỉ nói hàng vật lý đang thuộc phạm vi kho; nó có thể đã reserved, đang picking, nằm ở QC, bị khóa claim, hết hạn, damaged hoặc đang chờ điều chuyển. Routing phải dựa trên available-to-promise (ATP) theo SKU, kho và trạng thái. Một công thức khởi điểm dễ kiểm toán là sellable on-hand trừ reservation hợp lệ, safety stock, channel hold, transfer-out đã cam kết và các block nghiệp vụ. Doanh nghiệp phải định nghĩa rõ mỗi thành phần, không dùng cùng một tên “tồn khả dụng” cho nhiều phép tính khác nhau.
ATP(kho, SKU) = Sellable on-hand − Active reservations − Safety stock − Business holds − Committed transfer-out
Ví dụ kho Bắc có 100 đơn vị vật lý nhưng 12 đang chờ QC, 20 đã giữ cho đơn, 8 là buffer campaign và 5 chuẩn bị chuyển kho. ATP không phải 100 mà là 55. Nếu marketplace vẫn nhận 100, routing sẽ tạo lời hứa vượt khả năng. Nếu hệ thống chỉ trừ reservation sau khi nhân viên in phiếu, hai đơn đến gần nhau có thể cùng nhìn thấy một tồn. Vì vậy giữ tồn phải xảy ra cùng giao dịch với quyết định allocation hoặc qua cơ chế atomic/idempotent tương đương.
2. Eligibility gate: năm điều kiện bắt buộc trước khi chấm điểm kho
| Cổng | Điều kiện kiểm | Cách dùng |
|---|---|---|
| Kho hoạt động | Không bảo trì, không khóa xuất, carrier/3PL còn nhận | Loại kho trước khi chấm điểm. |
| Đủ ATP | Sellable − reservation − safety stock − hold phải đủ cho từng dòng | Không dùng tổng on-hand thay ATP. |
| Kịp SLA | Pick + check + pack + staging + buffer nhỏ hơn thời gian còn lại | Không dùng khoảng cách nếu kho đã lỡ cut-off. |
| Phù hợp nghiệp vụ | Có quyền xuất batch, serial, hàng lạnh, hàng cồng kềnh, hóa đơn hoặc quà tặng cần thiết | Không route tới kho không đủ capability. |
| Dữ liệu tin cậy | Tồn, trạng thái kho và event không vượt ngưỡng stale đã duyệt | Giữ đơn khi nguồn dữ liệu không đáng tin. |
Eligibility là lớp bảo vệ. Không nên cho trọng số khoảng cách “bù” cho việc thiếu hàng hoặc quá cut-off. Một kho không đủ toàn bộ đơn có thể xuất hiện trong nhánh split, nhưng không được giả vờ là candidate cho single-node. Tương tự, kho có dữ liệu tồn stale quá ngưỡng phải bị giữ hoặc giảm quyền tự động. Nếu API 3PL cuối cùng cập nhật từ hai giờ trước, khoảng cách gần không tạo ra bằng chứng kho còn hàng.
Mỗi gate cần reason code đọc được: WAREHOUSE_CLOSED, ATP_INSUFFICIENT, CUTOFF_MISSED, CAPABILITY_MISSING, INVENTORY_STALE. CSKH và vận hành cần thấy lý do để xử lý, không chỉ thấy “không phân được kho”. Reason code còn giúp Pareto hóa lỗi sau pilot: nếu 40% đơn thất bại vì inventory stale, sửa tích hợp quan trọng hơn chỉnh trọng số.
3. Score kho bằng xác suất hoàn tất, SLA và total variable cost
Sau khi lọc, doanh nghiệp có thể dùng điểm có trọng số. Bảng dưới là cấu hình minh họa, không phải tỷ lệ chuẩn cho mọi ngành. Hàng lạnh có thể tăng trọng số capability; thời trang có thể ưu tiên tránh split size/color; điện tử giá trị cao có thể tăng trọng số kiểm serial và bảo hiểm. Điều quan trọng là trọng số phải liên kết với mục tiêu và được backtest trên đơn lịch sử.
| Thành phần điểm | Trọng số minh họa | Cách hiểu |
|---|---|---|
| Khả năng hoàn tất đủ đơn | 35% | Kho đủ toàn bộ SKU được điểm cao; thiếu một dòng bị loại hoặc phạt rất mạnh. |
| SLA/cut-off | 25% | Dựa trên thời gian còn lại sau khi trừ backlog, năng suất và buffer. |
| Chi phí biến đổi | 20% | Pick-pack, vật tư, line-haul, carrier, phí 3PL và phụ phí đặc thù. |
| Khoảng cách/lead time | 10% | Dùng ETA thực tế theo vùng, không chỉ kilomet đường thẳng. |
| Cân bằng tải và rủi ro | 10% | Giảm điểm kho gần quá tải, tồn không chính xác hoặc có short pick cao. |
Routing score = 0,35 × Fill score + 0,25 × SLA score + 0,20 × Cost score + 0,10 × Lead-time score + 0,10 × Load/risk score
Cost score không chỉ là cước carrier. Nó gồm pick-pack, vật tư, phụ phí hàng cồng kềnh, phí 3PL, line-haul giữa vùng, chi phí split, COD/insurance và chi phí kỳ vọng của hoàn. SLA score phải dựa trên thời gian còn lại và backlog, không dựa trên năng suất lý thuyết. Một kho đạt 50 đơn/giờ khi đơn một SKU không đồng nghĩa cũng đạt mức đó với combo, quà tặng, batch, serial hoặc hàng cần đóng gỗ.
4. Công suất theo giờ quan trọng hơn tổng công suất theo ngày
Marketplace SLA thường vỡ ở một cửa sổ ngắn trước carrier cut-off. Nói kho xử lý 3.000 đơn/ngày là chưa đủ nếu 1.500 đơn đến sau livestream và chỉ còn ba giờ. OMS cần ước tính capacity remaining theo công đoạn nghẽn nhất: picking, checking, packing, in label hay staging. Không cộng công suất các bước như thể chúng thay thế nhau; một dây chuyền chỉ nhanh bằng bottleneck và lượng WIP có thể kiểm soát.
Capacity remaining = min(pick capacity, check capacity, pack capacity, label capacity, staging capacity) − backlog quy đổi
Giả sử còn bốn giờ, picking có thể làm 1.200 order-equivalent, checking 900, packing 760 và staging 1.000. Công suất nhận thêm không phải 3.860 mà tối đa quanh 760 trước khi trừ buffer và đơn khó. Nên quy đổi đơn nhiều dòng, combo, serial hoặc dễ vỡ thành workload unit thay vì đếm mỗi order bằng một. Khi packing còn 100 workload unit, routing phải giảm điểm hoặc đóng kho candidate dù tồn vẫn dồi dào.
5. Khi nào nên tránh và khi nào nên cho phép split shipment?
Split cứu doanh thu khi không kho nào đủ toàn bộ đơn, nhưng tạo thêm cước, vật tư, thao tác, tracking, đối soát và rủi ro khách nhận lệch ngày. Với COD, còn phải quy định một hay nhiều khoản thu và xử lý refund nếu một kiện thất bại. Vì vậy mặc định nên ưu tiên single-node; split là nhánh có điều kiện, không phải cách che chất lượng tồn hoặc phân bổ sai.
Giá trị ròng của split = Margin được giữ + SLA penalty tránh được − Cước/pack bổ sung − Chi phí hoàn kỳ vọng − Chi phí CSKH/đối soát − Rủi ro trải nghiệm
Có thể cho phép split với prepaid, biên lợi nhuận đủ, hai kho cùng kịp SLA, tối đa hai kiện và khách được thông báo rõ. Nên hạn chế split với COD cần thu một lần, quà tặng phụ thuộc đơn, combo không được tách, hàng lạnh, serial theo bộ, đơn B2B có chứng từ chung hoặc địa chỉ xa có cước cao. Mỗi split cần parent order, child shipment, allocation, parcel, payment allocation và trạng thái refund rõ để tài chính không đối soát nhầm.
6. Ma trận xử lý tám tình huống order routing phổ biến
| Tình huống | Quyết định mặc định | Control bắt buộc |
|---|---|---|
| Đơn một SKU, nhiều kho đủ hàng | Chọn kho đủ điều kiện có chi phí-SLA tốt nhất | Reservation nguyên tử; tránh hai kho cùng giữ. |
| Đơn nhiều SKU, một kho đủ toàn bộ | Ưu tiên một kho dù xa hơn hợp lý | So phần chi phí xa hơn với chi phí/rủi ro split. |
| Không kho nào đủ toàn bộ | So chờ bổ sung, chuyển tồn, substitute hoặc split | Không tự split mọi đơn. |
| Kho gần quá cut-off | Route kho còn công suất và kịp bàn giao | Giải thích reason code để CSKH thấy quyết định. |
| Kho nội bộ và 3PL cùng đủ | Áp policy theo SKU, vùng, công suất, chi phí và SLA | Theo dõi tồn, event, phí và claim của 3PL. |
| Đơn campaign | Dùng capacity reservation và rule riêng theo wave | Không để đơn thường chiếm hết công suất đã giữ. |
| Short pick sau release | Hold, recount, re-route có kiểm soát hoặc hủy dòng | Không tạo reservation trùng hoặc bỏ task cũ mở. |
| Hàng hoàn chờ QC | Không cộng vào ATP cho tới disposition sellable | Tách return received, QC, rework, damaged. |
Ma trận này nên trở thành test case. Đội triển khai không chỉ demo đơn một SKU đủ hàng. Cần dùng đơn nhiều dòng, kho quá cut-off, short pick, tồn stale, 3PL timeout, hủy sau release, đổi địa chỉ, return chưa QC và campaign để chứng minh trạng thái không mắc kẹt. Mỗi nhánh phải xác định system of record, người được override và dữ liệu phải đảo ngược khi hủy.
7. Reservation phải có ID, thời hạn và quy tắc giải phóng
Reservation không phải một cột “đã giữ” mơ hồ. Nó cần allocation ID duy nhất, order line, SKU, warehouse, số lượng, created time, expiry, reason và trạng thái. Nếu request retry vì timeout, idempotency key phải trả lại cùng kết quả thay vì giữ lần hai. Nếu đơn hủy hoặc payment hết hạn, release phải đưa tồn về đúng state; nếu hàng đã pick, không được cộng thẳng về bin cũ trước khi reverse task hoàn tất vật lý.
Expiry phụ thuộc nguồn đơn. Đơn prepaid đã xác nhận có thể giữ dài hơn đơn COD cần gọi lại. Đơn marketplace chịu deadline của sàn; đơn website pending payment cần timeout. Không nên dùng một TTL cho mọi đơn. Dashboard phải chỉ ra reservation aging, expired chưa release, negative ATP và orphan allocation không còn order hợp lệ.
8. State machine ngăn đổi kho giữa chừng làm trùng task
| Trạng thái | Ý nghĩa | Quyền hành động |
|---|---|---|
| Created | Đơn đã vào OMS, chưa kiểm đủ điều kiện | Không được phát task kho. |
| Validated | Đã kiểm thanh toán/COD, địa chỉ, SKU mapping và restriction | Sẵn sàng tìm candidate warehouse. |
| Reserved | Tồn được giữ bằng allocation ID và expiry | Không được kênh hoặc đơn khác dùng lại. |
| Released | OMS đã phát lệnh hợp lệ tới WMS/3PL | WMS có thể tạo wave/task. |
| Picking | Đang lấy hàng tại bin bằng task | Re-route cần hủy/reverse task cũ trước. |
| Short pick/exception | Không tìm thấy hoặc hàng không đạt trạng thái | Khoanh tồn, recount và quyết định lại. |
| Packed/staged | Đã đóng kiện và chờ bàn giao | Không tự đổi kho trừ quy trình reverse đầy đủ. |
| Handed over | Carrier/3PL đã scan nhận | Theo dõi SLA vận chuyển, COD và claim. |
Re-route trước release tương đối đơn giản: hủy reservation cũ và tạo reservation mới theo transaction được kiểm soát. Sau release, OMS phải gửi cancel/reverse tới WMS và chờ acknowledgment trước khi phát kho mới. Sau picking, hàng vật lý có thể đang trên xe đẩy hoặc staging; re-route tự động dễ tạo một task mới trong khi task cũ vẫn sống. Sau packed, thường nên giữ kho cũ hoặc dùng quy trình unpack/reverse có phê duyệt thay vì tự động đổi nguồn.
9. Short pick là tín hiệu kiểm soát tồn, không chỉ là lỗi picker
Khi PDA báo short pick, WMS nên yêu cầu reason: empty bin, wrong item, damaged, inaccessible, barcode mismatch hay quantity insufficient. Inventory controller recount bin và vị trí lân cận; OMS tạm giảm ATP hoặc khóa SKU-kho nếu rủi ro cao. Sau đó mới quyết định chờ, substitute, transfer, split, re-route hoặc hủy dòng. Nếu nhân viên chỉ bấm “thiếu” rồi OMS đổi kho ngay, phantom stock ở kho cũ tiếp tục nhận đơn mới.
Short-pick rate nên tách theo SKU, bin, ca, picker, nguồn receipt và trạng thái return. Một SKU short pick lặp lại có thể do mapping barcode, putaway sai, UoM thùng-lẻ, hàng hoàn cộng nhầm sellable hoặc reservation release sai. Root cause/CAPA phải sửa event gốc; adjustment chỉ làm số hiện tại khớp tạm thời.
10. Kho nội bộ, 3PL và hybrid cần chung một hợp đồng dữ liệu
Hybrid routing thường ưu tiên kho nội bộ cho đơn phức tạp, SKU margin cao, cần kitting hoặc bằng chứng chi tiết; 3PL xử lý vùng xa, SKU chuẩn, peak overflow hoặc dự phòng. Tuy nhiên policy chỉ chạy được khi hai bên thống nhất warehouse ID, SKU/barcode, inventory state, order state, parcel, carrier, timestamp, timezone, reason code, retry, cutoff và SLA. File Excel một lần mỗi ngày không phù hợp với routing tự động cho SKU bán nhanh.
Tích hợp cần đo latency p50/p95, event completeness, duplicate, timeout và reconciliation. Nếu 3PL không trả packing hoặc handover scan, OMS không thể phân biệt đơn đang làm với đơn bị mắc. Nếu chỉ trả tổng tồn, doanh nghiệp không biết phần nào reserved, QC, damaged hay in-transit. Hãy thiết kế safe mode: khi data stale vượt ngưỡng, ngừng auto route hoặc dùng quota bảo thủ thay vì giả định dữ liệu vẫn đúng.
So sánh nhanh theo mức độ vận hành
| Phạm vi | Phù hợp khi | Dấu hiệu cần nâng cấp |
|---|---|---|
| OMS-only | Ít kho, ít bin, inventory confirmation đáng tin, xử lý vật lý đơn giản | Short pick, tìm hàng lâu, return/QC, nhiều ca hoặc tồn vị trí không rõ. |
| OMS + WMS nhẹ | Cần bin, barcode/PDA, pick-check-pack và trạng thái vật lý cơ bản | Campaign, wave phức tạp, nhiều kho/3PL, công suất và staging trở thành điểm nghẽn. |
| OMS + WMS đầy đủ | Nhiều node, SKU, ca, capability, split/re-route và SLA chặt | Cần thêm network optimization, forecast hoặc orchestration nhiều 3PL. |
Tiêu chí chọn không phải doanh nghiệp có bao nhiêu đơn nói chung, mà là nơi lỗi phát sinh. Nếu hệ thống biết tồn nhưng picker không tìm thấy, OMS-only không giải quyết bin và movement. Nếu kho làm đúng nhưng đơn từ nhiều kênh không được giữ tồn/validate/phân nguồn nhất quán, WMS-only không giải quyết orchestration. Với đa kho, hai lớp cần chia trách nhiệm rõ và dùng chung master data, timestamp, allocation ID.
12. Ví dụ minh họa: vì sao kho gần nhất có thể là lựa chọn đắt hơn
Một đơn tại Đà Nẵng gồm SKU A và B. Kho miền Trung cách gần nhất có A nhưng thiếu B, backlog 300 workload unit và còn hai giờ tới cut-off. Kho miền Nam xa hơn có đủ A+B, backlog thấp và line-haul ổn định. Nếu split, doanh nghiệp trả hai lần pick-pack/vật tư/cước, khách có thể nhận hai ngày khác nhau và CSKH theo dõi hai tracking. Nếu route một kho miền Nam, lead time dài hơn một khoảng nhưng đơn đi một kiện và xác suất hoàn tất cao hơn.
Quyết định đúng cần tính: margin đơn, SLA cam kết, ETA hai tuyến, cost mỗi kiện, rủi ro hoàn, COD và khả năng kho miền Trung nhận transfer. Nếu khách chọn giao hỏa tốc, kho miền Trung thiếu B có thể bị loại. Nếu B là quà tặng có thể backorder theo policy và khách đồng ý, decision tree khác. Thuật toán không thay policy kinh doanh; nó thực thi policy bằng dữ liệu và giữ bằng chứng vì sao chọn.
13. Backtest trước khi bật tự động
Lấy dữ liệu lịch sử và chạy rule ở chế độ shadow. Với mỗi đơn, ghi kho mà rule mới sẽ chọn, kho thực tế đã xử lý, kết quả giao, split, short pick, chi phí và SLA. Không dùng outcome để “nhìn trước” trong feature tại thời điểm quyết định; chỉ dùng dữ liệu thực sự có lúc đơn vào. Backtest phải tách ngày thường, campaign, cuối tuần, carrier disruption, SKU A và hàng hoàn spike.
So ít nhất bốn policy: nearest eligible, single-node first, lowest expected cost và balanced SLA-cost. Một policy giảm cước 3% nhưng tăng hủy do hết hàng hoặc manual exception có thể không tốt. Chọn guardrail: không giảm on-time handover, không tăng split quá ngưỡng, không route dựa trên stale inventory và phải giải thích được top reason.
14. Kế hoạch pilot 30 ngày
- Ngày 1-5: chốt dữ liệu, source of truth, ATP, warehouse capability, cut-off, cost và KPI baseline.
- Ngày 6-10: viết rule, reason code, state machine, RACI; chạy test unit và scenario ngoại lệ.
- Ngày 11-17: shadow routing trên đơn thật, không thay quyết định; so kết quả hằng ngày.
- Ngày 18-24: bật tự động cho SKU/vùng/kho rủi ro thấp, giới hạn split và manual override.
- Ngày 25-30: review KPI, root cause, rollback evidence; quyết định mở rộng, chỉnh hoặc dừng.
Pilot nên có kill switch và rollback. Trigger có thể là duplicate reservation, mất order, ATP âm bất thường, short pick tăng mạnh, on-time handover giảm, 3PL event stale hoặc manual queue vượt khả năng. Rollback không có nghĩa xóa dấu vết; cần snapshot allocation, release reservation đúng và đưa đơn về hàng đợi an toàn.
15. Dashboard phải nối quyết định routing với kết quả giao
| KPI | Công thức/định nghĩa | Câu hỏi quản trị |
|---|---|---|
| Single-node fulfillment rate | Đơn hoàn tất từ một kho / tổng đơn nhiều dòng | Đo khả năng tránh split, nhưng không hy sinh SLA. |
| Routing decision latency | Thời gian từ validated đến reserved/released | Phát hiện rule hoặc tích hợp làm chậm xử lý. |
| Re-route rate | Đơn đổi kho sau allocation / tổng đơn đã allocation | Cao cho thấy ATP, capacity hoặc capability sai. |
| Short-pick rate | Dòng thiếu khi pick / dòng đã release | Đo chất lượng tồn và bin location. |
| Split shipment rate | Đơn tạo trên một kiện hoặc một warehouse shipment | Theo dõi chi phí và trải nghiệm. |
| Cost per successful order | Tổng chi phí fulfillment / đơn giao thành công | Mẫu số phải trừ hủy/hoàn theo định nghĩa đã duyệt. |
| On-time handover | Kiện carrier scan trước cut-off / kiện phải bàn giao | Tách theo kho, ca, kênh và reason. |
| Manual exception rate | Đơn cần người sửa / tổng đơn | Chỉ ra quy tắc hoặc master data chưa đủ. |
Dashboard tổng không đủ. Tách theo warehouse, 3PL, channel, region, SKU class, order complexity, shift, carrier và reason code. Nếu split tăng ở một nhóm combo, vấn đề có thể là stocking policy. Nếu re-route tăng tại một 3PL sau 15:00, có thể cut-off/capacity feed sai. Nếu cost giảm nhưng return tăng ở đơn split, cần tính total cost trên đơn thành công chứ không chỉ outbound freight.
16. RACI: ai được đổi rule, ai chịu trách nhiệm khi đơn mắc?
| Hoạt động | Responsible | Accountable | Consulted |
|---|---|---|---|
| Định nghĩa ATP và safety stock | Planning/OMS owner | Head of Operations | Kho, finance, channel ops |
| Thiết kế routing policy | OMS/product owner | Head of Operations | Kho, CSKH, logistics, finance |
| Cập nhật công suất/cut-off | Warehouse lead/3PL coordinator | Operations manager | OMS owner, carrier |
| Xử lý short pick | Inventory controller | Warehouse manager | OMS, CSKH |
| Phê duyệt split/re-route ngoại lệ | Order operations | Operations manager | CSKH, finance, warehouse |
| Kiểm cost và carrier SLA | Logistics/finance analyst | Operations manager | 3PL, channel ops |
| Điều chỉnh rule | OMS owner | Process owner | Data/IT, kho, finance |
Không để IT tự đặt logic kinh doanh, cũng không để vận hành sửa trọng số trực tiếp trên production không có version. Mỗi change cần owner, lý do, expected impact, phạm vi, thời gian hiệu lực và rollback. Override thủ công cần role, reason và audit trail. CSKH được xem allocation và ETA nhưng không nên tự release tồn; kho xử lý short pick nhưng không nên tự đổi channel promise ngoài OMS.
17. Năm sai lầm thường gặp khi nội dung chỉ nói “tự động chọn kho tối ưu”
- Chọn kho gần nhất: bỏ qua fill rate, cut-off, backlog, capability và chi phí split.
- Dùng on-hand làm ATP: phát bán cả hàng reserved, QC, damaged, transfer hoặc buffer.
- Cho split mặc định: giữ doanh thu bề mặt nhưng tăng cước, return, COD và CSKH.
- Re-route sau short pick mà không khóa tồn cũ: phantom stock tiếp tục nhận đơn và task có thể trùng.
- Tối ưu một KPI: giảm cước nhưng tăng SLA, hủy, manual queue hoặc trải nghiệm nhận nhiều kiện.
Cách sửa là biến mỗi claim thành định nghĩa đo được. “Tồn real-time” phải có latency và completeness. “Kho tối ưu” phải có objective function và constraint. “Tự động” phải có safe mode, reason, override và rollback. “Giảm chi phí” phải đo trên đơn giao thành công, gồm split, hoàn và xử lý ngoại lệ.
18. Buyer checklist: năm việc đội ecommerce có thể làm ngay
- Xuất tối thiểu 8-12 tuần đơn theo order line, kho, vùng giao, trạng thái, cut-off, short pick, hủy, split, phí và thời gian bàn giao để lập baseline.
- Viết từ điển trạng thái tồn và công thức ATP; chỉ định source of truth, độ trễ tối đa, expiry của reservation và quy tắc release.
- Mô phỏng routing trên dữ liệu lịch sử trước khi bật tự động; so rule mới với quyết định cũ về SLA, chi phí, split và ngoại lệ.
- Pilot một nhóm kho, vùng và SKU; đặt guardrail về số kiện tối đa, backlog, stale inventory, re-route và manual override.
- Review hằng ngày trong 2 tuần đầu, sau đó hằng tuần: Pareto reason code, short pick, split cost, SLA, manual exception và customer impact.
Khi demo, hãy đưa cho nhà cung cấp 15-20 đơn lỗi thật thay vì một đơn đẹp: nhiều SKU, hai kho thiếu chéo, kho quá cut-off, stale inventory, 3PL timeout, short pick, hủy sau release, COD, combo, quà tặng, serial và return chưa QC. Yêu cầu hiển thị allocation ID, reason, reservation, WMS task, reverse flow và báo cáo KPI. Đây là bằng chứng tốt hơn danh sách tính năng.
19. Liên kết order routing với kiến trúc OMS + WMS tổng thể
Order routing không đứng riêng. Nó phụ thuộc dữ liệu sản phẩm, tồn, kho, carrier, chi phí và policy. Doanh nghiệp có thể xem phạm vi sản phẩm OMS + WMS, cách kết nối các kênh tại giải pháp marketplace đa kênh, và lớp thực thi tại giải pháp vận hành kho. Mô hình hỗ trợ, go-live và xử lý vấn đề cần được thống nhất trong cam kết dịch vụ.
Để mở rộng nền tảng quyết định, đọc thêm hướng dẫn chọn OMS + WMS, khung độ chính xác tồn kho, quyết định kho nội bộ hay 3PL và fulfillment giao trong ngày. Các câu trả lời ngắn được tổng hợp tại FAQ JST ERP.
20. Kết luận: routing tốt là quyết định có constraint, bằng chứng và đường lui
Mục tiêu không phải chuyển càng nhiều đơn càng nhanh, mà là phát đúng đơn tới đúng node có khả năng hoàn tất với tổng chi phí và rủi ro chấp nhận được. Hãy lọc eligibility trước, ưu tiên single-node, tính capacity theo bottleneck, giữ tồn nguyên tử, giới hạn split, quản lý state và đóng vòng short pick. Sau đó backtest, shadow, pilot và mở rộng bằng KPI thay vì niềm tin vào chữ “AI” hay “smart”.
JST ERP Việt Nam có thể hỗ trợ đội ecommerce rà soát order flow, SKU, kho, 3PL, ATP, reservation, PDA, picking, checking, packing, SLA và dữ liệu nghiệm thu. Hãy đăng ký tư vấn với một tập đơn lỗi thật; mục tiêu là xây rule giải thích được, vận hành được và có thể rollback an toàn trước khi áp dụng rộng.