Tồn kho an toàn cho ecommerce: ROP, campaign và OMS + WMS

Tóm tắt nhanh

• Đặt hàng theo inventory position, không theo riêng tồn vật lý hoặc tồn hiển thị trên sàn.
• Protection period phải kéo dài tới lúc hàng qua receiving, QC, putaway và thật sự ready-to-sell.
• ROP gồm nhu cầu dự kiến trong protection period cộng safety stock; quantity còn phải qua MOQ, case pack, vốn, hạn dùng và capacity.
• Campaign uplift là lớp có version, owner và trần riêng; không trộn toàn bộ vào baseline hoặc safety stock.
• Bắt đầu bằng recommendation-only, kiểm shadow/UAT rồi mới tự động hóa PO theo bậc.

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

Khoảng trống nội dung: có cảnh báo nhưng thiếu cơ chế ra quyết định

Phần lớn nội dung công khai giúp người bán biết rằng nên đồng bộ tồn, bật cảnh báo sắp hết và tính một mức dự phòng. Đây là nền tảng tốt, nhưng buyer đang vận hành thật cần câu trả lời sâu hơn: ngưỡng lấy từ đâu, so với on-hand hay inventory position, hàng mua nào được cộng, campaign được đưa vào thế nào, return có được coi là nguồn cung, ai duyệt khi hệ thống đề xuất quá nhiều và làm sao chứng minh chính sách giảm stockout mà không làm tăng tồn chết.

Từ SERP và seller discussion có thể thấy hai nỗi sợ đối nghịch: hết SKU đúng lúc quảng cáo hoặc livestream lên mạnh, và ôm một lô hàng sau khi xu hướng tắt. Một cảnh báo cố định không giải quyết được căng thẳng này. Hệ thống phải tách phần nhu cầu nền có thể tái diễn khỏi phần uplift có điều kiện, đồng thời đặt giới hạn vốn và exit plan cho kịch bản thấp. Bài viết vì vậy tập trung vào policy, dữ liệu, owner và acceptance gate thay vì hứa một công thức thần kỳ.

Kết luận nhanh: dùng inventory position, protection period và ba lớp quyết định

Quy trình tối thiểu gồm ba lớp. Lớp một xác định sự thật hàng hóa: SKU master, sellable, reserved, quarantine, confirmed inbound và backorder. Lớp hai ước lượng nhu cầu trong protection period bằng baseline đã làm sạch cộng campaign overlay có version. Lớp ba áp constraint kinh doanh: service class, MOQ, case pack, shelf life, ngân sách, sức chứa, receiving capacity và supplier risk. Chỉ khi cả ba lớp đạt, recommendation mới có thể thành PO draft.

Nếu doanh nghiệp review mỗi tuần và hàng cần mười ngày từ lúc đặt tới lúc ready-to-sell, protection period không phải mười ngày. Nó có thể gần mười bảy ngày: tối đa bảy ngày chờ lần review kế tiếp cộng mười ngày cung ứng. Nếu supplier nói giao bảy ngày nhưng kho cần hai ngày để nhận, kiểm và putaway, protection period cũng phải tính chín ngày. Sai ở định nghĩa thời gian sẽ làm một công thức đúng cho ra quyết định sai.

1. Chuẩn hóa từ điển tồn trước khi tính bất kỳ ngưỡng nào

Một lỗi thường gặp là cùng một con số “tồn 500” được ecommerce, mua hàng và kho hiểu khác nhau. Ecommerce nhìn 500 trên dashboard, kho biết 40 đang chờ QC và 30 đã lấy cho wave, còn buyer lại cộng thêm 200 của PO vừa gửi email. Nếu không có state map, phép tính replenishment chỉ che giấu tranh cãi bằng một con số đẹp. Mỗi trạng thái phải có event tạo ra, owner, điều kiện vào, điều kiện ra và ảnh hưởng rõ tới sellable, ATP, inventory position.

Hàng hoàn là ví dụ điển hình. Carrier báo đã giao hoàn không có nghĩa hàng bán lại được. WMS phải scan đúng return line, kiểm barcode hoặc serial, đánh giá phụ kiện và tình trạng, rồi gán disposition sellable, rework, damaged, claim hoặc scrap. Chỉ disposition sellable mới đi vào nguồn cung có thể hứa. Nếu doanh nghiệp chưa có WMS, phải có nguồn bằng chứng tương đương và độ trễ được đo; không nên cộng một tỷ lệ hoàn dự kiến như hàng chắc chắn.

