Phần mềm tối ưu tuyến giao hàng nhiều điểm cho doanh nghiệp

Điều phối xếp điểm theo độ gần rồi có một tuyến nhìn khá gọn. Nhưng cửa hàng đầu chỉ nhận sau giữa buổi, điểm tiếp theo cần xe có thiết bị phù hợp, còn dỡ hàng ở điểm thứ ba lâu hơn kế hoạch cho phép. Phần mềm tối ưu tuyến giao hàng nhiều điểm hữu ích khi đưa các điều kiện đó ra trước lúc xe rời kho.

Đường ngắn nhất chỉ là một mục tiêu có thể chọn. Doanh nghiệp thường cần kế hoạch khả thi trước, giảm đơn chưa phân sau, rồi mới cân đối thời gian chạy và số xe. Bài này giải thích cách đánh giá năng lực lập tuyến dựa trên đầu vào và đầu ra VRP được TrackAsia tài liệu hóa, đồng thời giữ nhận đơn, duyệt kế hoạch và giao việc cho tài xế ở đúng phần mềm bao quanh.[6]

Mô tả ngày giao trước khi yêu cầu tối ưu

Bắt đầu bằng câu hỏi thực: có những việc gì, xe nào sẵn sàng và điều kiện nào phải đáp ứng? Bộ giải không tự suy ra giờ nhận của khách từ tên đường, cũng không biết thời gian dỡ hàng chỉ qua số điểm. Thiếu điều kiện nghĩa là máy đang giải một bài khác với bài điều phối nghĩ mình gửi đi.

Giả sử một kho có các đơn giao cửa hàng, hai xe và một yêu cầu lấy hàng. Phần lớn khách nhận trong ca, một khách có khung giờ hẹp. Đây là tình huống đề xuất để thử, không phải triển khai đã xảy ra hay số liệu tiết kiệm đã đạt. Nó giúp lộ các quyết định dễ bị bỏ qua trong một bản trình diễn ngắn.

Yêu cầu lấy hàng cần được hiểu kỹ. Nếu hàng lấy phải được giao tới nơi khác trong cùng hành trình, quan hệ đó khác hai lượt ghé độc lập. Nếu chỉ mang về kho, mô hình khác có thể đủ. Thống nhất vật gì thực sự di chuyển trước khi chọn trường trong yêu cầu.

Chốt cả khoảng lập kế hoạch. Một chuyến sáng, cả ngày và lịch nhiều ngày không thay thế nhau. Đợt thử đầu nên đủ nhỏ để người vận hành kiểm tra hết, biết rõ điểm xuất phát và giới hạn ca. Dễ tìm giả định sai trong một ngày của một kho hơn trong kế hoạch toàn mạng trông rất ấn tượng.

Chuyển điều kiện vận hành thành dữ liệu

VRP v1 của TrackAsia mô tả jobs, shipments và vehicles. Jobs là công việc; shipments liên kết bước lấy và giao. Mô hình có thời gian phục vụ, khung giờ, sức chứa, điều kiện phù hợp và mức ưu tiên. Mảng tọa độ theo kinh độ,vĩ độ, thời gian tính bằng giây và khoảng cách bằng mét.[6] Ghi các quy ước này vào đặc tả nhập dữ liệu, đừng để mỗi người giữ bảng tính tự hiểu.

Dùng mã số nguyên duy nhất cho công việc API và giữ bảng ánh xạ về mã đơn. Kết quả trả một mã phải dẫn lại đúng việc kinh doanh. Không lấy số dòng bảng tính nếu sắp xếp hoặc lọc có thể làm mã đó thay đổi giữa lúc tính và đối soát.

Xác nhận địa điểm trước khi giải. Tâm tòa nhà có thể không đại diện tốt cho cổng dỡ hàng. Giữ trạng thái cho điểm chưa rõ hoặc chưa kiểm tra và quyết định tạm loại chờ sửa hay xử lý riêng. Bỏ đơn thiếu tọa độ khỏi đầu vào mà không báo điều phối sẽ tạo kế hoạch có vẻ thành công nhưng thiếu việc.

Tài liệu cho phép mảng sức chứa nhiều chiều, chẳng hạn số kiện và khối lượng.[6] Mọi bên phải dùng cùng thứ tự và đơn vị. Sức chứa [100, 500] chưa có ý nghĩa nếu chưa biết từng số đại diện điều gì. Không mong bộ giải tự đoán kg, thùng hay thể tích.

Thời gian phục vụ cần phản ánh thao tác tại điểm. Đặt mọi điểm bằng không có thể giúp tuyến qua được kiểm tra giờ nhưng không còn thời gian dỡ hàng hay lấy xác nhận. Bắt đầu bằng ước tính có cơ sở theo loại điểm, rồi cải thiện bằng quan sát. Khi chưa đo, gọi đúng đó là giả định.

Một đầu vào nhỏ làm rõ cách mô hình hóa

