Tối Ưu Hóa Kho Hàng & Vận Tải Bán Lẻ
Cẩm nang vận hành chuỗi cung ứng FMCG: Phân loại SKU đa chiều, kiểm soát Inbound, Multi-Echelon Replenishment, chuyển đổi Cross-Docking và định tuyến VRPTW.
Quang Toàn Lê Nguyễn:
Em chào anh chị chuyên gia và anh chị em trên diễn đàn.
Em hiện đang đang làm việc tại công ty retail ngành FMCG, với vai trò là tối ưu kho và tuyến vận tải từ kho DC đến các cửa hàng.
Em có 2 chủ đề rất mong muốn được anh chị cho lời khuyên và kinh nghiệm về kho và vận tải ạ.
1. Chủ đề về kho - Quản lý tồn kho:
- Mục tiêu:
- Quản lý tồn kho một cách tốt nhất với ít sai sót trong quản lý tồn
- Làm cho luồng hàng trong kho được lưu thông từ nhập - lưu trữ - xuất một cách nhanh chóng nhất
- Clear các sản phẩm có số ngày tồn kho cao và những sản phẩm đang chiếm thể tích ở kho không tạo ra giá trị
- Bối cảnh:
- Hiện tại, công ty đã phân ra được những SKU thuộc 3 label: A, B, C
- Đối với label C: có thể giải quyết bằng việc công ty thanh lý những sản phẩm đã lâu không bán được nếu vượt quá tồn min cho phép ở kho. Hiểu rằng những SKU thuộc label C phải có mức tồn nhất định (tồn min) để cho các cửa hàng có hàng để trưng bày
- Đối với 2 label A,B: khi clean data em lại phân ra được thêm trong những SKU A,B này lại có những sản phẩm lại có ngày tồn kho cao và chiếm thể tích khá lớn ở kho.
- Xử lý:
đối với SKU A, B em đã lọc ra những SKU có số ngày tồn kho vượt số ngày tồn kho trung bình của label để giảm số lượng các SKU này tại kho => nhằm saving thể tích cho các SKU bán chạy khác nhập về.
- Câu hỏi:
- Vậy mình có thể quản lý đầu vào hay facing trong kho như thế nào để tránh việc phải xử lý vấn đề liên quan tới những SKU label A,B tồn lâu tại kho?
- Ngoài ra, còn những SKU bán chạy tại cửa hàng nhưng tồn kho đang bằng 0. Hiểu là ở cửa hàng thì tồn đang hết dần, kho thì chưa nhập hàng về. Vậy khi kho nhập về thì số lượng bao nhiêu là đủ để có thể đáp ứng được demand của tất cả các cửa hàng vừa cân bằng được tồn kho hiện tại của kho?
2. Chủ đề về vận tải - Thuật toán AI phân tuyến:
- Mục tiêu:
- Tối ưu và giảm chi phí vận tải từ kho DC đến các cửa hàng
- Tìm ra phân tuyến phù hợp với từng kho DC, từng địa hình vùng miền và phân bổ cửa hàng của từng kho DC
- Bối cảnh:
- Hiện tại công ty em đã có AI chạy phân tuyến hằng ngày các tuyến giao hàng từ kho DC đến các cửa hàng
- Tuy nhiên, em luôn tìm cách để tối ưu chi phí vận chuyển
- Xử lý:
hiện tại, em đang theo dõi tình hình phân tuyến hằng ngày của thuật toán theo kho DC, vùng miền và sắp tới sẽ là hình dạng phân tuyến cửa hàng của kho DC.
- Câu hỏi:
- Ngoài các KPIs như: chi phí, số điểm giao, tỉ lệ đầy xe thì em còn nên follow những KPIs nào nữa để tối ưu được tuyến không ạ?
- Nếu muốn build 1 thuật toán phân tuyến theo địa hình vùng miền và số lượng, vị trí cửa hàng phân bổ cho kho DC thì nên nhìn từ gốc độ như thế nào và chú ý những điều gì ạ?
Quang Toàn Lê Nguyễn (Update 13.08.2026):
Em chào anh chị em trên diễn đàn.
Trong thời gian qua do vướng bận với công việc nên chưa update được thêm thông tin cho topic này.
Nay em cung cấp thêm thông tin về topic "Quản lý tồn kho" bên dưới. Topic "Thuật toán phân tuyến" em sẽ tạm pending lại do dự án của công ty đang focus vào phần tồn kho hơn.
1. Mô tả chung về kho, SKU và vai trò của team em:
- Loại kho:
- Kho mà dự án em đang theo là kho khô chứa hàng FMCG
- Có nhiều hình dạng kho như: chữ I, chữ L và chữ U. Có kho lớn và kho nhỏ với thể tích từ 1500-5000 m3
- Khu vực inbound sẽ không có kệ thay vào đó khi nhập hàng sẽ để pallet dưới đất
- Khu vực trữ hàng có 6-8 dãy kệ, 1 dãy cao 4-5 tầng, 12 khung, 1 khung chứa được 3 pallet (1 dãy chứa được 144-180 pallet) (vì mỗi kho có thể tích và số lượng kệ khác nhau nên em lấy số lượng trung bình mà em theo dõi được). Phân thành 2 khu trữ chính: hàng non-food và hàng food
- Khu vực xuất hàng có 3 dãy kệ 6 khung với sức chứa như trên
- Một kho trung bình phục vụ 100 cửa hàng
- Số lượng SKU:
- Trung bình 1 DC hiện tại có 5,000 SKU, phân thành 18 ngành hàng (17 ngành hàng kinh doanh và 1 ngành hàng không kinh doanh)
- Phân label ABC, hiện nay công ty đang có 3 tool để phân loại: theo doanh thu mang lại (trong khoảng thời gian tự chọn), theo số lượng đã bán (trong khoảng thời gian tự chọn) và theo Forecast sức bán. Đối với cả 3 tool này đều có 1 rule chung là sắp xếp thứ tự theo yêu tố đã chọn từ cao tới thấp và lấy 20% SKU đứng đầu thuộc loại A, 50% SKU tiếp theo là B và cuối cùng là C.
- Hiện tại đang có rất nhiều suppliers giao với lịch trình khác nhau, nhưng sẽ phải theo lịch nhận và tải nhận của kho => Em sẽ lấy trung bình là mỗi lần đặt hàng thì suppliers sẽ giao đến kho trong vòng 3 ngày
- Vai trò của em và team:
- Như em đã có nhắc đến trước đó em và team thuộc về tối ưu vận hành kho và vận tải, chỉ take care về những gì thuộc về kho và làm sao để kho có luồng hàng được lưu thông tốt nhất (tìm được long mạch)
- Những việc liên quan đến forecast, sales hay procurement sẽ có team khác take care
2. Mục tiêu:
- Giảm cho kho về tải nhập và tải xuất
- Tồn trong kho không chứa quá nhiều SKU dư thừa. Hiểu là SKU nào tồn trong kho sẽ tạo ra được giá trị, SKU nào không tạo ra giá trị thì cần được xử lý sớm
- Chuyển đổi sang mô hình kho cross-docking
3. Xử lý:
- Giảm tải nhập và xuất cho kho: em đang tổng hợp SKU đang có lượng nhập và xuất bất thường. VD: SKU có nhập 1 lần với khối lượng 20 tấn và xuất luôn 20 tấn trong 1 ngày => Bất thường. Hay những SKU trong vòng 1-2 tuần không xuất được gì nhưng vẫn có đợt nhập hàng và số lượng của SKU vượt hơn tồn tối thiểu để gửi cảnh báo cho procurement điều chỉnh lại số lượng nhập xuất.
- Xử lý SKU đang dư thừa tại kho: em đã tổng hợp những SKU có số lượng tồn kho thực tế > số lượng tồn kho max dành cho SKU này và SKU đã ngừng kinh doanh để gửi bên procurement xử lý
- Đối với chuyển sang kho cross-docking: công ty đã và đang có dự án chia cross-dock cho 1 số SKU bán chạy trong kho và đang dần mở rộng danh sách SKU
4. Câu hỏi:
- Em muốn giảm tải nhập và tải xuất cho kho bằng cách show cho bên procurement thấy kho chỉ nên nhận SKU nào với số lượng như thế nào để họ có thể cân nhắc và trao đổi lại với NCC. Vậy thì em nên show ra những gì để có thể thuyết phục họ làm theo, vì hiện tại sức bán của siêu thị team em không nắm, chỉ có lượng nhập và lượng xuất tại kho?
- Mặt khác ở phía kho em cũng muốn chủ động để tăng năng suất cho kho, nhưng hiện tại chỉ đang về mặt vật lí: đầu tư xe nâng, xe nâng tay điện, nhân sự,... Vậy thì mặt strategy nên cần bổ sung hay thay đổi gì không ạ?
- Lý do em hỏi 2 câu trên cũng liên quan tới mục tiêu cuối cùng là chuyển đổi kho sang mô hình cross-docking, vì đối với em mô hình này cần phải forecast rất chính xác nếu không sẽ dễ phát sinh bottleneck.
VD: tính sai nhu cầu của cửa hàng => nhập về dư => gác lên kệ. Tầm 2-3 SKU thì có thể xử lý được nhưng nếu hàng chục sẽ làm quá tải kho. NCC nhập hàng tới đem ra line xuất, nhưng lại thừa hàng => phải gác lên kệ => riêng 1 lần cho 1 SKU này đã phải tốn 1 xe nâng rồi => thiếu xe nâng để nhập hàng NCC khác.
=> Vậy thì khi làm mô hình cross-docking này thì em cần lưu ý hay có những strategy như thế nào về forecast, layout kho hay những thứ gì khác không ạ?
PHẢN HỒI TỪ CÁC THÀNH VIÊN
Minh Ngọc - ERX Vietnam:
Anh chia sẻ câu 2 trước nhé, vì anh cũng có vài kinh nghiệm build system tối ưu phân tuyến (python).
- KPIs cần bổ sung: không rõ em đã có tỷ lệ quay vòng đầu xe chưa, nếu chưa thì nó sẽ là một KPIs trong tối ưu chi phí. Cần lưu tâm đến constraint về time-windows nếu chưa có. Trong phần chi phí nó nhiều yếu tố: loại xe (tải, xe máy, xe van...), tải trọng (đường cấm tải), tránh thu phí, số lượng xe, số lượng depot...
- Build thuật toán thì cần quan tâm nhiều thứ, ví dụ:
- ngôn ngữ lập trình
- thuật toán (Dijkstra, A-start, heuristic....) - này cần có kiến thức OR
- bản đồ dùng của đơn vị nào (hay vướng vụ "lưỡi bò" nếu dùng bản đồ ko chính thống), còn dùng chính thống thì quan tâm phí API (distance matrix API của Google)...còn nhiều nhà cung cấp API bản đồ nữa (Việt Nam, nước ngoài...)
- giới hạn về server - số lượng điểm tối đa có thể routing
- mô hình vận tải
- tự code hay vibe code :D
Vài điều chia sẻ với em.
Thao Santa8:
Hi em,
Mình nên data-driven một chút. Tùy vào scale mà cách approach sẽ khác nhau.
Em giới thiệu thêm về quy mô DC, số cửa hàng, số lượng SKU, tồn kho bao nhiêu tuần, tần suất đặt hàng,...
Có chút thông tin này thì trao đổi tiếp nó mới cụ thể và gần với tình huống của em.
Thuận Phạm Vũ Ngọc:
Đầu tiên có một câu hỏi mình cần hỏi lại: Kho của bạn là kho gì? Cold Warehouse hay thường? Có rack trữ hàng cao được layout tốt không?
Về Phần 1 câu hỏi 1:
Input của bạn: "SKU A,B này lại có những sản phẩm lại có ngày tồn kho cao". Không nói rõ A, B, C được phân ra theo các criteria nào? Có phải như SGK A, B, C analysis nơi A là giá trị cao, số lượng ít, C là giá trị thấp nhưng số lượng nhiều không?
=> Xem lại cách chia criteria cho A, B, C. Có thể cần chia nhỏ hơn không? Cần cross-working với bên mua hàng để xem lại turnover của các mã hàng này để đưa ra chiến lược lưu trữ hợp lý (đưa lên cao, ở sâu trong kho)
=> Và lý do chính cần cross-working với bên mua hàng để tránh trường hợp họ vì giá tốt mà đặt MOQ không hợp lý
Về Phần 1 câu hỏi 2:
=> Từ khóa cho bạn tìm kiếm "Multi-Echelon Inventory Management" (không rõ thì hỏi tiếp tại diễn đàn này :v)
Về Phần 2 câu hỏi 1:
=> Câu trả lời của anh Ngoc
Về Phần 2 câu hỏi 2:
Những điều cần quan tâm (rất nặng về input của Operation Research hay còn gọi là Decision Science):
Ngôn ngữ lập trình? (Python, C++)
Commercial (Pyomo, Gurobi, CPlex,...) hay Open Source Solver (OR Tools, PulP,...)
Chọn Solver sẽ liên quan đến việc chọn structural class của bài toán (vì đây là bài toán tổ hợp, thêm 1 node với nhiều ràng buộc sẽ làm bùng nổ tổ hợp khiến thời gian giải tăng nhiều ngàn lần), tạm gợi ý 2 class: MILP và CP. MILP sẽ dùng cho scale nhỏ tới trung để tìm nghiệm chất lượng cao, tuy nhiên độ khó formulate bài toán cũng cao để giải ra. CP thì formulate dễ hơn và dùng cho scale lớn hơn, lời giải được tìm ra với tốc độ nhanh và chất lượng khá tới tốt. MILP thì gợi ý dùng Gurobi (nhưng mà cỏ lúa phải có, vì đây là đồ chơi cho nhà giàu) hoặc CPlex. CP thì gợi ý Google OR-Tools, tuy nhiên đây là 1 incomplete solver, yêu cầu phải hiểu bản chất của toán học để validate chất lượng kết quả tốt (một cách validate hơi lòng vòng xíu).
Chất lượng bài toán công nghiệp yêu cầu phải phân rã bài toán và ràng buộc chặt hơn. Giải 4000 nodes với ràng buộc: khung thời gian phải giao (time window), giới hạn túi (capacity), giao và nhận (pick-drop),... là một thử thách lớn dù là solver xịn như OR-Tools. Kỹ thuật cần sử dụng:
- Spatial Partioning: chia 4000 nodes ra thành các cohort nhỏ rồi giải trên các cohort, gộp lại tiếp (giảm chất lượng nghiệm toàn cục) bằng các kỹ thuật xử lý giáp ranh giữa các cohort
- Domain Reduction: Các gói hàng có tải nặng hơn max capacity của 1 xe thì cắt arc đó không cần cho solver giải. Các đơn hàng có cùng timewindow có thể cân nhắc gộp lại (tăng tổng capacity lên, cái này nguy hiểm, cần xem điều kiện business thực tế)
- Các ràng buộc liên quan đến branch cutting
- Symmtry Breaking: Các xe có cùng Capacity, có cùng 1 type node được phân khúc thì set 1 constraint dạng xe X1<X2<X3 cho các node đó => Solver không cần hoán vị để giải nữa
- Machine Learning -> Warm start: Gom cụm bằng clustering (K-Mean), giải Tsp trong cụm, quăng vô làm warm start => Bài toán tổng được rút ngắn khá nhiều
Liên quan tới input của bài toán Routing này, là distance matrix, các đơn vị distance matrix thì tràn lan trên mạng, có thể dùng AI để benchmark đơn vị nào là phù hợp với các yếu tố: Matrix 1 lần call API lớn nhưng tần suất thấp (giải 1 lần nhiều đơn hàng nhưng ít khi giải), hay matrix nhỏ nhưng tần suất nhiều. Ngày xưa mình có dùng Travel Time (một đơn vị cung cấp bên UK), trả fixed 1 khoảng tiền cho số lượng element vô hạn, tuy nhiên giới hạn matrix size, nhưng 1 phút sẽ refresh lại 1 lần, thêm matrix size = thêm tiền.
Còn tự build distance matrix, hãy cân nhắc các thuật toán vẽ offset theo địa hình. Giải bài toán shortest path = disktra, A-star, Bi-directional A-star.
Hiểu biết chuyên sâu về geospatial programming, lý thuyết đồ thị. Từ khoá gợi ý: Thư viện OSMNX Python (gồm các thư viện NetworkX, Geopandas,…). Ngày xưa mình chưa kịp làm thì bể project ròi 🥹
Chúc bạn tìm được câu trả lời tốt nhất cho mình.
Quang Toàn Lê Nguyễn (Tác giả):
Em cảm ơn những câu trả lời vô cùng chất lượng của anh chị. Nhờ vậy mà em cũng biết được bước tiếp theo mình sẽ làm.
Để thảo luận được cụ thể hóa hơn thì em cần thời gian để tổng hợp thông tin sau đó sẽ thảo luận sâu hơn với anh chị ạ.
Son nguyen hoang:
Hi em, anh xin đóng góp vài kinh nghiệm vận hành của anh:
A. Quản lý tồn kho
1/ Rule phân label A,B,C:
cách em đánh label A,B,C là đúng hướng, nhưng chưa rõ cái rule em đánh label, dựa trên những gì em mô tả, anh đoán rule là dựa trên (ngày tồn kho trung bình, volume tổng).
Anh đề xuất thêm rule label A,B,C:
ABC → Average Days Inventor, volume
sang
ABC + Demand variability + diện tích chiếm chỗ + Aging
khi đổi sang như vậy, thì label A sẽ chi tiết hơn trong việc tách nhóm và ra quyết định.
Ví dụ:
- label A sku1 mà Demand variability thấp, chiếm chỗ ít => ưu tiên availability
- label A sku2 mà Demand variability cao, chiếm chỗ nhiều => kiểm soát chặt theo ngày
- label B sku3 mà Demand variability thấp, chiếm chỗ nhiều => đặt vừa số lượng vừa đủ
2/ Giá trị chiếm chỗ:
Em nêu "SKU chiếm thể tích nhưng không tạo ra giá trị" => quá rõ ràng em bổ sung thêm chỉ số đánh giá: giá trị chiếm chỗ.
Ví dụ:
SKU A: bán 500 triệu/tháng, chiếm 20 m3 → giá trị chiếm chỗ 25 triệu/m3/tháng.
SKU B: bán 150 triệu/tháng, chiếm 2 m3 -> giá trị chiếm chỗ 75 triệu/m3/tháng.
=> rõ ràng A sử dụng không gian nhưng ko hiệu quả như B.
Lúc đó em lại có thêm 1 nguyên tắc xử lý:
- bán nhiều + chiếm chỗ ít: ưu tiên
- bán nhiều + chiếm chỗ lớn: kiểm soát replenishment rất kỹ
- bán ít + chiếm chỗ nhỏ: bình thường
- bán ít + chiếm chỗ lớn: nguy hiểm nhất ==> xử lý đầu tiên
3/ Day of Supply (DOS):
"SKU bán chạy tại cửa hàng nhưng tồn kho đang bằng 0. Hiểu là ở cửa hàng thì tồn đang hết dần, kho thì chưa nhập hàng về" - Trong vận hành thực tế, thường cấp quản lý sẽ sử dụng thuật ngữ tồn theo số ngày bán hàng (Day of Supply) hơn là số lượng tồn.
Ví dụ:
SKU A: Inventory = 1.000, demand = 100/ngày ==> DOS = 1000 / 100 = 10 ngày (tồn 10 ngày bán hàng)
SKU B: Inventory = 500, demand = 20/ngày ==> DOS = 25 ngày (tồn 25 ngày bán hàng)
Nhìn inventory thì SKU A lớn hơn. Nhưng SKU B mới là SKU đáng lo.
Và mục tiêu tồn kho cũng nên chưa vậy:
- SKU A01, hiện tồn DOS 12, mục tiêu DOS 14 => tình trạng OK
- SKU A02, hiện tồn DOS 31, mục tiêu DOS 15 => Overstock
- SKU A03, hiện tồn DOS 4, mục tiêu DOS 12 => Rủi ro thiếu hàng
- SKU B04, hiện tồn DOS 45 mục tiêu DOS 20 => Overstock
4/ Quản lý đầu vào (Inbound control):
em nêu "mình có thể quản lý đầu vào hay facing trong kho như thế nào để tránh việc phải xử lý vấn đề liên quan tới những SKU label A,B tồn lâu tại kho".
Anh đoán góc nhìn: nhập hàng → bị overstock → phát hiện → clearance ==> em đang bị động trong khâu xử lý.
Em nên đổi: Phân tích Demand → check Vị trí tồn kho → Quyết định → Inbound control.
Ví dụ:
demand trung bình = 100/ngày
lead time supplier = 10 ngày
safety stock: 3 ngày bán hàng (300 units)
ROP = 100 × 10 + 300 = 1.300 (13 DOS) ==> thấp hơn (13 DOS) thì đặt, cao hơn (13 DOS) thì ko.
Vị trí tồn kho = tồn trong tay + tồn đang về - tồn đã lên lịch - tồn backlog
Ví dụ:
Kho còn 1.000.
Nhưng đã order supplier 2.000 đang trên đường.
Nếu hệ thống chỉ nhìn 1.000: "Tồn thấp → mua thêm!" → overstock toang!!!
Trước khi PO/inbound được release, hệ thống kiểm tra: dự tính DOS = (Onhand + Inbound) / Forecast Daily Demand
Nếu dự tính DOS > Max DOS → warning.
5/ Multi-Echelon Inventory:
em nêu "kho nhập về thì số lượng bao nhiêu là đủ để có thể đáp ứng được demand của tất cả các cửa hàng vừa cân bằng được tồn kho hiện tại của kho" => đây là bài toán Multi-Echelon Inventory.
em ko nên hỏi "Kho DC cần tồn bao nhiêu?" ==> hãy hỏi "DC + toàn bộ stores downstream đang cần bao nhiêu?"
Ví dụ 20 cửa hàng. Một SKU có:
tổng forecast 20 store = 1.000/week
trong tay đang có = 400
mục tiêu tồn = 1.500
đang trên đường tới store = 200
==> Tổng cần: 1.500 - 400 - 200 = 900
Nhưng DC cũng cần buffer. Safety stock DC = 300. Thì inbound requirement khoảng: 900 + 300 = 1.200
6/ NCC giao thiếu:
Nếu supplier chỉ giao thiếu thì chia thế nào? Giả sử supplier chỉ giao 600 nhưng hệ thống cần 1.200.
Không nên: chia đều, hoặc cửa hàng lớn lấy trước hết.
Nên dự vào DOS - tồn theo ngày bán hàng.
Ví dụ:
Store S1 | DOS = 0
Store S2 | DOS = 1
Store S3 | DOS = 3
Store S4 | DOS = 8
Inbound mới về thì S1/S2 cần ưu tiên trước.
Mục tiêu là cân bằng risk of stockout, không phải cân bằng số lượng.
7/ Đề xuất hệ thống quản lý inventory thành 4 tầng:
Forecast ==> Target Inventory (check theo LT, forecast) ==> Replenishment ==> Allocation
Dashboard chỉ cần tập trung vào:
- Overstock - SKU nào? ở DC nào?
- Stockout - SKU nào? ở DC nào?
- Aged stock - SKU nào? ở DC nào?
- Inbound flag - SKU inbound nào sẽ gây overstock
- Giá trị chiếm chỗ thấp
- Store imbalance
B. Vận tải
1/ Dữ liệu nền tảng:
Để tối ưu được bài toán vận tải. Điều đầu tiên em cần có là data về ma trận khoảng cách, thời gian (dựa theo lat, log), demand mỗi ngày.
Để tìm ma trận khoảng cách một cách đơn giản, chính xác => sử dụng google app script (hỏi chatgpt) tài khoản free thường được request 2500 cặp điểm/24h.
2/ Network Design Optimization:
Em nêu "Tìm ra phân tuyến phù hợp với từng kho DC, từng địa hình vùng miền và phân bổ cửa hàng của từng kho DC" => đây là bài toán Network Design Optimization => em có thể hỏi chatgpt tạo code python để giải (Ưu tiên các phương pháp tối ưu bằng MILP, bộ giải open source "Highs").
Lưu ý: em phải đưa yếu tổ demand trung bình (ngày,tháng,năm) để giải ra kết quả tốt. Kết quả trả ra sẽ là DC sẽ phục vụ cửa hàng nào.
3/ Phân loại đúng bài toán:
"Tuy nhiên, em luôn tìm cách để tối ưu chi phí vận chuyển", "em đang theo dõi tình hình phân tuyến hằng ngày của thuật toán theo kho DC, vùng miền và sắp tới sẽ là hình dạng phân tuyến cửa hàng của kho DC".
Phương pháp, em cẩn xác định và phân loại rõ bài toán. Giả sử em làm xong mục 2, ở mục 3 này: em cần xác định:
- Giao hàng của em là giao nguyên chuyến hay đi giao nhiều điểm / chuyến => tách riêng ra vì nếu như tỉ lệ giao nguyên chuyến cao, thì gần chạm ngưỡng tối ưu về mặt di chuyển rồi
- Giao bao nhiêu chuyến 1 ngày, có tách đơn tách điểm, chạy tăng bo,...
- DC có đội xe riêng hay sở hữu xe thuê, hay dùng cả 2
- Thời gian giao hàng, cấm đường, cấm tải. Kho giới hạn tải trọng
=> Mỗi yếu tố sẽ tạo nên 1 bài toán khác, cần xác định đúng trước khi xây giải thuật.
4/ Hệ thống KPIs vận tải:
"chi phí, số điểm giao, tỉ lệ đầy xe thì em còn nên follow những KPIs nào nữa để tối ưu được tuyến" - Một route có thể: full xe, giao nhiều điểm, km thấp, nhưng vẫn tệ vì: waiting time cao, overtime, quay đầu nhiều, failed delivery, cấm giờ, cấm tải, giao quá sớm/quá muộn.
Nên chia KPI thành các nhóm.
Nhóm 1) Cost efficiency
Em nên theo dõi: Cost / Delivery, Cost / km, Cost / thùng, Cost / kg, Cost / m3.
Quan trọng nhất với retail thường là: Cost per SUCCESSFUL drop (Chi phí giao hàng thành công) vì ko thành công sẽ tốn phí giao lại.
Nhóm 2) Time efficiency
Em nên theo dõi, phân rã thời gian chi tiết: Thời gian lái xe, Thời gian phục vụ, Thời gian chờ.
Ví dụ route = 10 giờ: Lái xe: 4h; Lên xuống tải: 3h; Thời gian chờ: 2h; Chờ: 1h.
Thay đổi algorithm routing có thể chỉ cải thiện 20 phút. Trong khi cải tiến appointment/store unloading có thể saving 2 giờ.
Nhóm 3) Service KPI
Cái này là tiêu chuẩn giao hàng: OTIF — On Time In Full, On-time arrival %, Delivery success %, Re-delivery %, Missed time window %, Route completion %, Returned goods %.
Một route rẻ nhưng failed delivery cao thì không thực sự rẻ.
Nhóm 4) Vehicle KPI
Nhóm này có thể đưa vào giải thuật để tăng tính tối ưu, và đánh giá: Utilization khối lượng chở, Utilization Thể tích chở.
Nhóm 5) Distance efficiency
tính số km / drop.
Ví dụ: Route A: 100 km / 20 stores = 5 km/drop. Route B: 100 km / 5 stores = 20 km/drop. Hai route có economics khác nhau => sử dụng xe thuê hay xử dụng đội xe hiện có.
Số % km chạy rỗng trên 1 chuyến (%). Có những DC bị geography rất xấu.
Ví dụ: DC tới cụm cửa hàng gần 100km => Thuật toán không thể sửa hoàn toàn vấn đề này. Đây là network design problem, không phải routing problem. Các chuyến xe overlap.
Nhóm quan trọng nhất: Planned vs Actual
Phải so sánh được kết hoạch và actual => Xác định sai sót nếu có.
Ví dụ: km: 120 vs 151; driving: 4,2h vs 5,5h; stops: 18 vs 17; fillrate: 88% vs 88%; cost: 3,2m vs 4,1m.
Sau vài tháng có thể phát hiện: Algorithm không sai; Travel Time Matrix đang sai hoặc thiếu (do ko tính kẹt xe, chờ xếp tải unloading).
4/ Xây dựng theo địa hình vùng miền:
Em không nên build solver riêng cho từng miền. - Miền Bắc dùng algorithm A - Miền Trung algorithm B - Miền Nam algorithm C.
Thay vào đó em nên dựng một optimization engine, nhưng input parameters khác nhau. Ví dụ cùng giải Multi-depot Heterogeneous Fleet VRPTW.
TP.HCM: Kẹt xe; thời gian di chuyển phụ thuộc thời gian xuất phát; cấm tải, cấm giờ; Mật độ cửa hàng; nhiều time windows.
Tây Nguyên: khoảng cách lớn; mật độ cửa hàng thấp; road speed khác; đia hình ảnh hưởng.
Đồng bằng: có tuyến đường hạn chế tải; bridge restriction.
Algorithm không cần "biết Tây Nguyên" hay "Đồng Bằng", Nó cần biết: ma trận khoảng cách và thời gian thực tế; danh sách ràng buộc.
5/ Kinh nghiệm xây dựng tool tối ưu:
Em nên chia bài toán routing thành 3 giai đoạn.
Giai đoạn 1 — Network Design: Quyết định: Store nào thuộc DC nào? => Đây không phải VRP.
Giai đoạn 2 — Delivery frequency: Không phải store nào cũng phải giao mỗi ngày.
Ví dụ: A store: Mỗi ngày; B store: Giao Hai, Tư, Sáu; C store: Giao Ba, Năm.
Nếu tối ưu được delivery frequency thì saving đôi khi lớn hơn tối ưu route.
Giai đoạn 3 — Daily routing: Sau khi biết hôm nay cần giao store nào, mới giải: VRP / VRPTW.
Combine Giai đoạn 2 + 3: Bài toán Inventory Routing Problem => có thể saving nhiều hơn.
Giao diện: FOCUS VÀO GIAO DIỆN CHỈNH SỬA TUYẾN SAU KHI RA KẾT QUẢ TỐI ƯU VÌ KẾT QUẢ MÀ MÁY TÍNH TRẢ RA THƯỜNG TỐI ƯU MẶT TOÁN, CÒN VẬN HÀNH THÌ PHẢI CHỈNH LẠI.
KHÂU CHỈNH LẠI NẾU KO CÓ GIAO DIỆN TỐT THÌ RẤT CỰC, KẾT QUẢ TỐT CŨNG THÀNH TỆ.
Nếu em cần hỏi chi tiết: Sơn - 0834552286
Tổng Hợp Hướng Giải Quyết Bài Toán Tối Ưu Kho & Tuyến
Tóm lược các nhóm giải pháp then chốt từ thảo luận thành viên
Nhóm 1: Quản Trị Tồn Kho DC
Thông thoáng kho & giảm nghẽn dock
Kết hợp Doanh thu + Thể tích (m³) + Hệ số biến thiên (CV = σ / μ) + Giá trị chiếm chỗ (Doanh thu / m³ / tháng). Xả hàng nhóm C cồng kềnh.
Tính Projected DOS = (Tồn kho + Hàng đang về) / Nhu cầu dự báo. Nếu vượt Max Allowed DOS → Tự động chặn PO tránh tràn sàn nhận.
Khi NCC giao thiếu, ưu tiên lấp đầy store có DOS thấp nhất trước để giảm rủi ro đứt hàng thay vì chia đều.
Nhóm 2: Chuyển Đổi Cross-Docking
Cắt giảm 100% bước kệ lưu kho
Ưu tiên nhóm A2 (Bán chạy + Cồng kềnh như nước ngọt, giấy, mì) và hàng Promotion giao thẳng trong <24h. Tiết kiệm 70% lượt xe nâng.
Kho chữ I là lý tưởng nhất (luồng 1 chiều đối diện). Thiết lập khu đệm Staging Buffer (12-24h) để tránh gác ngược lên kệ cao khi lệch đơn.
Áp dụng Time-slot booking cho xe NCC khớp với giờ xuất xe giao store + Nhận trước file điện tử ASN & dán tem SSCC thùng hàng.
Nhóm 3: Tối Ưu Tuyến Vận Tải
Giảm chi phí & tăng tỷ lệ đầy xe
Gán Store nào thuộc DC nào phụ trách bằng mô hình MILP/K-Means theo chu kỳ 3 - 6 tháng dựa trên chi phí biên.
Quy hoạch ngày giao cố định: Store lớn giao hàng ngày; Store nhỏ gom tải giao 2-4-6 hoặc 3-5-7 để luôn đạt tỷ lệ đầy xe >85%.
Thuật toán gom cụm (Cluster-first Route-second) + Ràng buộc giờ cấm tải đô thị + Giao diện kéo thả cho điều phối viên.
Thuật toán chỉ tối ưu trên mô hình toán học; Hiệu quả thực tế đến từ việc đồng bộ hóa dữ liệu Inbound với Procurement và giao diện kéo thả cho điều phối viên.
Bảng Tra Cứu Thuật Ngữ
Định nghĩa các khái niệm cốt lõi trong chuỗi cung ứng và vận hành kho FMCG
| Thuật ngữ | Tên tiếng Anh | Định nghĩa & Ý nghĩa vận hành |
|---|---|---|
| DC | Distribution Center | Trung tâm phân phối đóng vai trò làm kho tổng để gom hàng số lượng lớn từ các nhà máy/nhà cung cấp và điều phối lại cho các siêu thị, cửa hàng bán lẻ. |
| SKU | Stock Keeping Unit | Mã định danh duy nhất cho từng sản phẩm riêng biệt (phân biệt rõ theo dung tích, mùi vị, quy cách đóng gói, ví dụ lon 330ml khác chai 1.5L). |
| LT | Lead Time | Tổng thời gian tính từ lúc phát hành đơn đặt hàng (PO) đến khi nhà cung cấp hoàn tất giao hàng vào cửa kho DC. |
| MOQ | Minimum Order Quantity | Số lượng đặt hàng tối thiểu mà nhà cung cấp bắt buộc người mua phải đặt trong một lần giao hàng. |
| PO | Purchase Order | Đơn đặt hàng chính thức do bộ phận Mua hàng (Procurement) gửi cho nhà cung cấp xác nhận số lượng, đơn giá và ngày giao. |
| ASN | Advanced Shipping Notice | Chứng từ thông báo gửi hàng điện tử được nhà cung cấp gửi trước khi xe hàng tới kho, giúp kho bố trí nhân sự và dock nhận hàng. |
| SSCC | Serial Shipping Container Code | Mã vạch định danh tiêu chuẩn quốc tế dán trên pallet hoặc thùng hàng, giúp máy quét mã vạch nhận diện toàn bộ kiện hàng trong 1 giây mà không cần mở thùng. |
| Multi-Echelon | Multi-Echelon Inventory System | Hệ thống quản trị tồn kho đa tầng, phối hợp đồng bộ dòng tồn kho từ kho tổng DC xuống toàn bộ các điểm bán lẻ downstream thay vì quản lý rời rạc. |
| VRP / VRPTW | Vehicle Routing Problem (with Time Windows) | Bài toán tối ưu hóa định tuyến xe vận tải nhằm tìm chuỗi lộ trình giao hàng có tổng chi phí và quãng đường ngắn nhất kèm ràng buộc khung giờ nhận hàng. |
| Drop | Delivery Drop | Một điểm dừng trả hàng của xe tải tại một cửa hàng hoặc đại lý cụ thể trên tuyến giao. |
| CBM / m³ | Cubic Meter | Mét khối - đơn vị đo thể tích chiếm chỗ của hàng hóa trên giá kệ kho hoặc thùng xe tải vận chuyển. |
| CSL | Cycle Service Level | Xác suất KHÔNG bị hết hàng trong một chu kỳ đặt hàng (từ lúc đặt PO tới lúc PO kế tiếp về). Là căn cứ để tính Safety Stock chính xác theo từng SKU thay vì dùng số ngày cố định. |
| Safety Factor (z) | Safety Factor / k* | Hệ số nhân với độ lệch chuẩn nhu cầu trong lead time để ra Safety Stock. Tra từ bảng phân phối chuẩn theo CSL mong muốn (VD CSL 95% → z=1.65). |
| CDF | Cross-Docking Facility | Khu vực trung chuyển nơi hàng nhận từ NCC được phân loại và xuất thẳng lên xe giao mà không lưu kho quá 24-48 giờ, khác với kho lưu trữ truyền thống. |
| Common Cycle Time (T*) | Common Replenishment Cycle | Nhịp thời gian chung được gán cho một nhóm SKU chia sẻ cùng 1 chi phí thiết lập (VD 1 đợt đồng bộ dock), thay vì mỗi SKU/NCC có lịch giao riêng lẻ. |
| CVRP | Capacitated Vehicle Routing Problem | Phiên bản VRP có ràng buộc tải trọng/thể tích xe: tổng nhu cầu các điểm trên một tuyến không được vượt sức chứa của xe. |
| Service District | Delivery District / Zone | Một vùng con trong tổng vùng phục vụ của DC, được gán cố định cho một xe/tuyến phụ trách, dùng trong ước lượng nhanh quãng đường tối ưu (Continuous Approximation). |
Bảng Tra Cứu Chỉ Số
Công thức tính toán và ví dụ minh họa
| Chỉ số | Ý nghĩa và minh họa công thức |
|---|---|
| DOS Days of Supply (Số ngày tồn kho) |
Đo lường lượng hàng tồn kho thực tế có thể duy trì bán được trong bao nhiêu ngày nữa trước khi cạn kiệt.
DOS (Ngày) = Tồn kho thực tế (Units) / Nhu cầu bán trung bình 1 ngày (Units/Ngày)
Ví dụ: Kho DC đang tồn 1.200 thùng nước tương. Nhu cầu xuất trung bình của 100 siêu thị là 150 thùng/ngày.
→ DOS = 1.200 / 150 = 8.0 ngày bán hàng. |
| Projected DOS Số ngày tồn dự kiến (Cổng Inbound) |
Dự phóng số ngày tồn kho sau khi tiếp nhận toàn bộ các đơn hàng PO đang trên đường giao về kho nhằm ngăn chặn nhập quá tải.
Projected DOS = (Tồn kho thực tế + Hàng PO đang về) / Nhu cầu dự báo mỗi ngày
Ví dụ: Kho đang tồn 500 thùng bột giặt, vừa tạo thêm PO 2.000 thùng đang về. Forecast bán là 100 thùng/ngày. Ngưỡng Max DOS cho phép là 15 ngày.
→ Projected DOS = (500 + 2.000) / 100 = 25.0 ngày. → Cảnh báo: Projected DOS (25 ngày) > Max DOS (15 ngày) → Hệ thống tự động khóa PO hoặc yêu cầu giãn lịch giao để tránh tắc nghẽn dock nhận. |
| CV (σ / μ) Hệ số biến thiên nhu cầu |
Đo mức độ dao động của sức mua quanh giá trị trung bình để cấu hình mức tồn kho an toàn (Safety Stock).
CV = Độ lệch chuẩn nhu cầu (σ) / Nhu cầu bán trung bình (μ)
Ví dụ:
• SKU 1 (Mì gói): Bán trung bình μ = 100 thùng/ngày, độ lệch chuẩn σ = 10 thùng → CV = 10 / 100 = 0.10 (10% - Rất ổn định → Nhóm X). • SKU 2 (Hàng mùa vụ): Bán trung bình μ = 20 thùng/ngày, độ lệch chuẩn σ = 18 thùng → CV = 18 / 20 = 0.90 (90% - Biến động lớn → Nhóm Z). |
| ROP Reorder Point (Điểm đặt hàng lại) |
Mức tồn kho tối thiểu báo hiệu thời điểm cần phát hành đơn đặt hàng mới để không bị đứt hàng trong thời gian chờ nhà cung cấp giao.
ROP = (Nhu cầu bán trung bình ngày × Lead Time giao hàng) + Safety Stock
Ví dụ: Nhu cầu = 100 thùng/ngày, Lead time = 3 ngày, Safety stock = 200 thùng.
→ ROP = (100 × 3) + 200 = 500 thùng (Tồn kho chạm mốc 500 thùng là kích hoạt PO mới ngay). |
| OTIF On-Time In-Full |
Thước đo chất lượng dịch vụ vận tải: Tỷ lệ phần trăm các chuyến hàng vừa đến đúng giờ hẹn vừa giao đủ 100% số lượng đơn đặt.
OTIF (%) = (Số đơn hàng giao VỪA ĐÚNG GIỜ VÀ ĐỦ 100% SỐ LƯỢNG / Tổng số đơn hàng giao) × 100
Ví dụ: Trong tuần DC xuất 1.000 chuyến xe. Có 950 chuyến đúng giờ (95%), nhưng có 70 chuyến bị giao thiếu hàng. Số chuyến vừa đúng giờ vừa đủ hàng là 880.
→ OTIF = (880 / 1.000) × 100 = 88.0%. |
| Cost / Drop Cost per Successful Drop |
Chi phí thực tế để hoàn tất giao hàng thành công tại một điểm bán lẻ (tính cả chi phí phát sinh nếu phải giao lại).
Cost per Successful Drop = Tổng chi phí chuyến xe / Số điểm cửa hàng giao nhận thành công
Ví dụ: Chuyến xe tốn 1.200.000 VNĐ chi phí vận hành. Kế hoạch giao 6 cửa hàng, nhưng 1 cửa hàng từ chối nhận do trễ giờ nên chỉ giao thành công 5 điểm.
→ Cost per Successful Drop = 1.200.000 / 5 = 240.000 VNĐ/điểm giao (tăng 20% so với kế hoạch 200.000 VNĐ). |
| Vehicle Utilization Tỷ lệ lấp đầy xe (CBM & Tải trọng) |
Đo mức độ khai thác tối ưu không gian chứa hàng (thể tích m³) hoặc tải trọng (tấn) của thùng xe tải.
Tỷ lệ lấp đầy thể tích (%) = (Tổng thể tích hàng trên xe / Dung tích thùng xe) × 100
Ví dụ: Xe tải có thể tích thùng 28 CBM chở hàng nhẹ (tã giấy). Thể tích hàng xếp kín là 25.2 CBM.
→ Tỷ lệ lấp đầy thể tích = (25.2 / 28) × 100 = 90.0%. |
| SS (theo CSL) Safety Stock chính xác theo Service Level |
Lượng tồn đệm tính theo độ lệch chuẩn nhu cầu thực tế của từng SKU, thay cho quy tắc "N ngày cố định" – xem chi tiết tại mục 5.2A.
σ(X) = √L × σ(nhu cầu ngày) | SS = z × σ(X) | ROP = L×E(nhu cầu ngày) + SS
Ví dụ: L = 3 ngày, nhu cầu TB = 100 thùng/ngày, σ = 15 thùng/ngày, CSL 95% (z=1.65).
→ σ(X) = √3×15 = 26 → SS = 1.65×26 ≈ 43 thùng → ROP = 300+43 = 343 thùng. |
| Điểm Xếp Hạng R Cost-Service Ranking (Teunter et al., 2009) |
Tiêu chí xếp ABC tối ưu chi phí toàn hệ thống, thay cho xếp theo doanh thu – xem chi tiết tại mục 5.2B.
R = (cs × E(y)) / √(2 × s × h)
Ví dụ: Giấy vệ sinh: R ≈ 111.800 | Mỹ phẩm cao cấp: R ≈ 1.500 → dù cùng hạng A theo doanh thu, giấy vệ sinh cần CSL cao hơn hẳn.
|
| SS Gộp Multi-Echelon Pooling |
Tổng Safety Stock cần giữ khi gộp buffer nhiều điểm bán vào 1 buffer chung tại DC – xem chi tiết tại mục 5.2C.
SS Gộp = z × √(σ1² + σ2² + ... + σn²) ≤ ∑ SS riêng lẻ
Ví dụ: 4 cửa hàng, σ = 10, 8, 6, 12 → SS riêng = 59.4 thùng | SS gộp = 30.6 thùng (tiết kiệm ~48%).
|
| T* (Cross-Dock) Common Cycle Time |
Nhịp đồng bộ chung cho cả nhóm SKU cross-dock, thay vì mỗi NCC giao theo lịch riêng – xem chi tiết tại mục 6.2.
T* = √( 2cp / ∑chiDi ) | qi* = Di × T*
Ví dụ: 5 SKU, cp=800.000đ, ∑chiDi≈9.1 tỷ → T* ≈ 4.8 ngày (làm tròn 5 ngày/lần đồng bộ).
|
| D* Continuous Approximation (Daganzo) |
Ước lượng nhanh tổng quãng đường tối ưu lý thuyết của một vùng phục vụ, dùng làm mốc benchmark – xem chi tiết tại mục 7.2.
D* ≈ 2r(n/q) + ξ(q)√(A×n)
Ví dụ: Vùng đô thị (n=100, A=900km², r=15km, q=8) → D* ≈ 546 km/ngày (13 xe) | Vùng thưa dân (n=40, A=12.000km², r=60km, q=5) → D* ≈ 1.355 km/ngày (8 xe).
|
Ma Trận Phân Loại SKU Đa Chiều (ABC-XYZ)
Mở rộng phương pháp ABC truyền thống để giải quyết bài toán "SKU chiếm thể tích nhưng sinh lời kém"
Ví dụ: Mỹ phẩm, dầu gội cao cấp. Doanh thu 150 triệu/tháng, chỉ chiếm 2 m³ kho.
Ví dụ: Giấy vệ sinh, nước ngọt, tã bỉm. Doanh thu 500 triệu/tháng nhưng chiếm tới 20 m³ kho.
Ví dụ: Pin tiểu, dao cạo râu. Giữ mức tồn trưng bày tối thiểu (Min Display).
Ví dụ: Thau chậu nhựa, hộp đựng lớn. Chiếm 15 m³ nhưng doanh thu chỉ 35 triệu/tháng.
Công Thức Kiểm Soát Cốt Lõi
1. Điểm đặt hàng lại (Reorder Point - ROP):
→ ROP = (100 × 3) + 200 = 500 thùng (Tồn kho chạm 500 thùng là tạo PO mới).
Dữ Liệu Đối Thoại Với Procurement
Số liệu chứng minh để thuyết phục bộ phận Mua hàng:
- Inbound Spike Index: Tỷ lệ đột biến nhập (VD: Nhập 1 lần 20 tấn trong khi dock chỉ nhận tối đa 8 tấn/ca).
- Space Cost Penalty: Chi phí chiếm chỗ kệ của đơn hàng ôm giá rẻ nhưng DOS > 45 ngày.
Nền Tảng Học Thuật: Safety Factor, Xếp Hạng ABC & Gộp Tồn Kho Đa Điểm
Bổ sung công thức Operations Research cho 3 câu hỏi mở trong phần thảo luận (ROP chính xác hơn, tiêu chí ABC tối ưu chi phí, và phân bổ khi NCC giao thiếu)
A. Safety Stock theo Mức Độ Biến Động (thay vì "cứng N ngày an toàn")
Cách "safety stock = 3 ngày bán hàng cố định" mà nhiều DC hay dùng không phân biệt được SKU ổn định (nhóm X) với SKU biến động mạnh (nhóm Z) — đúng như ma trận ABC-XYZ ở mục 5.1 đã phân loại. Công thức chuẩn dưới đây gắn Safety Stock trực tiếp vào độ lệch chuẩn nhu cầu của từng SKU:
ROP (r*) = E(X) + z × σ(X) (z = hệ số an toàn ứng với mức phục vụ mong muốn)
| Cycle Service Level mong muốn | 90% | 95% | 98% | 99% |
|---|---|---|---|---|
| Hệ số an toàn z | 1.28 | 1.65 | 2.05 | 2.33 |
• SKU nhóm X (ổn định): nhu cầu 100 thùng/ngày, σ = 15 → σ(X) = √3×15 = 26 → SS = 1.65×26 ≈ 43 thùng → r* = 300+43 = 343 thùng (thấp hơn nhiều so với quy tắc "3 ngày = 300").
• SKU nhóm Z (biến động, CV=0.9): nhu cầu 20 thùng/ngày, σ = 18 → σ(X) = √3×18 = 31.2 → SS = 1.65×31.2 ≈ 52 thùng → r* = 60+52 = 112 thùng (cao hơn quy tắc "3 ngày = 60", nghĩa là buffer cố định đang ÍT HƠN mức cần thiết cho SKU này).
→ Áp dụng: dùng chung 1 công thức, chỉ thay σ (đo từ dữ liệu bán 8-13 tuần gần nhất) theo từng SKU – tự động sinh ra buffer thấp cho nhóm X, cao cho nhóm Z, không cần rule cứng theo số ngày.
B. Tiêu Chí Xếp Hạng ABC Tối Ưu Chi Phí (Teunter, Babai & Syntetos, 2009)
Xếp hạng theo doanh thu (như mục 5.1 đang dùng) thường KHÔNG phải là cách tiết kiệm chi phí nhất: nghiên cứu gốc chỉ ra rằng SKU giá trị cao nên nhận mức phục vụ thấp hơn, không phải cao hơn, nếu xét trên toàn bộ ngân sách tồn kho. Tiêu chí thay thế xét đồng thời độ quan trọng, nhu cầu, chi phí đặt hàng và chi phí tồn trữ:
cs: chi phí thiếu hàng/đơn vị · E(y): nhu cầu năm · s: chi phí đặt hàng/đợt · h: chi phí tồn trữ 1 đơn vị/năm
• SKU giấy vệ sinh (giá rẻ, bán rất nhiều): cs=40.000đ, E(y)=500.000/năm, s=2tr đ, h=8.000đ → R ≈ 111.800
• SKU mỹ phẩm cao cấp (giá cao, bán ít hơn nhưng doanh thu tương đương): cs=300.000đ, E(y)=5.000/năm, s=2tr đ, h=250.000đ → R ≈ 1.500
→ Dù cùng hạng A theo doanh thu, giấy vệ sinh nên được ưu tiên CSL cao hơn hẳn mỹ phẩm – vì chi phí tồn trữ/đặt hàng trên mỗi đơn vị giá trị thấp hơn nhiều. Gán: Top 20% điểm R → CSL 98%; 50% giữa → CSL 92%; 30% còn lại → CSL 85%.
C. Gộp Tồn Kho An Toàn Đa Điểm (Multi-Echelon Pooling) & Thuật Toán Phân Bổ Khi NCC Giao Thiếu
Nếu nhu cầu của các cửa hàng tương đối độc lập với nhau, giữ 1 buffer an toàn chung tại DC luôn cần ÍT hơn tổng các buffer lẻ tại từng điểm, vì các dao động thừa/thiếu triệt tiêu bớt lẫn nhau:
• Giữ buffer riêng từng cửa hàng: SS = 1.65×(10+8+6+12) = 59.4 thùng
• Giữ 1 buffer chung tại DC: SS = 1.65×√(10²+8²+6²+12²) = 1.65×18.55 = 30.6 thùng
→ Tiết kiệm gần 48% tồn kho an toàn mà vẫn giữ nguyên CSL 95% toàn hệ thống.
Khi nhà cung cấp chỉ giao được một phần, buffer chung này cần được chia lại cho các điểm – thuật toán đơn giản sau bám sát gợi ý "cân bằng rủi ro hết hàng, không cân bằng số lượng" đã nêu trong phần thảo luận:
Thuật toán phân bổ Greedy theo DOS thấp nhất
1. Tính DOSi = Tồn hiện cói / Nhu cầu dự báo ngàyi cho từng cửa hàng i
2. Sắp xếp danh sách cửa hàng theo DOS tăng dần (DOS thấp nhất = rủi ro đứt hàng cao nhất)
3. Cấp hàng lần lượt cho cửa hàng đứng đầu danh sách tới khi DOS đạt mức mục tiêu tối thiểu (VD 3 ngày)
4. Chuyển phần còn lại của lô hàng cho cửa hàng tiếp theo trong danh sách, lặp lại bước 3
5. Dừng khi hết hàng nhận được hoặc toàn bộ cửa hàng đã đạt DOS mục tiêu
Mô Hình Kho Cross-Docking
Cắt giảm 100% bước Putaway & Picking đối với nhóm hàng Fast-Moving
Đồng Bộ Giờ Xe (Dock Booking)
Ví dụ: Xe NCC sữa tươi cập dock 06:00 sáng, xe tải phân phối đi 20 siêu thị xuất bến 08:30 sáng.
Quy Chuẩn ASN & SSCC
NCC dán sẵn mã thùng chuẩn, nhân viên kho chỉ quét mã vạch 1 giây là hệ thống tự chia sang line xe tương ứng.
Khu Đệm Staging Buffer (12-24h)
Thiết lập khu đệm mặt sàn để giữ hàng lệch đơn tạm thời, tuyệt đối không dùng xe nâng đưa ngược lên giá kệ cao.
Nền Tảng Học Thuật: Đồng Bộ Nhịp Nhập-Xuất Chung (Common Cycle Time)
Xử lý đúng gốc rễ vấn đề "NCC giao lệch nhịp → dư hàng → buộc gác kệ → giật xe nâng" đã nêu trong phần thảo luận
Nguyên nhân gốc của tình trạng "thiếu xe nâng vì phải gác hàng dư lên kệ" là các SKU cross-dock đang được nhận theo lịch riêng của từng NCC, khiến khối lượng đến dock dao động thất thường. Về học thuật, khi nhiều SKU cùng chia sẻ 1 chi phí thiết lập cố định (đợt đồng bộ dock/xe nâng/nhân sự), lời giải tối ưu luôn là gán cho tất cả SKU cùng một nhịp chu kỳ chung T* – không phải nhịp lệch nhau theo từng NCC:
cp: chi phí cố định mỗi đợt đồng bộ dock · Di: nhu cầu năm SKU i · chi: chi phí tồn trữ/lưu bãi đơn vị của SKU i tại khu đệm
| SKU cross-dock | Di (thùng/năm) | chi (đ/thùng/năm) | qi* mỗi đợt (T*≈5 ngày) |
|---|---|---|---|
| Sữa tươi | 150.000 | 12.000 | ~1.990 |
| Nước ngọt | 400.000 | 8.000 | ~5.300 |
| Giấy vệ sinh | 300.000 | 6.000 | ~3.980 |
| Bánh kẹo | 100.000 | 15.000 | ~1.330 |
| Dầu ăn | 80.000 | 10.000 | ~1.060 |
Thuật toán thiết lập nhịp Cross-Dock chung
1. Chọn nhóm SKU đủ điều kiện cross-dock: Fast-moving, biến động thấp (nhóm X/Y trong ma trận ABC-XYZ, mục 5.1)
2. Thu thập Di (forecast nhu cầu năm) và chi (chi phí lưu bãi/vốn) cho từng SKU trong nhóm
3. Tính T* chung cho cả nhóm bằng công thức trên, làm tròn về lịch vận hành thực tế
4. Chuyển cho Procurement đàm phán lại lịch giao NCC theo đúng nhịp T*, khối lượng mỗi đợt = Di × T*
5. Kiểm tra tổng khối lượng mỗi đợt so với công suất dock/xe nâng mỗi ca – nếu vượt, tách nhóm SKU thành 2 sub-cycle lệch giờ trong ngày (offset scheduling) thay vì dồn 1 lần
6. Với SKU biến động cao hơn dự kiến (nhóm Z), không ép cross-dock thuần túy – giữ lại một buffer nhỏ theo công thức Safety Stock ở mục 5.2A để tránh thiếu hàng khi forecast lệch
Kiến Trúc Tối Ưu Tuyến Vận Tải 3 Tầng
Phân định rõ bài toán Thiết Kế Mạng Lưới, Tần Suất Giao Hàng và Điều Tuyến Hàng Ngày
Network Design & Allocation
Giải bài toán MILP gán 100 cửa hàng vào DC tối ưu.
Ví dụ: Store cách DC 12km được gán cố định cho DC Đông Sài Gòn, giảm 15% km chạy rỗng.
Delivery Frequency / Rhythm
Quy hoạch ngày giao cố định (2-4-6 hoặc 3-5-7).
Ví dụ: Gom đơn 30 cửa hàng nhỏ giao 3 ngày/tuần, nâng tỷ lệ đầy xe từ 55% lên 88%.
Daily Dynamic VRPTW + UI
Chạy OR-Tools gom cụm kèm giờ cấm tải.
Ví dụ: Giảm tổng quãng đường từ 160km xuống 105km, tiết kiệm 1.1 triệu VNĐ/ngày.
| Chỉ số so sánh | Điều tuyến truyền thống (Chạy chéo) | Tối ưu hóa gom cụm (Cluster-First) | Mức độ cải thiện |
|---|---|---|---|
| Tổng quãng đường di chuyển | 160 km / ngày | 105 km / ngày | -34.4% km lăn bánh |
| Tỷ lệ lấp đầy thùng xe bình quân | 62.0% CBM | 89.0% CBM | +27.0% tải trọng |
| Chi phí vận tải mỗi ngày | 3.200.000 VNĐ | 2.100.000 VNĐ | Tiết kiệm 1.100.000 VNĐ/ngày |
| Tỷ lệ giao đúng hẹn (OTIF) | 82.5% | 96.0% | +13.5% chất lượng dịch vụ |
Nền Tảng Học Thuật: Công Thức Xấp Xỉ Liên Tục Cho Định Tuyến & Thiết Kế Vùng
Trả lời trực tiếp 2 câu hỏi: nên thêm KPI benchmark nào, và có cần xây thuật toán riêng cho từng vùng miền không
Không cần biết trước lời giải VRP chi tiết, có thể ước lượng nhanh tổng quãng đường tối ưu lý thuyết của một vùng phục vụ chỉ từ 4 số liệu: diện tích vùng, khoảng cách trung bình từ kho tới cửa hàng, tổng số cửa hàng và số điểm giao trung bình mỗi tuyến:
r: khoảng cách TB kho→cửa hàng · A: diện tích vùng phục vụ (km²) · n: tổng số cửa hàng · q: số điểm giao/tuyến
| Tham số vùng | Vùng đô thị mật độ cao (VD: TP.HCM) | Vùng thưa dân (VD: Tây Nguyên) |
|---|---|---|
| Số cửa hàng (n) | 100 | 40 |
| Diện tích vùng A (km²) | 900 | 12.000 |
| Khoảng cách TB tới kho r (km) | 15 | 60 |
| Điểm giao/tuyến (q) | 8 | 5 |
| Tổng quãng đường lý thuyết D* | 546 km/ngày (13 xe) | 1.355 km/ngày (8 xe) |
| Quy đổi km/cửa hàng | 5.5 km/điểm | 33.9 km/điểm (~6 lần) |
Trả lời câu hỏi "có cần thuật toán riêng theo vùng miền": bảng trên dùng đúng một công thức cho cả 2 vùng, chỉ thay 4 tham số đầu vào (A, r, n, q) theo đặc thù địa lý – không cần viết engine riêng cho từng miền. Chênh lệch km/điểm gấp ~6 lần giữa 2 vùng cho thấy đây là vấn đề Network Design (vị trí kho, phạm vi phục vụ) chứ không phải lỗi thuật toán VRP hàng ngày.
Mô Phỏng Phân Bổ Tồn Kho Đa Điểm Khi NCC Giao Thiếu
So sánh phương pháp Phân bổ truyền thống (Chia đều) vs Phân bổ cân bằng DOS (Fair-Share)
| Cửa hàng (Store) | Sức bán/ngày | Tồn hiện tại | DOS Hiện Tại | Chia Đều (Naïve) | Phân Bổ Fair-Share | DOS Mới |
|---|
Đánh Giá Chiến Lược
Hệ thống tự động ưu tiên dồn hàng cho Store có số ngày bán hàng thấp nhất (nguy cơ đứt hàng cao nhất) nhằm nâng DOS của toàn chuỗi lên mức đồng đều.
Mô Phỏng Thuật Toán Gom Tuyến Cửa Hàng (VRP Routing)
Giả lập 10 cửa hàng bán lẻ phân tán và thuật toán gom cụm tối ưu xe tải giao hàng
Thông Số Kế Hoạch Vận Chuyển
Trong thực tế, điều phối viên luôn cần bản đồ để điều chỉnh lại các điểm giáp ranh khi gặp sự cố tắc đường hoặc cửa hàng dời giờ nhận hàng.