Delivery plan generation device and delivery plan generation method
The delivery plan generation device and method equalize workload among delivery personnel by dividing areas into unit zones, optimizing routes, and considering personnel skills, addressing inefficiencies in existing methods and reducing execution time.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- PANASONIC INTELLECTUAL PROPERTY MANAGEMENT CO LTD
- Filing Date
- 2022-04-15
- Publication Date
- 2026-07-03
AI Technical Summary
Existing delivery plan generation methods fail to equalize the workload among delivery personnel, leading to imbalances and do not consider factors like schedule, skills, and past work performance, resulting in inefficiencies and increased overall execution time.
A delivery plan generation device and method that divides the delivery area into unit areas, generates routes for multiple personnel, and performs leveling processes to equalize deliveries, considering factors such as delivery destinations, road costs, and personnel skills, with a user interface for inputting settings and displaying results.
The system effectively generates delivery plans that balance workload among delivery personnel while minimizing overall execution time, reducing delivery costs, and optimizing routes based on historical data and road conditions.
Smart Images

Figure 0007884205000001 
Figure 0007884205000002 
Figure 0007884205000003
Abstract
Description
Technical Field
[0001] The present disclosure relates to a delivery plan generation device and a delivery plan generation method for supporting the delivery of a plurality of packages to be delivered.
Background Art
[0002] As a prior art for making a delivery plan for products, for example, Patent Document 1 can be cited. In Patent Document 1, a method of generating an optimal delivery route is disclosed by dividing a delivery area into meshes using a mesh method and connecting the meshes in one stroke using the shortest distance condition.
Prior Art Documents
Patent Documents
[0003]
Patent Document 1
Summary of the Invention
Problems to be Solved by the Invention
[0004] In view of the above-described conventional situation, the present disclosure devises a delivery plan generation device and a delivery plan generation method that generate a delivery plan for suppressing the bias in the workload of delivery personnel while suppressing the overall execution time of delivery by equalizing the delivery routes of packages among delivery personnel.
Means for Solving the Problems
[0005] The present disclosure is a delivery plan generation device that causes a processor to execute a process of dividing a delivery area into predetermined unit areas and generating delivery routes for each of a plurality of personnel to whom delivery destinations of articles are assigned. The processor performs generation of delivery routes for each of the plurality of personnel identified by connecting unit areas including one or more delivery destinations, and equalization processing for equalizing deliveries included in the delivery routes for each of the plurality of personnel. When performing the repeated delivery plan generation process A setting screen for allowing a user to input setting items used for this, and The system provides a result screen for the delivery plan generation process, where the user inputs the setting items, including the delivery leveling target, the allowable difference for the leveling target, and the maximum calculation time for the delivery plan generation process. If the delivery plan generation process is completed within the maximum calculation time, the system provides a result screen indicating the successful completion of the delivery plan generation process based on the setting items. If the time required for the delivery plan generation process exceeds the maximum calculation time, the system provides a result screen indicating the intermediate solution at that point.We provide a delivery plan generation device.
[0006] Furthermore, this disclosure relates to a delivery plan generation method that divides the delivery area into predetermined unit areas and generates delivery routes for each of the multiple personnel to whom the delivery destinations of goods are assigned, wherein the processor and memory cooperate to generate delivery routes for each of the multiple personnel identified by connecting unit areas containing one or more delivery destinations, and to perform a leveling process that equalizes the deliveries included in each of the multiple personnel's delivery routes. When performing the repeated delivery plan generation process A settings screen that allows the user to input the settings used, and The system provides a result screen for the delivery plan generation process, where the user inputs the setting items, including the delivery leveling target, the allowable difference for the leveling target, and the maximum calculation time for the delivery plan generation process. If the delivery plan generation process is completed within the maximum calculation time, the system provides a result screen indicating the successful completion of the delivery plan generation process based on the setting items. If the time required for the delivery plan generation process exceeds the maximum calculation time, the system provides a result screen indicating the intermediate solution at that point. It provides a method for generating delivery plans. [Effects of the Invention]
[0007] According to this disclosure, the user set Based on the distribution target for leveling, the tolerance for the difference in the distribution target, and the maximum computation time for the distribution plan generation process, This process involves generating delivery routes for multiple delivery personnel, each identified by connecting unit areas containing one or more delivery destinations, and then performing a leveling process to equalize the deliveries included in each of those delivery routes. The delivery plan generation process is executed repeatedly, While taking into account the processing time of the load-intensive leveling process, With the desired accuracy and tolerance, This makes it possible to generate delivery plans that suppress imbalances in the workload of delivery personnel. [Brief explanation of the drawing]
[0008] [Figure 1] Block diagram showing an example of a system configuration according to Embodiment 1 of the present invention. [Figure 2] Conceptual diagram illustrating the mesh according to Embodiment 1 of the present invention. [Figure 3] Conceptual diagram illustrating the aggregation of delivery plans according to Embodiment 1 of the present invention. [Figure 4] An explanatory diagram illustrating the delivery planning method according to Embodiment 1 of the present invention. [Figure 5] An explanatory diagram illustrating the delivery planning method according to Embodiment 1 of the present invention. [Figure 6] An explanatory diagram illustrating the delivery planning method according to Embodiment 1 of the present invention. [Figure 7]Flowchart of delivery plan generation process according to Embodiment 1 of the present invention [Figure 8] Flowchart of delivery plan calculation process according to Embodiment 1 of the present invention [Figure 9] Diagram showing a configuration example of the UI screen of the delivery plan generation device according to Embodiment 1 of the present invention [Figure 10] Diagram showing a configuration example of the UI screen of the delivery plan generation device according to Embodiment 1 of the present invention [Figure 11] Diagram showing a configuration example of the UI screen of the delivery plan generation device according to Embodiment 1 of the present invention [Figure 12] Diagram showing an example of the data configuration used in the delivery plan generation device according to Embodiment 1 of the present invention [Figure 13] Diagram showing a configuration example of the UI screen of the delivery plan generation device according to Embodiment 1 of the present invention [Figure 14] Diagram showing a configuration example of the UI screen of the delivery plan generation device according to Embodiment 1 of the present invention [Figure 15] Diagram showing a configuration example of the UI screen of the delivery plan generation device according to Embodiment 1 of the present invention [Figure 16] Diagram showing a configuration example of the UI screen of the delivery plan generation device according to Embodiment 1 of the present invention [Figure 17] Diagram showing a configuration example of the UI screen of the delivery plan generation device according to Embodiment 1 of the present invention
Embodiments for Carrying Out the Invention
[0009] (The process leading to the content of each embodiment) In the above-mentioned Patent Document 1, by automatically determining the delivery route for a unit area using the mesh method and determining the vehicle type and number of necessary delivery vehicles, etc., reduction of delivery costs and improvement of delivery efficiency are achieved. However, among multiple delivery staff, there is a bias in their workload, and even leveling of the workload is not considered. In the actual field, the delivery of a huge amount of goods is shared by multiple delivery staff (drivers), and only the optimal delivery route within a predetermined delivery range cannot equalize the determination of the delivery route for each driver and the number of delivery items for each driver. In particular, since the number of delivery destinations included within a mesh unit area varies depending on the situation, the accuracy of leveling decreases. Also, in Patent Document 1, convenience such as a UI screen that can be used when each delivery staff actually performs delivery is not considered.
[0010] Also, planning the delivery considering the schedule, skills, past work performance, etc. of each delivery staff was not considered. Therefore, it is possible to calculate the delivery route at a certain point, but Patent Document 1 could not achieve the work sharing that reflects past work performance, etc.
[0011] Therefore, in the following embodiments, an example of a delivery plan generation device and a delivery plan generation method that can generate a delivery plan that equalizes the work of delivery staff, suppresses the bias of the work load of delivery staff while suppressing the overall execution time of delivery will be described.
[0012] Hereinafter, each embodiment specifically disclosing the delivery plan generation device and the delivery plan generation method according to the present disclosure will be described in detail with reference to the drawings as appropriate. However, detailed descriptions more than necessary may be omitted. For example, detailed descriptions of well-known matters and duplicate descriptions for substantially the same configuration may be omitted. This is to avoid making the following description unnecessarily redundant and to facilitate the understanding of those skilled in the art. Note that the attached drawings and the following description are provided for those skilled in the art to fully understand the present disclosure, and it is not intended to limit the subject matter described in the claims by these.
[0013] <Embodiment 1> The following describes an example of formulating (generating) a delivery plan when delivering multiple packages, as Embodiment 1 of the present invention. In this embodiment, the delivery plan is a plan of the delivery route when delivering packages (goods) from a base to multiple destinations using at least one delivery vehicle (e.g., a truck) within a predetermined period (e.g., one day). The delivery route corresponds to the order in which the vehicle travels to the multiple destinations. When generating the delivery plan, it is determined, for example, based on road costs, in order to reduce the delivery cost.
[0014] [Device configuration] The delivery plan generation device 100 according to this embodiment is connected to one or more client terminals 200 via a network 300 so as to be able to communicate with them. The delivery plan generation device 100 may be configured as an on-premise server device at the delivery company's base, or it may be configured as a cloud-based device on the network.
[0015] The delivery plan generation device 100 is composed of a processing unit 110, a storage unit 120, a UI (User Interface) unit 130, and a communication unit 140. The processing unit 110 may be a processor configured using, for example, a CPU (Central Processing Unit), a GPU (Graphical Processing Unit), an MPU (Micro Processing Unit), a DSP (Digital Signal Processor), or an FPGA (Field-Programmable Gate Array). The processing unit 110 realizes various functions described later by, for example, referring to various databases (hereinafter referred to as DB) stored in the storage unit 120 or reading programs. The storage unit 120 is a storage unit for storing various data and programs, and may be composed of volatile / non-volatile storage devices such as RAM (Random Access Memory), ROM (Read Only Memory), or HDD (Hard Disk Drive).
[0016] The UI unit 130 is the part that receives operations from the user of the delivery plan generation device 100 and outputs various information. The UI unit 130 may consist of a display, mouse, keyboard, etc. The communication unit 140 is an interface for communicating with external devices via the network 300. The communication standards that the communication unit 140 can support are not particularly limited and can be wired or wireless. It may also support multiple communication standards.
[0017] The client terminal 200 is a terminal device that can be used by delivery personnel during delivery work, and may be a mobile terminal such as a smartphone, tablet, or POS terminal. The client terminal 200 may also be installed in a delivery vehicle (hereinafter simply referred to as "vehicle") used during delivery. The client terminal 200 is composed of a processing unit 201, a storage unit 202, a communication unit 203, a UI unit 204, and a sensor unit 205.
[0018] The processing unit 201 may be configured using, for example, a CPU, GPU, MPU, DSP, or FPGA. The processing unit 201 implements various functions described later by, for example, referring to various data stored in the memory unit 202 or reading programs. The memory unit 202 is a memory unit for storing various data and programs, and may be composed of, for example, a volatile / non-volatile storage device such as RAM, ROM, HDD, flash memory, or SSD (Solid State Drive).
[0019] The communication unit 203 is an interface for wireless communication with external devices via the network 300. The communication standards that the communication unit 203 can support are not particularly limited. The sensor unit 205 consists of one or more sensors for detecting status information of the client terminal 200, and may include, for example, a position sensor using GNSS (Global Navigation Satellite System) such as GPS (Global Positioning System), a magnetic sensor, an acceleration sensor, and a camera as an imaging device.
[0020] In this embodiment, the processing unit 110 of the delivery plan generation device 100 implements a road cost calculation unit 111, a delivery cost generation unit 112, a delivery plan calculation unit 113, a screen generation unit 114, a DB management unit 115, and a data linkage unit 116. Note that the configuration of the functional blocks is just an example, and the functions of one block may be further subdivided, or the functions of multiple blocks may be combined into a single configuration.
[0021] The road cost calculation unit 111 calculates the cost of roads used as delivery routes. The delivery cost generation unit 112 calculates delivery costs based on road costs and the size of the packages to be delivered. The delivery plan calculation unit 113 calculates a delivery plan for the packages based on delivery costs and road costs. The screen generation unit 114 generates various UI screens to be provided to the delivery plan generation device 100 and client terminals 200. The DB management unit 115 updates and manages various DBs configured in the storage unit 120. The data linkage unit 116 acquires and provides various information necessary for delivery planning from external devices (client terminals 200 and other external devices).
[0022] In this embodiment, the storage unit 120 of the delivery plan generation device 100 includes a road information DB 121, a delivery information DB 122, and a person in charge information DB 123. Note that the DB configuration is just an example, and one DB may be further subdivided, or multiple DBs may be combined to form a single database.
[0023] The Road Information DB121 is a database for managing road and map information for the delivery area. Road and map information may be updated by, for example, accessing an external map server (not shown) to obtain the latest information. Road information may include not only the shape of the road, but also information on traffic congestion, passability, and past travel history. Based on this information, the cost of each road is defined. The Delivery Information DB122 is a database for managing delivery information for the goods to be delivered. Delivery information may include the delivery destination, origin, delivery base, and delivery date and time. The Personnel Information DB123 is a database for managing information on delivery personnel. Personnel information may include assigned deliveries, the person's delivery history, work schedule, current location during delivery, and the person's delivery skills.
[0024] When using the delivery plan generation device 100 from the client terminal 200, the client terminal 200 may access the delivery plan generation device 100 using its built-in web browser (not shown), or it may be used by launching an application compatible with the delivery plan generation device 100 that is installed on the client terminal 200. Furthermore, the division of functions between the delivery plan generation device 100 and the client terminal 200 is not limited to the configuration shown in Figure 1; a configuration in which the client terminal 200 performs some of the functions of the delivery plan generation device 100 is also possible.
[0025] [Aggregation using mesh] Figure 2 is a diagram illustrating the mesh-based aggregation according to this embodiment. The mesh 210 in Figure 2(a) shows the state before aggregation, and the mesh in Figure 2(b) shows the state after aggregation. Here, an example of a 6x6 mesh (36 unit areas in total) set on the map is shown. Note that the vertical and horizontal size of one unit area of the mesh is not particularly limited, and any rectangular values may be set. In Figure 2, one circle represents one delivery destination. In Figure 2(a), unit area 211 contains three delivery destinations. Unit area 212 contains two delivery destinations. Aggregation is performed when a unit area contains multiple delivery destinations, by grouping the delivery destinations together for each unit area. For example, unit area 211 in Figure 2(a) becomes unit area 221 in Figure 2(b) by aggregating the three delivery destinations. In Figure 2, aggregated delivery destinations are shown as rectangles. Similarly, unit area 212 in Figure 2(a) becomes unit area 222 in Figure 2(b) by consolidating two delivery destinations. This simplifies the handling during route generation and reduces the processing load.
[0026] Figure 3 shows an example of mesh and route generation according to this embodiment. Similar to Figure 2, it shows an example of a 6x6 mesh set on the map. Figure 3(a) shows the state before aggregation. In Figure 3, the locations indicated by black triangles represent delivery hubs (hereinafter also simply referred to as "hubs"). In addition, multiple delivery destinations are indicated by circles around them. Here, they are classified into three types of circles (solid lines, thick lines, and dashed lines), and an example is shown where there are 6 solid lines, 5 thick lines, and 5 dashed lines. These three types of circles indicate the division of labor (assignment) for each of the three delivery personnel.
[0027] Figure 3(b) shows an example where the mesh in Figure 3(a) is adjusted to a 2x2 unit area. In this case, the mesh becomes 3x3. In Figure 3(b), the number of delivery destinations belonging to each 2x2 unit area is shown.
[0028] Figure 3(c) shows the state in Figure 3(b) after the delivery destinations have been consolidated into a 2x2 unit area. The consolidated state is indicated by a white triangle. The map position at this point of consolidation may be the center of each delivery destination or the center of the unit area. Furthermore, in Figure 3(c), the delivery route from the delivery base to the consolidated location is indicated by arrows. Here, the return route from the last delivery destination to the delivery base is omitted.
[0029] Figure 3(d) shows the state as in Figure 3(a), where delivery destinations are aggregated into 1x1 unit areas within a 6x6 mesh, and the delivery routes to the aggregated locations are indicated by arrows, starting from the delivery hub. Here, the return route from the last delivery destination to the delivery hub is omitted.
[0030] [Delivery Plan] In this embodiment, an initial solution for the delivery plan is derived, and then three types of improvement methods and delivery cost optimization are applied to this initial solution to determine a more appropriate delivery plan. Delivery cost optimization can be reduced by, for example, changing the route between two delivery destinations. More specifically, since the cost (road cost) differs for each road, the delivery cost differs depending on which road is taken when traveling from one delivery destination to another. Which road to take may be determined, for example, by performing machine learning based on the driving history of an experienced driver, or it may be determined by the known Dijkstra's algorithm based on pre-set road costs.
[0031] Furthermore, as methods for improving the delivery plan according to this embodiment, "substitution," "exchange," and "transfer" will be explained as examples. Substitution is the process of changing the order of delivery destinations. Exchange is the process of changing delivery destinations among multiple delivery routes. Transfer is the process of moving a delivery destination to a different delivery route. Based on the explanatory diagram in Figure 4, specific examples of substitution, exchange, and transfer will be explained below. Note that if there are two routes from each delivery destination, the route with the higher cost is represented by a dotted line, and the route with the lower cost is represented by a solid line.
[0032] (replacement) In Pattern 1, a delivery plan is set up in which one delivery vehicle delivers in the order of base S → delivery destination D1 → delivery destination D2 → delivery destination D3 → delivery destination D4. In this case, the delivery cost (in other words, distance) is "10 + 10 + 10 = 30".
[0033] On the other hand, in Pattern 1, a replacement delivery plan is set up in which one delivery vehicle delivers in the order of base S → destination D1 → destination D3 → destination D2 → destination D4. In this case, the delivery cost is "15 + 10 + 15 = 40". Therefore, the delivery cost is higher than before the replacement, and this is not adopted as a solution for the delivery plan.
[0034] In Pattern 2, a delivery plan is set up in which one delivery vehicle delivers in the order of base S → destination D1 → destination D2 → destination D3 → destination D4. In this case, the delivery cost is "10 + 10 + 10 = 30".
[0035] On the other hand, in Pattern 2, a delivery plan is set up in which a single delivery vehicle delivers in the order of base S → destination D1 → destination D3 → destination D2 → destination D4. In this case, the delivery cost is "5 + 10 + 5 = 20". Therefore, the delivery cost can be reduced and this is adopted as the solution for the delivery plan.
[0036] (exchange) In Pattern 3, a delivery plan is set for the first delivery vehicle, in the order of base S → destination D1 → destination D2 → destination D3 → destination D4. A delivery plan is also set for the second delivery vehicle, in the order of base S → destination D5 → destination D6 → destination D7 → destination D8. In this delivery plan, the delivery cost for the first delivery vehicle is "10 + 10 + 0 = 20", and the delivery cost for the second delivery vehicle is "10 + 10 + 0 = 20". The sum of the delivery costs for the two delivery vehicles is "20 + 20 = 40".
[0037] On the other hand, in Pattern 3, a delivery plan is set for the first delivery vehicle, in the order of base S → destination D1 → destination D6 → destination D3 → destination D4. Also, a delivery plan is set for the second delivery vehicle, in the order of base S → destination D5 → destination D2 → destination D7 → destination D8. In this delivery plan, the delivery cost for the first delivery vehicle is "15 + 10 + 0 = 25", and the delivery cost for the second delivery vehicle is "10 + 10 + 0 = 20". At this time, the sum of the delivery costs for the two delivery vehicles is "20 + 25 = 45". Therefore, the delivery cost is higher than before the exchange, and this is not adopted as a solution for the delivery plan.
[0038] In Pattern 4, a delivery plan is set for the first delivery vehicle, in the order of base S → destination D1 → destination D2 → destination D3 → destination D4. A delivery plan is also set for the second delivery vehicle, in the order of base S → destination D5 → destination D6 → destination D7 → destination D8. In this delivery plan, the delivery cost for the first delivery vehicle is "10 + 10 + 0 = 20", and the delivery cost for the second delivery vehicle is "10 + 10 + 0 = 20". The sum of the delivery costs for the two delivery vehicles is "20 + 20 = 40".
[0039] On the other hand, in Pattern 4, a delivery plan is set for the first delivery vehicle, in the order of base S → destination D1 → destination D6 → destination D3 → destination D4. Also, a delivery plan is set for the second delivery vehicle, in the order of base S → destination D5 → destination D2 → destination D7 → destination D8. In this delivery plan, the delivery cost for the first delivery vehicle is "5 + 10 + 0 = 15", and the delivery cost for the second delivery vehicle is "10 + 10 + 0 = 20". At this time, the sum of the delivery costs for the two delivery vehicles is "15 + 20 = 35". Therefore, the delivery cost can be reduced, and this is adopted as the solution for the delivery plan.
[0040] (Transfer) In Pattern 5, a delivery plan is set for the first delivery vehicle, with the delivery order being base S → destination D1 → destination D2 → destination D3 → destination D4. A delivery plan is also set for the second delivery vehicle, with the delivery order being base S → destination D5 → destination D6 → destination D7 → destination D8. In this Pattern 5, the delivery cost for the first delivery vehicle is "10 + 10 + 0 = 20", and the delivery cost for the second delivery vehicle is "10 + 10 + 0 = 20". The sum of the delivery costs for the two delivery vehicles is "20 + 20 = 40".
[0041] On the other hand, in Pattern 5, a delivery plan is set for the first delivery vehicle, with deliveries made in the order of base S → destination D1 → destination D3 → destination D4. A delivery plan is also set for the second delivery vehicle, with deliveries made in the order of base S → destination D5 → destination D6 → destination D2 → destination D7 → destination D8. In this Pattern 5, the delivery cost for the first delivery vehicle is "25 + 0 = 25", and the delivery cost for the second delivery vehicle is "10 + 10 + 10 + 0 = 30". The sum of the delivery costs for the two delivery vehicles is "25 + 30 = 55". Therefore, the delivery cost is higher than before the transfer, and this solution is not adopted for the delivery plan.
[0042] In Pattern 6, a delivery plan is set for the first delivery vehicle, in the order of base S → destination D1 → destination D2 → destination D3 → destination D4. A delivery plan is also set for the second delivery vehicle, in the order of base S → destination D5 → destination D6 → destination D7 → destination D8. In this Pattern 6, the delivery cost for the first delivery vehicle is "10 + 10 + 0 = 20", and the delivery cost for the second delivery vehicle is "10 + 10 + 0 = 20". The sum of the delivery costs for the two delivery vehicles is "20 + 20 = 40".
[0043] On the other hand, in Pattern 6, a delivery plan is set for the first delivery vehicle, with delivery in the order of base S → destination D1 → destination D3 → destination D4. Also, a delivery plan is set for the second delivery vehicle, with delivery in the order of base S → destination D5 → destination D6 → destination D2 → destination D7 → destination D8. In this Pattern 6, the delivery cost for the first delivery vehicle is "5 + 0 = 5", and the delivery cost for the second delivery vehicle is "10 + 10 + 10 + 0 = 30". At this time, the sum of the delivery costs for the two delivery vehicles is "5 + 30 = 35". Therefore, the delivery cost can be reduced, and this is adopted as the solution for the delivery plan.
[0044] (Challenges with conventional mesh methods) Figure 5 is a conceptual diagram illustrating the process of improvement (in this case, transfer) using the conventional mesh method. The explanation assumes that the process proceeds from left to right in Figure 5. Here, two vehicles, A and B, are used as examples. Vehicle A is assigned delivery destinations with 3 mesh counts ("1" to "3"), and vehicle B is assigned delivery destinations with 5 mesh counts ("4" to "8"). Here, it is assumed that one delivery person is responsible for each vehicle. In this case, each delivery destination is shown aggregated within a mesh unit area. The arrows indicate the delivery order.
[0045] In this example, let's assume that delivery destination "8" is transferred from vehicle B to vehicle A. At this time, let's assume that vehicle A has set the delivery order so that delivery destination "8" comes after delivery destination "3". At first glance, it might seem that both vehicles A and B have been assigned 4 mesh units each, and that the delivery destinations are leveled out. However, since the delivery destinations are aggregated by the mesh unit area, in this example the actual number of deliveries (total number of delivery destinations) is 4 for vehicle A and 6 for vehicle B, meaning that the leveling is not sufficient. Note that although a transfer was used as an example here, similar issues can arise with exchanges.
[0046] (Improvement in mesh using the method of this embodiment) In light of the challenges of leveling across meshes as described above, this embodiment improves the process by considering the number of delivery destinations aggregated in the mesh. Figure 6 is a conceptual diagram illustrating the flow of transfers across meshes using the method according to this embodiment.
[0047] The process is explained assuming it proceeds from left to right in Figure 6. Here, we take two delivery vehicles, A and B, as examples. Delivery vehicle A is assigned delivery destinations with 3 mesh counts ("1" to "3"), and vehicle B is assigned delivery destinations with 5 mesh counts ("4" to "8"). In this case, each delivery destination is shown in its aggregated state within the mesh unit area. The arrows indicate the delivery order. Next to each delivery destination, the number of destinations before aggregation is shown. Therefore, in reality, vehicle A is assigned 3 delivery destinations, and vehicle B is assigned 7 delivery destinations.
[0048] In this example, delivery destinations "7" and "8" are transferred from vehicle B to vehicle A. At this time, vehicle A sets the delivery order so that delivery destination "7" comes after delivery destination "3", and then delivery destination "8". At first glance, it might seem that vehicle A is assigned 5 delivery destinations and vehicle B is assigned 3 delivery destinations, and that no leveling has occurred. However, considering the number of deliveries before aggregation, in this example, the actual number of deliveries (total number of delivery destinations) for both vehicle A and B is 5, so leveling has occurred.
[0049] [Delivery plan generation process] Figure 7 is a flowchart of the delivery plan generation process performed by the delivery plan generation device 100 according to this embodiment. This process flow may be realized by the processing unit 110 of the delivery plan generation device 100 reading and executing programs and data stored in the storage unit 120. For the sake of simplicity, the processing unit for each step is described collectively as the delivery plan generation device 100.
[0050] The delivery plan generation device 100 receives and inputs information regarding the delivery area (step S701). The information regarding the delivery area may specify a region or area of responsibility on a map, or it may specify a list of delivery destinations. The information regarding the delivery area may also be received from the client terminal 200 or input via the UI unit 130.
[0051] The delivery plan generation device 100 references road information from the road information DB 121 based on the information entered in step S701 (step S702). The road information DB 121 is updated as needed, and the latest road information may be referenced.
[0052] The delivery plan generation device 100 calculates the road costs corresponding to the road information referenced in step S702 and the multiple roads included in the delivery area entered in step S701 (step S703). The road costs may be predetermined or may be changed according to conditions such as congestion or construction. In addition, the road costs may be set according to the shape and characteristics of the roads, traffic regulations, etc.
[0053] Based on the road information referenced in step S702, the delivery plan generation device 100 sequentially identifies the nodes of the two delivery destinations (including bases) for which it wants to determine the delivery route (step S704).
[0054] The delivery plan generation device 100 uses a predetermined algorithm to determine a delivery route having two sequentially identified delivery destination nodes and calculates the delivery cost corresponding to the determined delivery route (step S705). The algorithm for determining the delivery route may be, for example, the well-known Dijkstra's algorithm. In this embodiment, the delivery route is determined so as to be a single continuous line for each unit area assigned to each of the multiple personnel, as shown in Figures 3(c) and 3(d).
[0055] The delivery plan generation device 100 calculates a delivery plan based on the delivery cost determined in step S705 (step S706). Details of this process will be described later using Figure 8. Then, this processing flow ends.
[0056] (Delivery plan calculation process) Figure 8 is a flowchart of the delivery plan calculation process according to this embodiment. This process flow corresponds to step S706 in Figure 7.
[0057] The delivery plan generation device 100 determines an initial solution for the delivery plan (step S801) using the delivery cost determined in step S705 of Figure 7. The initial solution for the delivery plan is a delivery plan that includes the delivery route and delivery cost determined in step S705. Note that the initial solution may also be a delivery plan manually formulated by the user of the delivery plan generation device 100 or client terminal 200 based on the delivery route and delivery cost determined in step S705 described above.
[0058] The delivery plan generation device 100 sequentially applies the above-described improvement method to all combinations of delivery destinations based on the current solution, which is the delivery plan (step S802). Here, the current solution is either the initial solution determined in step S801, or the improved solution obtained in the later step S804.
[0059] The delivery plan generation device 100 calculates the actual number of deliveries within the delivery mesh for each vehicle that is a candidate for improvement (i.e., the number of deliveries before aggregation) (step S803).
[0060] The delivery plan generation device 100 determines whether the leveling condition is met with respect to the number of deliveries calculated in step S803 (step S804). The leveling condition is predetermined and may be set as follows: for example, the difference in the number of deliveries for each vehicle is within a predetermined value (for example, "1"). An example of setting the leveling condition will be described later. If the leveling condition is met (step S804; YES), the processing of the delivery plan generation device 100 proceeds to step S805. On the other hand, if the leveling condition is not met (step S804; NO), the processing of the delivery plan generation device 100 returns to step S802 and the process is repeated.
[0061] In step S802, the delivery plan generation device 100 performs three types of improvement methods on all combinations of delivery destinations and determines whether or not it was possible to improve the delivery plan (step S805). This determination is based on whether or not the delivery cost was reduced, as described above. If improvement was achieved (step S805; YES), the delivery plan generation device 100 proceeds to step S806. On the other hand, if improvement was not achieved (step S805; NO), the delivery plan generation device 100 proceeds to step S807.
[0062] The delivery plan generation device 100 adopts the improved solution as the current solution (step S806). Then, the processing of the delivery plan generation device 100 returns to step S802 and the process is repeated.
[0063] The delivery plan generation device 100 outputs the current solution as the final delivery plan (step S807). This output may be displayed on the UI unit 130 of the delivery plan generation device 100 by generating a delivery plan screen, or it may be notified to the client terminal 200. Then, this processing flow ends.
[0064] If, during this processing flow, a predetermined time has elapsed since the start of the delivery plan calculation process, the solution at that point will be output as the delivery plan, and this processing flow will terminate. In this case, a screen indicating that the process was interrupted may be displayed. Examples of setting this time will be described later.
[0065] [UI screen] The following describes an example of the configuration of a UI screen based on a delivery plan generated by the delivery plan generation device 100 in this embodiment. Each UI screen is generated, for example, by the screen generation unit 114 of the delivery plan generation device 100 and displayed and provided by the UI unit 130 of the delivery plan generation device 100 or the UI unit 204 of the client terminal 200.
[0066] Figure 9 shows an example configuration of the settings screen 900 used when creating a delivery plan. The settings screen 900 is displayed, for example, in step S701 of Figure 7. The input form 901 is an item for specifying delivery destination data. The input form 901 may be configured to accept input by displaying a list of available delivery destination data, or it may be accepted by specifying a predetermined storage location. The delivery destination data is a list data consisting of, for example, delivery destination information and package information, and corresponds to the information regarding the delivery range in step S701. The delivery person setting button 902 is a button for setting settings for each delivery person. When the delivery person setting button 902 is pressed, the system transitions to the settings screen 1100 shown in Figure 11. The default setting button 903 is a button for setting default values for various parameters used when creating a delivery plan. When the default setting button 903 is pressed, the system transitions to the settings screen 1000 shown in Figure 10.
[0067] Figure 10 shows an example configuration of a settings screen 1000 for setting various parameters used when creating a delivery plan. Input form 1001 is an item for setting the maximum calculation time based on the current time. The delivery plan is generated with the time specified in input form 1001 as the maximum. Normally, generating a delivery plan requires a certain processing time, so an upper limit is set here, and if the upper limit is exceeded, the delivery plan generation process is terminated, and the solution at that point is used as the delivery plan. Input form 1002 is an item for setting the maximum mesh width (i.e., unit area) of a unit area in the mesh. In this embodiment, a rectangular unit area with the same length and width is used. Input forms 1001 and 1002 may be configured to allow text input, for example.
[0068] Input form 1003 is an item for specifying the parameter to be leveled. In the example process shown in Figure 8, "number of deliveries" was used as an example of the parameter to be leveled. However, the parameter to be leveled is not limited to this. For example, "number of deliveries," "number of deliveries (unit area)," "delivery distance," and "delivery time" may be used as the parameter to be leveled. Alternatively, "number of deliveries" or "number of deliveries (unit area)" may be combined with "delivery distance," "delivery time," etc. Therefore, input form 1003 may be configured to accept these as a list. In the above example, "number of deliveries" refers to the case where the number of deliveries before aggregation is the target of leveling, and "number of deliveries (unit area)" refers to the case where the number of deliveries after aggregation is the target of leveling.
[0069] Input form 1004 is an item for specifying the allowable difference (deviation) for each assignment when leveling is performed, and the selectable values are switched according to the settings specified in input form 1003. For example, if "Number of deliveries" or "Number of deliveries (unit area)" is specified in input form 1003, input form 1004 may be configured to accept a list of values such as "5 deliveries", "10 deliveries", and "15 deliveries". Similarly, if "Delivery distance" is specified in input form 1003, input form 1004 may be configured to accept a list of values such as "5km", "10km", and "15km". Similarly, if "Delivery time" is specified in input form 1003, input form 1004 may be configured to accept a list of values such as "5 minutes", "10 minutes", and "15 minutes". Alternatively, the allowable value may be configured to be set as a ratio ("5%", "10%", "15%", etc.). Furthermore, when equalizing for three or more delivery personnel, the acceptable value may be the difference between the delivery personnel with the highest and lowest assignments.
[0070] The OK button 1005 is used to confirm each setting value entered on the settings screen 1000 as the default setting. The Cancel button 1006 is used to discard each setting value entered on the settings screen 1000. The system may be configured to transition to the settings screen 900 when either the OK button 1005 or the Cancel button 1006 is pressed.
[0071] Figure 11 shows an example configuration of the settings screen 1100 for performing leveling. Input form 1101 is an item for specifying the delivery start time in the delivery plan. Input form 1102 specifies the execution time for creating the delivery plan. Similar to input form 1001 in Figure 10, the delivery plan generation process is executed with the time specified here as the maximum processing time.
[0072] Input form 1103 is an item that displays the number of delivery personnel, i.e., the number of people to be equalized. The delivery person list 1104 displays information about the delivery personnel in a list format, and is configured so that each item can be entered. The item "No." indicates identification information to uniquely identify the delivery person. The item "Person in Charge" indicates the name of the delivery person. The item "Delivery Skill" indicates the delivery skill of the delivery person, and here, a higher number indicates a more skilled delivery person. The item "Delivery Skill" may also be configured to be toggleable between showing and hiding.
[0073] The "Shift" item indicates the time period during which each delivery person works. Here, it is shown in one-hour increments, but it may be configured to display in larger or smaller time periods. The "Shift" item may also be configured to display further time periods by switching the display range using a slider bar or similar. The "Delivery" item is used to specify the delivery persons to be leveled, and a checkmark is displayed when selected. The number of delivery persons selected here is displayed in input form 1103. The "Delivery Ratio" item is used to specify the delivery ratio to be assigned to each of the selected delivery persons. The sum of the delivery ratios will be 100 (%).
[0074] Setting item 1105 is for displaying the delivery forecast period as a result of leveling. In this example, it is configured so that "Delivery," "Today," "This Week," "This Month," and any arbitrary period can be set. Here, "This Month" is selected and the leveling button 1106 is pressed, and as a result of the leveling, the "Number of Deliveries," "Working Hours," and "Delivery Distance" for each delivery person for this month are displayed in graphs 1107, 1108, and 1109. If the period includes past data, a portion of it will be aggregated as actual data. Note that if "Delivery" is selected in setting item 1105 and the leveling button 1106 is pressed, the leveling process and the display of graphs 1107, 1108, and 1109 will be performed only on the delivery destination data specified in the input form 901 of the setting screen 900. In this case, only the delivery persons selected in the delivery person list 1104, i.e., those who are subject to leveling, may be displayed in the graphs.
[0075] Figure 12 shows an example of the data structure for each delivery person's deliveries. The data here includes the items "ID," "Delivery Start Time," "Delivery End Time," "Delivery Person," "Delivery Time," "Distance," and "Number of Deliveries." This data may be historical data if the deliveries have been completed, or it may be structured as scheduled data if the deliveries have not yet been completed. When "Today," "This Week," "This Month," or any other period is selected in setting item 1105, this data is used to aggregate the results in the graph. This data is updated as needed, such as when delivery destinations are assigned or when deliveries are completed, and may be managed in the delivery information DB 122 or the person in charge information DB 123. Note that the structure of the historical data is just an example and is not limited to this. For example, other items may be included if they are necessary for generating the graph.
[0076] Figure 13 shows an example of the UI screen configuration that shows the result of the leveling process according to this embodiment, when "Delivery" is selected in setting item 1105 and the leveling button 1106 is pressed. Figure 13(a) shows an example of the UI screen 1300 that is displayed when leveling is performed successfully as a result of the leveling process. Figure 13(b) shows an example of the UI screen 1310 that is displayed when leveling is not performed successfully as a result of the leveling process.
[0077] Here, we show an example of using the following parameters as leveling parameters, as specified in the settings screen 1000 shown in Figure 10. These parameters are displayed on the screen along with the results of the leveling process.
[0078] Target for leveling: Number of items (actual number of deliveries) Delivery staff: 2 people (Delivery staff A, Delivery staff B) Maximum calculation time: 30 minutes Mesh width: 100m Error: 2 items
[0079] As shown in result 1301 on UI screen 1300 in Figure 13(a), the error in the number of items assigned to each delivery person after equalization is 1, which is less than or equal to the equalization parameter of 2. Therefore, it is displayed as if the equalization was performed successfully. The confirm button 1302 is pressed when the current equalization result is to be adopted. The recalculate button 1303 is pressed when the equalization process is to be performed again.
[0080] On the other hand, as shown in result 1311 on UI screen 1310 in Figure 13(b), the error in the number of items assigned to each delivery person after equalization is 4, which is more than the equalization parameter of 2. Therefore, it is displayed as if the equalization was not performed correctly. Also, the calculation time is 30 minutes, which is the same value as the equalization parameter of 30 minutes, indicating that the equalization process was terminated midway. The OK button 1312 is pressed when the current equalization result is to be adopted. The RECalculate button 1313 is pressed when the equalization process is to be performed again.
[0081] Figures 14 and 15 show examples of the configuration of a UI screen 1400 for displaying the results of the leveling process, and are screens displayed, for example, on the UI unit 130 of a delivery plan generation device 100 operated by an administrator. For example, the user may transition to UI screen 1400 when the OK button is pressed on any of the UI screens in Figure 13.
[0082] Figure 14 shows an example of a display (normal mode) that shows individual delivery destinations within a mesh unit area. On the UI screen 1400, dashed lines 1402 indicating the set mesh unit areas are superimposed on the map 1401. The assignment information 1403 shows the results of the leveling process for each delivery person (in this example, two delivery persons, A and B). The confirm button 1404 is pressed to confirm the leveling results and notify each delivery person. The recalculate button 1405 is pressed to perform the leveling process again. The mode switching button 1406 is used to switch to the display example (mesh mode) shown in Figure 15.
[0083] On UI screen 1400, icon 1407 indicates the location of the delivery person. In this example, it is assumed that delivery persons A and B are in the same location and are shown as "×2". The position of icon 1407 may change as the delivery person (more specifically, the client terminal 200) moves. Icon 1408 indicates the location of the delivery destination and is displayed with hatching. For example, manipulating icon 1408 may display corresponding, more detailed delivery information (e.g., the delivery destination address). The number within icon 1408 indicates the delivery order. Icon 1409, like icon 1408, indicates the location of the delivery destination, but here it is assigned to a different delivery person and is therefore displayed in a different format (white in this example) than hatching.
[0084] Figure 15 shows an example of the display (mesh mode) when aggregated by mesh unit area. It shows the aggregated delivery destinations belonging to each unit area. On the UI screen 1500, solid lines 1502 indicating the set mesh are superimposed on the map 1501. The assignment information 1503 shows the results of the leveling process for each delivery person (in this example, two delivery persons, A and B). The confirm button 1504 is pressed to confirm the leveling results and notify each delivery person. The recalculate button 1505 is pressed to perform the leveling process again. The mode switching button 1506 is used to switch between the display example shown in Figure 14 (normal mode).
[0085] In UI screen 1500, icon 1507 indicates the location of the delivery person. In this example, it is assumed that delivery persons A and B are in the same location and are shown as "×2". The position of icon 1507 may change as the delivery person (more specifically, the client terminal 200) moves. Icon 1508 shows the aggregated results of delivery destinations belonging to a unit area (indicated by "(×)") and the delivery order, and is displayed with hatching. For example, manipulating icon 1508 may display a list of corresponding, more detailed delivery information (e.g., delivery destination addresses). Icon 1509, like icon 1508, indicates the location of a delivery destination, but here it is assigned to a different delivery person and is therefore displayed in a different format (white outline in this example).
[0086] Figures 16 and 17 show examples of UI screen configurations for displaying the results of the leveling process, and are screens displayed, for example, on the UI unit 204 of a client terminal 200 operated by delivery person A. For convenience, the UI screen 1600 shown in Figure 16 will also be referred to as the first screen, and the UI screen 1700 shown in Figure 17 will also be referred to as the second screen. In this description of the embodiment, "first" and "second" are used merely to distinguish and explain different components, and are not intended to be interpreted as limiting the explanation to specific components. For example, when the confirm button is pressed on any of the UI screens in Figure 13, the delivery plan as a result of the leveling process will be notified to the client terminal 200 held by delivery person A, and the UI screen 1600 may be displayed.
[0087] Figure 16 shows an example of displaying individual delivery destinations assigned to delivery person A (normal mode). On the UI screen 1600, dashed lines 1602 indicating the set mesh are superimposed on the map 1601. Assignment information 1603 shows information about deliveries assigned to delivery person A. This information includes the number of deliveries, distance traveled, and estimated time required for delivery. The mode switching button 1604 is used to switch between the display example shown in Figure 17 (mesh mode).
[0088] In UI screen 1600, icon 1605 indicates the location of delivery person A. The position of icon 1605 may change as delivery person A (more specifically, client terminal 200) moves. Icon 1606 indicates the location of the delivery destination. For example, manipulating icon 1606 may display corresponding, more detailed delivery information (e.g., the delivery destination address). The number within icon 1606 indicates the delivery order. Delivery route 1607 shows the delivery route to each assigned delivery destination. This route is derived based on the delivery cost as described above.
[0089] Figure 17 shows an example of the display (mesh mode) when aggregated by mesh unit area. It shows the aggregated delivery destinations belonging to each unit area. On the UI screen 1700, solid lines 1702 indicating the set mesh are superimposed on the map 1701. The assignment information 1703 shows information about deliveries assigned to delivery person A. This information includes the number of deliveries, distance traveled, and estimated time required for delivery. The mode switching button 1704 is used to switch between the display example shown in Figure 16 (normal mode) and the mode switching button.
[0090] In UI screen 1700, icon 1705 indicates the location of delivery person A. The position of icon 1705 may change as delivery person A (more specifically, client terminal 200) moves. Icon 1706 indicates the aggregated results of delivery destinations belonging to a unit area (indicated by "(×)") and the delivery order. For example, manipulating icon 1706 may display a list of corresponding, more detailed delivery information (e.g., delivery destination addresses).
[0091] As described above, the delivery plan generation device 100 according to this embodiment has a screen generation unit 114 that provides a setting screen (for example, setting screen 900, setting screen 1000, setting screen 1100) that allows the user to input setting items used when generating delivery routes for multiple personnel, which are identified by connecting unit areas containing one or more delivery destinations, and a process to equalize the deliveries included in each of the multiple personnel's delivery routes.
[0092] This makes it possible to create a delivery plan that equalizes delivery routes among delivery personnel, reducing the overall delivery time while suppressing imbalances in the workload of delivery personnel.
[0093] Furthermore, the settings screen 1000 is configured to allow specifying the maximum calculation time for repeating the processes of generating delivery routes and leveling out deliveries.
[0094] This makes it possible to terminate processing at a desired time, even when performing computationally intensive leveling processes, thereby preventing the execution of processes that are unnecessarily long.
[0095] Furthermore, the settings screen 1000 is configured to allow the user to specify the size of the unit area.
[0096] This makes it possible to aggregate delivery destinations by the desired unit area size, and to generate delivery routes at any granularity, thereby reducing the processing load.
[0097] Furthermore, the settings screen 1000 is configured to allow the user to specify the targets for delivery leveling.
[0098] This makes it possible to specify the desired target as the target for leveling.
[0099] Furthermore, the targets for delivery leveling are the number of deliveries, delivery distance, or delivery time.
[0100] This makes it possible to specify one of the following for leveling out the delivery volume: the number of deliveries per unit area, the delivery distance, or the delivery time.
[0101] Furthermore, the settings screen 1000 is configured to allow specifying the acceptable difference for the leveling of deliveries.
[0102] This makes it possible to perform leveling within the desired accuracy and tolerance range.
[0103] Furthermore, the screen generation unit 114 also provides a settings screen 1100 that allows setting at least the person to whom the delivery destination will be assigned, and the period.
[0104] This makes it possible to specify the desired personnel and time period to generate and standardize delivery routes.
[0105] Furthermore, the settings screen 1100 is configured to display the aggregated results of the leveling process for each of the multiple responsible persons, categorized by leveling item.
[0106] This makes it easy to grasp the aggregated values of the leveling results and the aggregated values of delivery performance, and enables leveling to be implemented according to the situation.
[0107] Furthermore, the screen generation unit 114 provides a UI screen 1600 that displays the delivery routes for multiple delivery destinations assigned to the person in charge, superimposed on a map of the delivery area.
[0108] This allows delivery personnel to easily understand the standardized delivery routes assigned to them, thereby improving the convenience of deliveries.
[0109] Furthermore, the screen generation unit 114 provides a UI screen 1700 that displays the total number of delivery destinations assigned to the person in charge, aggregated for each unit area, superimposed on a map of the delivery area.
[0110] This allows delivery personnel to simplify and understand their assigned deliveries on a per-area basis, in a way that is more evenly distributed.
[0111] Furthermore, this disclosure also applies to programs and storage media that supply programs that realize the functions of the apparatus of the above-described embodiment to the apparatus via a network or various storage media, and which are read and executed by a computer within the apparatus.
[0112] Although various embodiments have been described above with reference to the drawings, it goes without saying that this disclosure is not limited to these examples. It will be clear to those skilled in the art that various modifications, alterations, substitutions, additions, deletions, and equivalents can occur within the scope of the claims, and these will naturally fall within the technical scope of this disclosure. Furthermore, the components of the various embodiments described above can be combined arbitrarily without departing from the spirit of the invention. [Industrial applicability]
[0113] This disclosure provides a delivery plan generation device and delivery plan generation method that effectively support the formulation of an optimal delivery plan for multiple packages according to road conditions to the delivery destination, and significantly reduce the burden on delivery personnel responsible for each package. [Explanation of Symbols]
[0114] 100... Delivery plan generation device 110... Processing Unit 111...Road Cost Calculation Unit 112...Delivery cost generation unit 113…Delivery Planning Department 114...Screen generation section 115...DB management department 116...Data Integration Department 120...Storage section 121…Road information DB 122…Delivery information DB 123... Person in Charge Information Database 130...UI section 140... Communications Department 200…Client terminals 201... Processing Unit 202...Storage section 203... Communications Department 204...UI section 205...Sensor unit 300…Network 900, 1000, 1100... Settings screen 1300, 1310, 1400, 1500, 1600, 1700…UI screen
Claims
1. A delivery plan generation device that uses a processor to perform a process of dividing the delivery area into predetermined unit areas and generating delivery routes for each of multiple personnel to whom the delivery destinations of goods are assigned, The aforementioned processor, This invention provides a settings screen for the user to input settings used when executing a delivery plan generation process that repeatedly generates delivery routes for each of the multiple personnel identified by connecting unit areas containing one or more delivery destinations, and performs a leveling process to equalize the deliveries included in each of the multiple personnel's delivery routes, and a results screen for the delivery plan generation process. Based on user input, the settings items, including the target for delivery leveling, the allowable difference for said leveling, and the maximum calculation time for the delivery plan generation process, are specified. If the delivery plan generation process is completed within the maximum calculation time, the results screen indicating the successful completion of the delivery plan generation process based on the setting items is provided. If the time required for the delivery plan generation process exceeds the maximum calculation time, the results screen indicating the intermediate solution at that point is provided. Delivery plan generation device.
2. The delivery plan generation device according to claim 1, wherein the result screen includes a recalculation operation unit that instructs the delivery plan generation process to be performed again.
3. The delivery plan generation device according to claim 1, wherein the setting screen is configured to allow the size of the unit area to be specified.
4. The delivery plan generation device according to claim 1, wherein the target for leveling is any of the number of deliveries, delivery distance, or delivery time.
5. The delivery plan generation device according to claim 1, further comprising a processor that provides a second setting screen in which at least the person to be assigned to the delivery destination and the period can be set.
6. The delivery plan generation device according to claim 5, wherein the second setting screen is configured to display the aggregated values of the leveling results for each of the multiple personnel, for each leveling item.
7. The delivery plan generation device according to claim 1, further comprising a processor that provides a first screen that displays delivery routes for multiple delivery destinations assigned to a person in charge superimposed on a map of the delivery area.
8. The delivery plan generation device according to claim 1, further comprising a second screen which displays the aggregated number of delivery destinations assigned to a person in charge for each unit area superimposed on a map of the delivery area.
9. A delivery plan generation method that divides the delivery area into predetermined unit areas and generates delivery routes for each of multiple personnel to whom the delivery destinations of goods are assigned, The processor and memory work together, This invention provides a settings screen for the user to input settings used when executing a delivery plan generation process that repeatedly generates delivery routes for each of the multiple personnel identified by connecting unit areas containing one or more delivery destinations, and performs a leveling process to equalize the deliveries included in each of the multiple personnel's delivery routes, and a results screen for the delivery plan generation process. Based on user input, the settings items, including the target for delivery leveling, the allowable difference for said leveling, and the maximum calculation time for the delivery plan generation process, are specified. If the delivery plan generation process is completed within the maximum calculation time, the results screen indicating the successful completion of the delivery plan generation process based on the setting items is provided. If the time required for the delivery plan generation process exceeds the maximum calculation time, the results screen indicating the intermediate solution at that point is provided. Delivery plan generation method.