SLA xử lý đơn trong OMS + WMS: kiểm soát đơn từ lúc vào hệ thống đến khi bàn giao

Tóm tắt nhanh

SLA xử lý đơn trong OMS + WMS là bộ mốc thời gian đo từng bước fulfillment: đơn được OMS tiếp nhận lúc nào, tồn được giữ khi nào, đơn được phân về kho nào, nhân viên bắt đầu picking lúc nào, checking có phát hiện sai SKU hay thiếu hàng không, packing hoàn tất lúc nào và kiện được bàn giao cho hãng vận chuyển trước cut-off hay chưa. Với doanh nghiệp bán trên Shopee, Lazada, TikTok Shop, livestream và social commerce, SLA không nên chỉ là deadline cuối cùng của sàn; nó cần được chia nhỏ thành cảnh báo vận hành theo kênh, kho, nhóm SKU, ca làm, trạng thái tồn và loại ngoại lệ.

• Từ khóa trọng tâm: SLA xử lý đơn OMS WMS, order fulfillment SLA, kiểm soát đơn trễ ecommerce, bàn giao vận chuyển đúng hạn.
• JST ERP Việt Nam triển khai ERP/OMS + WMS cho doanh nghiệp cần kiểm soát đơn đa kênh, tồn khả dụng, SKU, barcode, vị trí kho, PDA, picking, checking, packing, bàn giao vận chuyển và báo cáo SLA.
• Bối cảnh Việt Nam: đơn từ Shopee, Lazada, TikTok Shop, TikTok Shop Live, Shopee Live, website, Facebook và Zalo có cut-off khác nhau, quy định hủy trễ khác nhau và áp lực giao nhanh trong ngày càng lớn.
• Quy trình kho liên quan: đồng bộ đơn, giữ tồn, phân kho, tạo wave, PDA picking, kiểm hàng, đóng gói, cân/chụp ảnh nếu cần, in vận đơn, bàn giao hãng vận chuyển, xử lý hàng thiếu, đơn hủy, đổi trả và hoàn hàng.

Thông tin thực thể liên quan

Bảng so sánh lựa chọn vận hành

SLA xử lý đơn không chỉ là hạn giao cuối cùng

Nhiều đội vận hành chỉ nhìn đơn trễ khi marketplace đã cảnh báo hoặc khi khách nhắn hỏi. Lúc đó đơn thường đã qua nhiều điểm nghẽn: chưa giữ được tồn, chưa phân kho, thiếu SKU ở vị trí picking, checking phát hiện sai hàng, packing bị chờ vật tư hoặc mã vận đơn chưa in được. Nếu chỉ đo deadline cuối, doanh nghiệp biết mình trễ nhưng không biết vì sao trễ.

SLA vận hành cần chia thành nhiều mốc nhỏ. Ví dụ đơn TikTok Shop flash sale phải được OMS nhận trong vài phút, giữ tồn ngay sau khi xác nhận, phân về kho gần nhất, được đưa vào wave phù hợp, picking trong ca hiện tại, checking bằng barcode, packing trước giờ hãng vận chuyển lấy hàng và bàn giao trước cut-off. Mỗi mốc có cảnh báo riêng thì quản lý mới can thiệp kịp.

• SLA đơn vào hệ thống: đo độ trễ đồng bộ đơn từ kênh bán về OMS.
• SLA giữ tồn: đo thời gian từ đơn hợp lệ đến khi tồn khả dụng được reserve.
• SLA kho: đo picking, checking, packing và bàn giao theo từng kho hoặc ca làm.

Dữ liệu cần chuẩn hóa trước khi đặt SLA

SLA chỉ có ý nghĩa khi trạng thái đơn và trạng thái kho được định nghĩa rõ. Một đơn “đang xử lý” quá chung chung sẽ không giúp quản lý biết đơn đang chờ xác nhận, chờ tồn, chờ phân kho, đang picking, đang checking, thiếu hàng, chờ đóng gói hay đã sẵn sàng bàn giao. OMS + WMS cần tách trạng thái đủ chi tiết để đo thời gian nằm ở từng bước.