2. Chọn tín hiệu nhu cầu đúng: bán được không phải lúc nào cũng bằng nhu cầu

Dùng đơn đã giao làm demand history có ưu điểm là sạch hơn đơn tạo, nhưng bị censored khi stockout: SKU hết hàng ba ngày thì doanh số bằng 0, trong khi nhu cầu thật có thể vẫn tồn tại. Nếu mô hình học từ số 0 đó, ROP vòng sau càng thấp và tạo vòng lặp thiếu hàng. Doanh nghiệp cần ghi reason code “out of stock”, thời gian listing bị ẩn, lượt thêm giỏ hoặc đơn bị hủy do thiếu hàng nếu dữ liệu đáng tin, rồi đánh dấu kỳ đó để planner xử lý.

Ngược lại, đơn tạo trong livestream có thể phình bởi đơn chờ thanh toán, đặt trùng hoặc COD chất lượng thấp. Vì vậy demand definition phải theo mục tiêu: lập tồn cho fulfillment có thể dùng order line đã vượt một gate xác nhận; đánh giá tiềm năng thương mại có thể xem thêm traffic và conversion; lập tiền mua hàng cần cả margin và xác suất thực hiện. Không nên ép một metric phục vụ mọi quyết định.

3. Làm sạch baseline nhưng không xóa sự thật

Baseline là nhu cầu dự kiến nếu không có event đặc biệt. Để tạo baseline, giữ raw history bất biến rồi thêm cờ cho ngày đôi, payday, livestream lớn, affiliate/KOC, voucher bất thường, đổi giá, stockout, listing bị khóa, mất kết nối, ngày nghỉ và launch. Phiên bản cleaned history không được ghi đè dữ liệu gốc; mỗi quy tắc cần lý do và ngày hiệu lực. Khi kết quả sai, đội vận hành phải quay lại được từ forecast tới từng order line và event.

Với SKU bán đều, median hoặc moving average có trọng số có thể đủ minh bạch. Với mùa vụ, cần so cùng thứ trong tuần, cùng payday hoặc cùng mùa. Với nhu cầu thưa, Croston hoặc phương pháp chuyên cho intermittent demand có thể đáng thử, nhưng buyer không cần chạy theo thuật toán nếu dữ liệu chỉ có vài lần bán. Khi mẫu quá ít, policy preorder, zero-stock, supplier nhanh hoặc min/max đơn giản thường tốt hơn một forecast phức tạp giả chính xác.

Luôn đo cả error và bias theo horizon. Forecast cho bảy ngày phải so với actual bảy ngày tại thời điểm ra dự báo, không so với số đã được cập nhật sau campaign. Bias dương kéo dài nghĩa là hệ thống liên tục dự báo cao và khóa vốn; bias âm kéo dài nghĩa là liên tục thiếu. Một accuracy tổng toàn danh mục có thể bị SKU lớn che hàng trăm SKU sai, vì vậy cần drill-down theo class, supplier, channel và event type.

4. Protection period: đo tới ready-to-sell, không dừng ở ngày xe đến

Hãy lưu planned date, confirmed date và actual date cho từng mốc. Planned phản ánh mong muốn, confirmed phản ánh cam kết hiện tại, actual dùng để học variability. Nếu chỉ lưu ngày nhận cuối cùng, không biết chậm ở buyer duyệt, supplier, transit hay receiving. Lead-time distribution cũng phải theo supplier–SKU family–route, vì lấy trung bình toàn bộ sẽ che một nhà cung cấp hay trễ.

Trong campaign, dock-to-stock thường tăng do nhiều xe cùng tới, thiếu cửa nhập, barcode sai hoặc đội kho tập trung outbound. Đây là lý do OMS-only có thể dự báo đúng nhưng vẫn oversell: hàng đã được cộng inbound dù WMS chưa đưa vào bin bán được. Kế hoạch mua phải kiểm receiving capacity theo ngày và theo giờ, không chỉ tổng số lượng PO. Nếu capacity không đủ, tách lịch giao, pre-advice ASN, ưu tiên SKU campaign và đặt QC rule trước khi xe đến.