JSON sau là nội dung bài toán minh họa dùng trường trong tài liệu. Nó lấy mốc thời gian tương đối: số không là đầu khoảng lập kế hoạch, không mặc định là nửa đêm hoặc dấu thời gian Unix. Đây là ví dụ cấu trúc, không bảo đảm phương án cụ thể cho một ngày hoạt động. TrackAsia mô tả endpoint VRP là /api/v1/vrp; khi tích hợp cần xác nhận cách gửi hiện hành và cấu hình tài khoản.[6]

{
  "jobs": [
    {"id": 101, "location": [106.70, 10.78], "service": 600,
     "delivery": [8], "time_windows": [[1800, 10800]]},
    {"id": 102, "location": [106.72, 10.80], "service": 900,
     "delivery": [12], "time_windows": [[0, 14400]], "skills": [1]}
  ],
  "vehicles": [
    {"id": 1, "profile": "car", "start": [106.68, 10.76],
     "end": [106.68, 10.76], "capacity": [25], "skills": [1],
     "time_window": [0, 14400]}
  ]
}

Chiều số lượng trong ví dụ được quy ước là thùng. Việc đầu không được bắt đầu phục vụ trước giây 1.800; việc thứ hai cần nhãn phù hợp số 1 mà xe có. Các mã skills là nhãn do ứng dụng định nghĩa, không tự chứng minh xe đủ điều kiện pháp lý trên đường hoặc tài xế có chứng chỉ nghề.

Quay về kho được mô tả rõ bằng start và end giống nhau. Tài liệu giải thích bỏ end cho phép kết thúc ở công việc cuối.[6] Lựa chọn này ảnh hưởng chi phí kế hoạch. So một tuyến phải quay kho với tuyến dừng ngoài đường rồi gọi phần chênh là tiết kiệm sẽ gây hiểu sai.

Điều gì bắt buộc, điều gì có thể thương lượng?

Giờ nhận có thể là điều kiện cứng hoặc mong muốn khách sẵn sàng đổi. Sức chứa là giới hạn vật lý, còn thói quen giữ địa bàn quen có thể thương lượng. Không nên biến mọi thói quen thành ràng buộc tuyệt đối khi chưa xem tác động đến khả năng phân việc.

TrackAsia mô tả khung giờ bắt đầu phục vụ, giờ làm xe, điều kiện qua skills và ưu tiên công việc.[6] Ưu tiên ảnh hưởng xu hướng chọn việc khi không thể làm hết; không nên trình bày thành bảo đảm rằng việc ưu tiên cao luôn khả thi.

Ý nghĩa khung giờ cần được thống nhất. Nếu ràng buộc tài liệu là lúc bắt đầu phục vụ, doanh nghiệp yêu cầu dỡ xong trước giờ đóng cửa phải mô hình hóa hoặc kiểm tra thêm điều đó. Đề nghị đội tích hợp trình bày trường hợp sát biên thay vì mặc định hai cách hiểu giống nhau.

Tương tự, nhãn thiết bị có thể giới hạn xe nào được nhận việc, nhưng không làm đường đi tự phù hợp mọi kích thước xe và quy định. Giữ khả năng phục vụ của xe, định tuyến đường và tiếp cận cơ sở thành các kiểm tra liên quan nhưng riêng biệt. Xác nhận hỗ trợ ràng buộc cần dùng thay vì suy từ tên trường.

Thử với mã nguồn: Xếp thứ tự điểm giao có khung giờ

Chạy sáu hoán vị cho ba điểm có khung giờ; thay giờ xuất phát để kiểm tra tính khả thi.

Dữ liệu và giả định minh họa; không phải giao diện sản phẩm, số liệu khách hàng hay báo giá TrackAsia.

Giải nén ZIP, chạy python3 -m http.server 8080 trong thư mục vừa giải nén, rồi mở http://localhost:8080/index-vi.html. README tiếng Việt và tiếng Anh nằm trong ZIP; không cần npm hay bước build.

Tải ZIP mã nguồn đầy đủ

Xếp thứ tự điểm giao có khung giờ
Bấm ảnh để mở kích thước đầy đủ.

Đọc việc chưa được phân trước khi mừng tuyến đẹp

Đầu ra VRP có mã trạng thái, tóm tắt, routes và unassigned. Tài liệu tách thời gian chạy, phục vụ, chuẩn bị và chờ.[6] Phần mềm nên giữ các ý nghĩa đó thay vì gộp thành một con số hấp dẫn mang tên tổng thời gian.

Mọi việc đầu vào cần được giải trình: đã giao cho xe, chưa phân hoặc bị loại trước khi giải với lý do nhìn thấy được. Đối chiếu mã bằng chương trình. Một yêu cầu thành công nhưng còn việc chưa phân có thể là câu trả lời hữu ích vì lộ thiếu xe hoặc điều kiện xung đột; nó chưa phải kế hoạch điều phối hoàn chỉnh.

Không tự tạo lời giải thích chính xác từ đầu ra chỉ liệt kê mã việc chưa phân. Ứng dụng có thể hướng dẫn kiểm tra vị trí, tải, skills và giờ, nhưng phải phân biệt nguyên nhân xác nhận với phỏng đoán. Người vận hành có thể cần nới điều kiện, thêm xe hoặc gọi khách.