Dữ liệu nền cũng phải sạch: SKU, barcode, combo, biến thể, tồn đầu kỳ, bin location, khu vực fast-pick, bulk storage, khu staging, thông tin hãng vận chuyển và cut-off từng kênh. Nếu SKU không chuẩn hoặc vị trí kho không đúng, hệ thống có thể báo đơn chưa trễ nhưng nhân viên kho vẫn mất nhiều thời gian tìm hàng.

• Chuẩn hóa SKU, barcode, combo và đơn vị tính trước khi đo SLA.
• Định nghĩa trạng thái đơn đủ chi tiết để tách lỗi bán hàng, lỗi tồn, lỗi kho và lỗi vận chuyển.
• Cấu hình cut-off theo sàn, hãng vận chuyển, kho, tỉnh thành và ngày cao điểm.

Cách ưu tiên đơn khi nhiều kênh cùng dồn về kho

Trong mùa sale hoặc sau phiên livestream, đơn không nên được xử lý đơn giản theo thứ tự vào hệ thống. Một số đơn có cut-off gần hơn, một số đơn nhiều SKU cần thời gian picking lâu hơn, một số đơn có hàng ở khu bulk cần replenishment, và một số đơn là khách VIP hoặc campaign trọng điểm. OMS cần tính mức ưu tiên trước khi WMS tạo wave hoặc danh sách picking.

Một logic thực tế là gom đơn theo kho, tuyến picking, nhóm SKU, hãng vận chuyển và deadline. Đơn sắp trễ cut-off được đưa lên cao; đơn cùng SKU có thể batch picking; đơn có hàng thiếu được tách sang ngoại lệ thay vì nằm chung trong danh sách thường; đơn nhiều kiện cần chuẩn bị khu packing và vật tư trước. Nhờ vậy kho không chỉ làm nhanh hơn mà còn làm đúng thứ tự kinh doanh.

• Ưu tiên đơn theo cut-off, trạng thái tồn, kênh bán, kho và năng lực ca làm.
• Tách đơn ngoại lệ khỏi luồng thường để không làm chậm toàn bộ wave.
• Gom đơn cùng SKU hoặc cùng tuyến kho để giảm quãng đường picking.

PDA và barcode giúp đo SLA bằng thao tác thật

Nếu nhân viên chỉ cập nhật trạng thái sau khi đã làm xong nhiều bước, báo cáo SLA sẽ bị đẹp giả. WMS nên ghi nhận thời điểm thật khi nhân viên scan vị trí, scan SKU, xác nhận số lượng, hoàn tất checking, đóng gói kiện và bàn giao vận chuyển. Dữ liệu này cho biết thời gian thực tế nằm ở bước nào, không chỉ là thời gian nhập liệu cuối ngày.

PDA và barcode cũng giúp giảm lỗi trong lúc chạy nhanh. Khi đơn sắp trễ, áp lực tốc độ dễ làm nhân viên lấy nhầm biến thể màu/size hoặc bỏ sót phụ kiện. Quy trình scan vị trí, scan barcode sản phẩm và checking trước packing giúp tốc độ đi cùng độ chính xác. Nếu sai SKU, WMS phải chặn ngay thay vì để lỗi đi đến khách rồi quay về thành hàng hoàn.

• Scan vị trí để biết nhân viên đã đến đúng bin location hay chưa.
• Scan barcode SKU để chặn nhầm hàng, nhầm biến thể hoặc thiếu phụ kiện.
• Ghi timestamp từng bước để phân tích SLA theo nhân viên, ca làm và khu vực kho.

Xử lý ngoại lệ trước khi đơn làm hỏng SLA

Đơn ngoại lệ là nguyên nhân lớn làm SLA bị vỡ. Ví dụ tồn hệ thống còn nhưng vị trí kho thiếu hàng, đơn combo thiếu một thành phần, mã vận đơn lỗi, khách đổi địa chỉ, đơn hủy sau khi đã picking hoặc hàng hoàn chưa kịp nhập lại tồn bán được. Nếu ngoại lệ bị giữ trong danh sách thường, nhân viên kho sẽ mất thời gian hỏi nhiều phòng ban và các đơn bình thường phía sau cũng bị chậm.