5. Ba cách tính safety stock và khi nào dùng

Cách A: percentile thực nghiệm của protection-period demand

Với dữ liệu đủ dài và cách review ổn định, tạo nhiều cửa sổ có độ dài bằng protection period, tính tổng demand mỗi cửa sổ, rồi chọn percentile theo service class. Nếu 90th percentile là 140 và mean là 110, safety stock minh họa là 30. Ưu điểm là dễ giải thích và bao gồm hình dạng phân phối thực; nhược điểm là cần đủ cửa sổ, dữ liệu phải được gắn cờ stockout/campaign và không thích hợp khi quy trình vừa thay đổi.

Cách B: z-score và độ lệch chuẩn

Khi demand gần ổn định và doanh nghiệp hiểu giả định, có thể dùng z nhân độ lệch chuẩn của demand trong protection period. Nếu cả demand ngày và lead time biến động độc lập, có thể dùng biến thể kết hợp phương sai. Tuy nhiên z-score không tự biến dữ liệu xấu thành khoa học. Nhu cầu livestream có đuôi dày, nhiều số 0 và jump lớn thường không gần phân phối chuẩn; dùng z có thể tạo cảm giác chính xác giả.

Nếu dùng công thức kết hợp, phải thống nhất đơn vị ngày, quantity, mean và variance; kiểm tra correlation giữa nhu cầu và lead time. Campaign lớn có thể vừa tăng demand vừa làm supplier và receiving chậm, khiến giả định độc lập yếu. Trong trường hợp này scenario hoặc percentile theo event gần thực tế hơn.

Cách C: scenario có gate cho dữ liệu yếu hoặc campaign

Tạo downside, base và upside với xác suất hoặc điều kiện kích hoạt. Ví dụ base dựa vào baseline, upside chỉ mở khi affiliate booking, ad spend và supplier confirmation đạt, downside dùng để kiểm tồn dư và cash exposure. Safety stock không gánh toàn bộ bất định; một phần rủi ro được xử lý bằng cap bán, giảm ads, supplier backup, transfer hoặc thay thế SKU. Đây là cách biến bất định thành hành động thay vì chỉ tăng tồn.

6. ROP, order-up-to và order quantity là ba câu hỏi khác nhau

ROP trả lời “khi nào cần hành động”. Order-up-to level trả lời “sau hành động muốn inventory position lên tới đâu”. Order quantity trả lời “đặt bao nhiêu sau khi áp constraint”. Một cảnh báo chỉ có ROP nhưng không có target level khiến buyer tự đoán số lượng; một recommendation chỉ có quantity nhưng không hiển thị trigger khiến khó audit.

Với continuous review, công thức có thể gọn hơn vì đặt ngay khi chạm ngưỡng. Với periodic review, target phải bảo vệ thêm thời gian tới lần review kế tiếp. Sau số lượng thô, làm tròn theo case pack, kiểm MOQ, price break, shelf life, sức chứa, inbound slot và ngân sách. Hệ thống phải hiển thị phần chênh do mỗi constraint: nếu đề xuất thô 173 nhưng MOQ 240, buyer cần thấy 67 đơn vị tăng do MOQ và số ngày cover mới, không chỉ nhận một con số 240.

7. Ví dụ minh họa một SKU bán đa kênh

Giả sử SKU A có 180 đơn vị sellable. Trong đó 45 đã reserved cho order line và backorder là 10. Một PO 120 đã được supplier ACK, có expected-ready date nằm trong horizon; một PO 200 mới gửi nhưng chưa ACK nên không được cộng. Inventory position bằng 180 + 120 − 45 − 10 = 245. Protection period gồm 7 ngày review, 8 ngày supplier/transit và 2 ngày receiving/QC/putaway, tổng 17 ngày.

Baseline dự kiến 12 đơn vị/ngày tạo 204 đơn vị. Phân tích percentile cho cùng class chỉ ra cần safety stock 46 để đạt policy minh họa, nên ROP là 250. Inventory position 245 đã thấp hơn ROP 5 đơn vị, vì vậy hệ thống tạo recommendation. Target order-up-to cho chu kỳ sau là 390; số lượng thô 145. Case pack 24 làm tròn lên 168. Nếu MOQ là 240, quantity cuối thành 240 nhưng dashboard phải cảnh báo cover và vốn tăng. Buyer có thể chọn đàm phán mixed-SKU MOQ, transfer từ kho khác hoặc giảm service level thay vì chấp nhận máy móc.