Kiểm tra kế hoạch đã chọn độc lập theo quy tắc quan trọng: số lượng, giờ bắt đầu phục vụ, điều kiện phù hợp và điểm cuối ca. Điều này giúp phát hiện lỗi ánh xạ dữ liệu và yêu cầu nằm ngoài mô hình. Điều phối cũng có cách giải thích rõ vì sao phương án dùng được.

Bộ giải là một thành phần của phần mềm giao hàng

API tính phương án từ mô tả bài toán. Phần mềm bao quanh nhận đơn, kiểm tra dữ liệu, phân quyền, hiện ngoại lệ, duyệt phiên bản, chuyển việc và ghi thực hiện. Những trách nhiệm này vẫn tồn tại khi mua tối ưu dưới dạng dịch vụ.

Một kiến trúc vừa đủ có bốn ranh giới: nhận đơn, chuẩn bị dữ liệu lập kế hoạch, tối ưu và thực thi. Giữ hồ sơ đơn gốc ngoài yêu cầu bộ giải. Lưu phiên bản đầu vào cùng đầu ra để điều phối xem lại điều kiện nào tạo kế hoạch. Chỉ gửi cho tài xế phiên bản đã được xem xét.

TrackAsia giới thiệu TMS riêng với lập kế hoạch, quản lý đơn và tài xế, theo dõi, báo cáo và tích hợp.[7] Đánh giá sản phẩm đó nếu thiếu cả quy trình vận hành. Nếu hệ thống hiện có đã sở hữu các phần này, API VRP có thể là thành phần tập trung cho lập tuyến. So cả công triển khai và trách nhiệm duy trì của hai hướng.

Bản đồ vẫn hữu ích để xem kế hoạch, nhưng cần kèm danh sách việc và ngoại lệ. Đường vẽ không nói một đơn đã bị bỏ, đơn vị thùng bị hiểu sai hay giờ khách bị áp sai múi giờ. Góc nhìn dữ liệu và địa lý cần giải thích cùng phiên bản đã duyệt.

Đơn đến giữa ca cần quy tắc thay đổi

Đơn mới lúc trưa không nên âm thầm đảo hết việc còn lại của mọi tài xế. Có việc đã xong, đang làm và đã hẹn với khách. Chốt phần được thay đổi và người duyệt trước khi triển khai tối ưu lặp lại.

Lập lại cần mô tả cập nhật về xe sẵn có và công việc còn lại. Việc xong không được gửi như việc chưa ghé. Vị trí xe hiện tại và tải đang có có thể quan trọng, nhưng cần dữ liệu đáng tin. Không giả vờ điểm xuất phát ở kho buổi sáng vẫn mô tả xe đang ngoài đường.

Tài liệu VRP bàn về vehicle steps với cách dùng trong chế độ lập và giải.[6] Không mặc định gửi một thứ tự ban đầu nghĩa là đóng băng chính xác thứ tự đó. Kiểm tra ý nghĩa của tích hợp đã chọn và áp dụng riêng quy tắc phát hành trong ứng dụng.

Khi duyệt thay đổi, ghi phiên bản mới, công việc bị tác động và cách xác nhận đã nhận. Tài xế cần biết chỉ dẫn cũ đã bị thay chưa. Nếu thiết bị mất kết nối, hệ thống cần đường đối soát thay vì coi API thành công là lệnh mới đã tới người thực hiện.

So sánh trên cùng công việc và điều kiện

Chạy lại một ngày đã ẩn thông tin cá nhân với cùng việc, điểm đầu/cuối, thời gian phục vụ và khung giờ cho phương án cũ và mới. Tách sửa dữ liệu nguồn khỏi hiệu quả tối ưu. Nếu kế hoạch mới dùng tọa độ tốt hơn, mô tả đúng cải thiện đó thay vì gán tất cả cho bộ giải.

Có thể đo tỷ lệ việc được phân, thời gian chạy, chờ, phục vụ, số xe, lần sửa tay và công lập kế hoạch. Khi thực hiện thật, bổ sung hoàn tất và ngoại lệ chưa giải quyết. Đây là gợi ý đánh giá, không phải số liệu thành tích TrackAsia.

Dùng nhóm chi phí hợp hoạt động. Chỉ nhìn km dễ bỏ qua khả dụng xe, công tài xế, mức tối thiểu nhà thầu và giao thất bại. Ngược lại, cost nội bộ của tối ưu không tự thành hóa đơn tiền; tài liệu nêu giá trị cost thuộc mục tiêu tối ưu.[6] Giải thích cách phân tích thương mại ánh xạ vào đó trước khi trình bày kết quả bằng tiền.

Bước tiếp theo đáng làm là một thử nghiệm dữ liệu nhỏ có cả việc cố ý không khả thi. Yêu cầu TrackAsia hoặc đội tích hợp cho xem ánh xạ đầu vào, kết quả chưa phân, quyết định người vận hành và kế hoạch phát hành. Chọn phần mềm giúp một ngày có thể thực hiện trở nên dễ hiểu hơn, không chỉ làm đường trên hình ngắn hơn.

Tài liệu chính thức

Trao đổi với TrackAsia