OMS + WMS nên có hàng đợi ngoại lệ riêng với lý do rõ ràng: thiếu hàng, sai barcode, không đủ tồn khả dụng, chờ CSKH xác nhận, chờ điều chuyển, chờ đóng gói lại hoặc chờ đối soát trạng thái sàn. Mỗi loại ngoại lệ có người chịu trách nhiệm và SLA xử lý riêng. Mục tiêu không phải che giấu ngoại lệ mà là làm cho ngoại lệ nhìn thấy được trước khi quá hạn.

• Tạo trạng thái riêng cho đơn thiếu hàng, sai barcode, chờ CSKH và chờ điều chuyển.
• Không để đơn lỗi nằm chung với đơn thường trong wave picking.
• Đo SLA ngoại lệ theo người phụ trách, lý do lỗi và thời gian xử lý.

Báo cáo SLA nên đọc theo kênh, kho và nguyên nhân

Một báo cáo “95% đơn đúng hạn” chưa đủ để cải tiến. Quản lý cần biết 5% còn lại đến từ kênh nào, kho nào, nhóm SKU nào, ca làm nào và nguyên nhân nào. Có thể Shopee đúng hạn nhưng TikTok Shop Live trễ sau mỗi phiên live; có thể kho Hà Nội nhanh nhưng kho TP.HCM nghẽn ở packing; có thể SKU nhỏ xử lý tốt nhưng hàng cồng kềnh luôn chậm vì thiếu vật tư đóng gói.

Báo cáo tốt nên tách SLA theo từng mốc: thời gian đồng bộ đơn, thời gian giữ tồn, thời gian chờ picking, thời gian picking, thời gian checking, thời gian packing và thời gian chờ bàn giao. Khi nhìn theo mốc, doanh nghiệp biết nên sửa quy trình, tăng nhân sự, đổi vị trí SKU, bổ sung vật tư, chia lại ca làm hay điều chỉnh cut-off với hãng vận chuyển.

• Theo dõi tỷ lệ đơn đúng hạn theo Shopee, Lazada, TikTok Shop, livestream và social commerce.
• Tách báo cáo theo kho, ca làm, nhóm SKU, hãng vận chuyển và loại ngoại lệ.
• Dùng dữ liệu SLA để quyết định slotting, replenishment, staffing và quy tắc ưu tiê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ủ đề SLA xử lý đơn trong 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 thời gian xử lý đơn theo từng mốc vận hành: đơn vào hệ thống, giữ tồn, phân kho, picking, checking, packing, in vận đơn, bàn giao vận chuyển và xử lý ngoại lệ trước khi đơn bị trễ hạ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 SLA xử lý đơn trong 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ê cut-off của từng sàn, từng hãng vận chuyển và từng kho.
• Chuẩn hóa trạng thái đơn từ OMS đến WMS: mới, giữ tồn, phân kho, picking, checking, packing, bàn giao, ngoại lệ.
• Kiểm tra SKU, barcode, combo, bin location, khu fast-pick, khu bulk và khu staging.
• Chọn 10-20 đơn thật gồm đơn nhiều SKU, đơn combo, đơn livestream, đơn thiếu hàng, đơn hủy và đơn đổi hàng để chạy thử SLA.
• Định nghĩa chỉ số nghiệm thu: tỷ lệ đơn đúng hạn, thời gian từng bước, tỷ lệ ngoại lệ, lỗi picking/checking/packing và số đơn trễ cut-off.

JSTERP có thể hỗ trợ như thế nào?

JSTERP hỗ trợ thiết kế SLA xử lý đơn bằng cách nối OMS và WMS thành một luồng vận hành thống nhất. OMS gom đơn đa kênh, chuẩn hóa trạng thái, giữ tồn và ưu tiên đơn; WMS điều phối thao tác kho bằng barcode, PDA, vị trí, picking, checking, packing và bàn giao vận chuyển.

Đội triển khai JST ERP Việt Nam có thể khảo sát kênh bán, số đơn/ngày, số SKU, số kho, cut-off vận chuyển, nhóm lỗi hiện tại và năng lực nhân sự để đề xuất dashboard SLA phù hợp. Doanh nghiệp có thể bắt đầu từ các mốc đơn giản rồi mở rộng sang cảnh báo ngoại lệ, năng suất ca làm và tối ưu wave khi quy trình đã ổn định.

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.