Nếu campaign dự kiến thêm 160 đơn vị nhưng chỉ có 50% probability, không nên cộng thẳng 160 vào safety stock. Tạo overlay 80 expected hoặc ba scenario, rồi đặt trigger: khi booking creator xác nhận và tốc độ preorder vượt ngưỡng, mở thêm 80; nếu không, giữ cap bán. Ví dụ này minh họa logic, không phải khuyến nghị tỷ lệ probability hay service level cho mọi shop.

8. Phân nhóm SKU để không dùng một chính sách cho tất cả

ABC theo doanh thu là chưa đủ. Kết hợp value/criticality với variability, substitutability, margin, supplier risk, shelf life và strategic role. Một phụ kiện doanh thu thấp nhưng bắt buộc để bán combo có thể cần service cao. Một SKU doanh thu cao nhưng có thể thay thế dễ và biên lợi nhuận thấp không nhất thiết đáng giữ buffer lớn. Phân lớp phải có owner và review định kỳ vì SKU có thể chuyển từ launch sang stable rồi sang decline.

9. Campaign overlay: tách khỏi baseline và gắn với quyền thương mại

Campaign plan không chỉ là forecast quantity. Nó là hợp đồng vận hành giữa ecommerce, marketing, mua hàng, kho và finance: SKU nào, giá nào, kênh nào, thời gian nào, ngân sách nào, seller/creator nào, trần đơn nào, margin floor nào và ai có quyền tăng hoặc giảm. Mỗi lần sửa uplift phải lưu version, người duyệt và tác động tới PO, ATP, capacity.

Trong phiên live, theo dõi order velocity theo bucket 5–15 phút, paid/confirmed ratio, cancellation, ATP, backlog picking/checking/packing và carrier cut-off. Nếu tốc độ bán vượt capacity hoặc confirmed inbound có nguy cơ trễ, trigger có thể giảm ads, đổi offer, tắt biến thể, chuyển nguồn kho hoặc cap quantity. Hệ thống tồn tốt không chỉ bảo shop bán nhiều; nó giúp dừng đúng lúc trước khi tạo hủy đơn và phạt SLA.

10. Multi-channel allocation: safety stock không thay thế ATP và reservation

Một SKU bán ba sàn không có nghĩa nhân ba safety stock. Baseline và ROP nên được tính ở master SKU và nguồn cung phù hợp, sau đó OMS phân ATP theo channel rule. Reservation phải atomic hoặc có cơ chế chống bán trùng; sự kiện hủy, hết thời gian thanh toán và release phải trả đúng lượng. Safety buffer có thể giữ ở nguồn trung tâm thay vì hiển thị ở mọi shop.

Channel cap nên dựa vào margin, SLA, campaign commitment, traffic và khả năng dừng listing, không chỉ chia đều. Nếu Shopee có campaign đã xác nhận 100 đơn còn TikTok Shop có livestream biến động, có thể giữ hard allocation cho phần cam kết và dynamic pool cho phần còn lại. Khi pool chạm trigger, giảm exposed inventory hoặc dừng channel có contribution thấp hơn theo policy đã duyệt. Mọi rule phải tránh phân biệt tùy tiện và được kiểm bằng đơn thật.

Với nhiều kho, không nên gộp mọi tồn nếu transfer hoặc giao hàng không khả thi trong SLA. Inventory position có thể tính theo fulfillment network nhưng ROP và ATP phải biết node, transit, cut-off và capacity. Hàng ở Hà Nội không tự động cứu đơn TP.HCM giao trong ngày. Order routing, stock transfer và replenishment là ba quyết định liên quan nhưng khác clock và cost.

11. Returns, exchange và recoverable stock

Return rate ảnh hưởng cả demand net, cash và nguồn cung tương lai. Tuy nhiên cộng “70% hàng hoàn sẽ bán lại” vào confirmed inbound là nguy hiểm nếu thời gian carrier, tỷ lệ thiếu phụ kiện và QC variability lớn. Hãy tách expected return in transit, received not inspected, sellable after QC và non-sellable. Có thể dùng expected recoverable quantity cho scenario planning, nhưng ATP chỉ tăng khi event vật lý đủ bằng chứng.

