Quản lý tồn kho và theo dõi thuật toán phân tuyến

Quang Toàn Lê Nguyễn · 2026-08-10 · 6 trả lời

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ì ạ?

******************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 ạ?

Thảo luận & Trả lời (6)

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 · 2026-08-10

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.

🎅❤️🍀

Đầ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 · 2026-08-10

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 · 2026-08-11

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/ 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/ 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ỗ

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/ "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/ 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/ 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/ 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/ Để 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/ 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/ "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/ "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/ em nêu "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

Thư Nguyễn · 2026-08-15

Chào anh Toàn và mọi người,

Em đã tổng hợp toàn bộ giải pháp thành cẩm nang tra cứu và mô phỏng trực quan. Bên cạnh các kinh nghiệm vận hành thực tế rất hay của các anh, em có bổ sung thêm phần tài liệu học thuậtcủa môn Integrated Logistics (MSc in UK) liên quan đến các vấn đề đang được thảo luận (như cách tính Safety Stock theo độ biến động, chu kỳ đồng bộ Cross-docking và ước lượng tuyến VRP), mong sẽ cung cấp thêm ý tưởng và cơ sở định lượng để anh Toàn tham khảo.

Mời anh Toàn và mọi người xem qua link: https://fmcg-solutions.netlify.app/

Nội dung chính trong file:

  • Hệ thống 8 Tabs chi tiết: Nội dung thảo luận bên trên, tóm tắt giải pháp (Summary), bảng tra cứu thuật ngữ & chỉ số (kèm công thức và ví dụ), các chuyên đề về Tồn kho ABC-XYZ, Cross-Docking và Tối ưu tuyến 3 tầng.

  • Bộ công cụ mô phỏng Live (Simulators): Giả lập thuật toán chia hàng khi thiếu (Fair-Share by DOS) và mô phỏng gom cụm định tuyến xe (VRP Engine) trực quan.

Em cảm ơn mọi người đã chia sẻ và cho em học hỏi thực tế.

Best regards,

Thư (Thu.minh090997@gmail.com)

💬 Tham gia thảo luận cùng cộng đồng

Chủ đề này có 6 câu trả lời, chia sẻ thực chiến và tài liệu đính kèm từ các chuyên gia chuỗi cung ứng.