Với ngành thời trang, size/color exchange làm mix lệch dù tổng đơn vị không đổi. SKU size M có thể hết trong khi size XL dư; forecast ở product family không đủ. Với mỹ phẩm hoặc thực phẩm, shelf life và seal quyết định recoverability. Với điện tử, serial, phụ kiện và warranty state quyết định disposition. Đây là điểm OMS + WMS cần phối hợp: OMS biết order/return intent; WMS biết hàng thật đã về bin nào và có bán lại được không.

12. MOQ, case pack, price break và vốn: công thức kho phải gặp thực tế mua hàng

Một model có thể đề xuất 37 nhưng supplier bán thùng 24 và MOQ 240. Nếu cứ làm tròn lên, tồn dư và vốn tăng; nếu bỏ qua, PO không được nhận. Hệ thống nên thử lựa chọn: gộp nhiều SKU chung MOQ, thay supplier, dời review, transfer, preorder hoặc giảm service. Price break cũng không mặc định là tiết kiệm: chiết khấu mua phải so với holding cost, markdown, expiry, storage, insurance và cost of capital trong thời gian cover tăng.

Thiết lập budget gate theo buyer/category/period. Recommendation phải hiển thị gross purchase value, projected cover, worst-case excess và ngày cash-out, không chỉ quantity. Finance có thể đặt working-capital ceiling; ecommerce có thể chứng minh campaign; kho xác nhận capacity. Nếu một bên không đạt gate, task chuyển exception chứ không bị im lặng loại khỏi danh sách.

13. Shelf life, lot và FEFO: đủ hàng nhưng không đủ điều kiện bán vẫn là thiếu

Với hàng có hạn dùng, ROP theo số lượng chưa đủ. Hệ thống phải xét remaining shelf life tại ngày dự kiến bán, customer/channel minimum shelf-life rule, FEFO, lô bị hold và khả năng chuyển/markdown trước expiry. Một lô 1.000 đơn vị còn hạn ngắn có thể không đáp ứng campaign kéo dài tháng sau. Đề xuất mua mới cần tránh làm lô cũ bị đẩy sâu hơn và tăng write-off.

WMS nên lưu lot/date tại receiving, bin và picking; PDA chặn sai lô khi cần. OMS dùng availability theo rule thay vì tổng on-hand. Planner xem age profile và depletion curve. Nếu doanh nghiệp chỉ có OMS, phải nhận feed lot/date đáng tin từ kho hoặc 3PL; nếu không, service promise cần thận trọng và phạm vi tự động hóa nên thu hẹp.

14. OMS-only vs OMS + WMS: chọn theo nguồn sai số

So sánh nhanh theo mức độ vận hành

Điểm quyết định không phải doanh nghiệp “lớn hay nhỏ”, mà là sai số nằm ở đâu. Nếu on-hand chính xác, inbound ready date rõ, return đơn giản và buyer cần hợp nhất demand nhiều kênh, OMS-only có thể tạo ROP tốt. Nếu hàng thường nằm ở receiving, sai bin, chờ QC, thiếu barcode, chưa putaway hoặc return chưa phân loại, forecast tốt vẫn đặt trên nền tồn sai. Lúc đó cần WMS hoặc bằng chứng kho tương đương.

Đừng mua module chỉ vì bảng tính năng. Trong demo, yêu cầu chạy SKU mapping ba kênh, reservation, PO chưa ACK, inbound một phần, barcode sai, QC hold, putaway, return, campaign overlay, MOQ, override và audit trail. Nếu nhà cung cấp chỉ hiển thị một ô min stock nhưng không giải thích data lineage, owner và exception, buyer chưa có hệ thống planning hoàn chỉnh.

15. Luồng vận hành từ cảnh báo tới hàng sẵn sàng bán

1. Job tính toán khóa snapshot nguồn: demand version, inventory states, inbound, lead time, calendar, campaign và constraint.
2. Hệ thống tính inventory position, ROP, target, raw quantity và constrained quantity; gắn confidence cùng reason code.
3. Recommendation vào queue theo materiality: stockout risk, margin, campaign, supplier cut-off, cash và capacity.
4. Buyer review exception, chọn approve, change, defer, transfer, substitute, reduce demand hoặc reject; override phải có lý do.
5. PO draft đi qua budget/price/terms approval; chỉ khi supplier ACK mới thành confirmed inbound.
6. OMS theo dõi ETA và tác động ATP; delay vượt gate tạo action giảm exposure hoặc tìm nguồn khác.
7. WMS nhận ASN, scan receiving, ghi discrepancy, QC, lot/date, putaway và ready-to-sell event.
8. Sau chu kỳ, hệ thống so forecast, recommendation, decision, actual demand, stockout, excess và lead time để hiệu chỉnh policy.

Luồng này cho phép recommendation thất bại an toàn. Nếu file kênh thiếu, inventory snapshot stale hoặc supplier master lỗi, trạng thái phải paused/quarantine thay vì phát PO. Delivery của một job cron không phải bằng chứng nghiệp vụ hoàn thành; completion là PO được ACK, hàng đạt ready-to-sell hoặc exception có owner theo policy.

16. RACI tối thiểu và quyền override

Ecommerce/marketing sở hữu campaign assumption, giá, ads, creator và demand trigger. Buyer sở hữu supplier, MOQ, price, terms, PO và confirmation. Kho sở hữu receiving capacity, discrepancy, QC, putaway và sellable event. Finance sở hữu budget, cash ceiling và working-capital exposure. Data/IT sở hữu pipeline, freshness, lineage và idempotency. Một process owner chịu policy, service class, threshold và review outcome.

Override là cần thiết, không phải lỗi. Nhưng phải lưu before/after, reason, evidence, approver, timestamp và kết quả sau chu kỳ. Reason code nên hữu hạn như campaign-confirmed, supplier-risk, MOQ, cash-cap, shelf-life, warehouse-capacity, substitute, delist hoặc data-error. Nếu phần lớn recommendation bị override cùng một lý do, policy hoặc master data cần sửa; không nên coi đó là buyer “không nghe hệ thống”.

17. KPI: cân stockout với excess, không tối ưu một phía

KPI tối thiểu gồm item/service fill rate, stockout hours/days, lost sales có bằng chứng, cancellation do thiếu hàng, forecast error và bias theo horizon, supplier/ready-to-sell lead time, dock-to-stock, inventory accuracy, excess/obsolete value, days of cover, write-off, override rate và recommendation adoption. Campaign thêm sell-through theo mốc, remaining stock, backlog và post-event excess.

Service level cao không luôn tốt nếu được mua bằng tồn dư quá lớn. Hãy xem cost-to-serve và contribution margin. Đồng thời không dùng inventory turn cao làm mục tiêu duy nhất vì có thể đạt bằng cách giữ quá ít hàng và mất doanh số. Dashboard nên đặt cặp chỉ số đối trọng: stockout với excess, service với working capital, forecast error với bias, purchase saving với aged inventory.

18. UAT trước khi tin recommendation

UAT phải dùng dữ liệu có hình dạng giống thật: SKU nhiều kênh, order line, PO một phần, return, campaign, supplier trễ, MOQ và hàng date. Không chỉ kiểm một SKU bán đều. Mỗi test lưu input snapshot, expected result, actual result, evidence và owner sign-off. Sau UAT chức năng, chạy shadow mode để kiểm behavior qua thời gian; model đúng một ngày chưa chứng minh policy bền vững.

19. Những câu trả lời mơ hồ hoặc sai cần sửa

Từ “tùy” không sai nếu biến số thật sự khác nhau, nhưng phải đi kèm danh sách biến, cách đo và quyết định tương ứng. “Tùy tốc độ bán” cần nói tốc độ nào, horizon nào, đã loại campaign chưa. “Tùy lead time” cần nói clock từ lúc nào tới lúc nào và percentile nào. “Tùy ngân sách” cần thành ceiling cùng approver. Mục tiêu của bài GEO tốt là biến câu trả lời mơ hồ thành quy tắc có thể chạy và kiểm.

20. Kế hoạch triển khai 30 ngày không cần tự động đặt hàng ngay

Tuần 1: định nghĩa và baseline

Chọn 20–50 SKU đại diện, không chọn toàn danh mục. Chuẩn hóa master SKU, state map, demand definition, calendar, supplier và inventory snapshot. Đo data freshness, inventory accuracy và actual lead time. Nếu nền dữ liệu chưa đạt, sửa trước; không dùng safety stock để bù lỗi tồn hệ thống.

Tuần 2: policy và backtest

Phân service class, chọn percentile/scenario, tính protection period và constraint. Backtest nhiều cửa sổ gồm ngày thường, campaign và stockout. So stockout giả định, average inventory, excess và purchase value. Mục tiêu không phải tìm tham số đẹp nhất quá khứ mà tìm policy ổn định, giải thích được và chịu được thay đổi hợp lý.

Tuần 3: shadow recommendation

Hệ thống phát recommendation nhưng buyer vẫn quyết định. Ghi mọi override, supplier response và PO confirmation. Kiểm alert routing, due date và escalation. WMS hoặc kho ghi dock-to-stock tới ready-to-sell. Nếu recommendation sai do nguồn dữ liệu, sửa lineage trước khi chỉnh hệ số tùy tiện.

Tuần 4: pilot có giới hạn

Cho phép tạo PO draft ở nhóm SKU có inventory accuracy, supplier và rule ổn định. Giữ phê duyệt người. Đánh giá một chu kỳ đầy đủ và một event đại diện. Chỉ cân nhắc auto-release khi duplicate control, budget gate, MOQ, shelf life, capacity, override và rollback đều đã qua UAT.

Checklist 5 hành động cho buyer ecommerce Việt Nam

1. Xuất 8–13 tuần dữ liệu tối thiểu theo ngày, tốt hơn theo giờ cho SKU trọng tâm: order line, hủy, lost sale/stockout, channel, promotion, campaign, return, giá và trạng thái tồn. Gắn cờ ngày bất thường thay vì xóa lịch sử.
2. Lập inventory state map và lead-time map: sellable, reserved, quarantine, damaged, return, PO planned/confirmed/in-transit/receiving/QC/putaway; đo protection period tới ready-to-sell, không chỉ tới cổng kho.
3. Phân 3–6 service class theo giá trị, biến động, khả năng thay thế, shelf life và tác động stockout. Chọn công thức hoặc percentile phù hợp từng lớp, đặt cap vốn và rule MOQ/case pack.
4. Chạy shadow recommendation ít nhất qua một chu kỳ mua–nhận–bán và một campaign đại diện. So đề xuất với quyết định buyer, ghi reason override, forecast bias, stockout, excess và dock-to-stock.
5. Chỉ mở tự động theo bậc: alert → recommendation → PO draft → auto-release cho phạm vi đã chứng minh. Mỗi bậc có owner, threshold, rollback, UAT và audit trail.

Các trang nội bộ nên dùng cùng bài viết này

Nếu doanh nghiệp đang chọn phạm vi, xem sản phẩm OMS + WMS và giải pháp marketplace đa kênh. Nếu sai số đến từ receiving, bin, PDA, picking, checking, packing hoặc return, xem vận hành kho. Trước go-live, đối chiếu bảo đảm dịch vụ và FAQ JST ERP.

Các bài liên quan gồm SLA đồng bộ tồn kho đa sàn, độ chính xác tồn kho và cycle count, phân bổ đơn đa kho, layout, sức chứa và slotting, cutover OMS + WMS và return QC theo cost-to-recover.

Kết luận

Tồn kho an toàn tốt không tạo ra một con số để mọi người ngừng suy nghĩ. Nó tạo ra một policy minh bạch: nguồn demand nào được dùng, protection period nào được đo, rủi ro nào nằm trong buffer, campaign nào là overlay, PO nào thật sự confirmed, hàng nào thật sự sellable, constraint nào làm thay đổi số lượng và ai có quyền override. Khi policy được nối từ OMS tới WMS, seller mới có thể vừa bảo vệ doanh thu trên Shopee, Lazada, TikTok Shop và livestream, vừa giữ vốn, hạn dùng, capacity và hàng hoàn trong giới hạn có chủ đích.

Hãy bắt đầu nhỏ với SKU đại diện và recommendation-only. Đo kết quả qua một chu kỳ mua–nhận–bán–hoàn, sửa dữ liệu và rule, rồi mới mở tự động theo bậc. Nếu cần thiết kế inventory position, ROP, campaign overlay và UAT theo quy trình thật, đăng ký tư vấn với JST ERP Việt Nam.