WO2023199755A1 - 配送計画生成装置、および配送計画生成方法 - Google Patents

配送計画生成装置、および配送計画生成方法 Download PDF

Info

Publication number
WO2023199755A1
WO2023199755A1 PCT/JP2023/013446 JP2023013446W WO2023199755A1 WO 2023199755 A1 WO2023199755 A1 WO 2023199755A1 JP 2023013446 W JP2023013446 W JP 2023013446W WO 2023199755 A1 WO2023199755 A1 WO 2023199755A1
Authority
WO
WIPO (PCT)
Prior art keywords
delivery
plan generation
leveling
generation device
charge
Prior art date
Application number
PCT/JP2023/013446
Other languages
English (en)
French (fr)
Inventor
晃一郎 山口
凌大 齋藤
Original Assignee
パナソニックＩｐマネジメント株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by パナソニックＩｐマネジメント株式会社 filed Critical パナソニックＩｐマネジメント株式会社
Publication of WO2023199755A1 publication Critical patent/WO2023199755A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
    • G06Q10/047—Optimisation of routes or paths, e.g. travelling salesman problem
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083—Shipping

Definitions

  • the present disclosure relates to a delivery plan generation device and a delivery plan generation method that support delivery of multiple packages to be delivered.
  • Patent Document 1 discloses a method of generating an optimal delivery route by dividing a delivery range into meshes using a mesh method and connecting the meshes with a single stroke using a shortest distance condition.
  • An object of the present invention is to provide a delivery plan generation device and a delivery plan generation method that generate a delivery plan that suppresses the above.
  • the present disclosure is a delivery plan generation device that divides a delivery range into predetermined unit areas and generates delivery routes for each of a plurality of persons to whom delivery destinations of goods are assigned, the device including one or more delivery destinations.
  • a delivery plan generating device is provided, which includes a providing unit that provides a setting screen that allows a user to input setting items used when generating each delivery route.
  • the present disclosure also provides a delivery plan generation method that divides a delivery range into predetermined unit areas and generates delivery routes for each of a plurality of personnel to whom delivery destinations of goods are assigned, in which a processor and a memory cooperate. process to generate a delivery route for each of the plurality of persons in charge specified by connecting unit areas including one or more delivery destinations, and to equalize the deliveries included in each of the delivery routes of the plurality of persons in charge.
  • the present invention provides a delivery plan generation method that provides a setting screen that allows a user to input setting items to be used when generating delivery routes for each of the plurality of persons in charge by repeatedly performing the above steps.
  • a block diagram showing an example of a system configuration according to Embodiment 1 of the present invention Conceptual diagram for explaining the mesh according to Embodiment 1 of the present invention
  • Conceptual diagram for explaining aggregation of delivery plans according to Embodiment 1 of the present invention An explanatory diagram for explaining the delivery planning method according to Embodiment 1 of the present invention
  • An explanatory diagram for explaining the delivery planning method according to Embodiment 1 of the present invention An explanatory diagram for explaining the delivery planning method according to Embodiment 1 of the present invention
  • Flowchart of delivery plan generation processing according to Embodiment 1 of the present invention Flowchart of delivery plan calculation processing according to Embodiment 1 of the present invention
  • a diagram showing an example of the configuration of a UI screen of the delivery plan generation device according to Embodiment 1 of the present invention A diagram showing an example of the configuration of a UI screen of the delivery plan generation device according to Embodiment 1 of the present invention.
  • a diagram showing an example of the configuration of a UI screen of the delivery plan generation device according to Embodiment 1 of the present invention A diagram showing an example of the configuration of a UI screen of the delivery plan generation device according to Embodiment 1 of the present invention.
  • a diagram showing an example of the configuration of a UI screen of the delivery plan generation device according to Embodiment 1 of the present invention A diagram showing an example of the configuration of a UI screen of the delivery plan generation device according to Embodiment 1 of the present invention.
  • Patent Document 1 reduces delivery costs and improves delivery efficiency by automatically determining delivery routes and determining the type and number of delivery vehicles required for a unit area using a mesh method. It has been realized. However, uneven workloads occur among multiple delivery personnel, and no consideration is given to leveling out the workloads. In actual sites, the delivery of a huge amount of goods is shared among multiple delivery personnel (drivers), and it is not possible to determine the delivery route for each driver and the delivery schedule for each driver. It was not possible to level out the quantities. In particular, the number of delivery destinations included in a mesh unit area varies depending on the situation, which reduces the accuracy of leveling. Further, Patent Document 1 does not take into consideration the convenience of UI screens and the like that each delivery person can use when actually making a delivery.
  • Patent Document 1 is unable to realize work sharing that reflects past work results.
  • a delivery plan that can generate a delivery plan that equalizes the work of delivery personnel and suppresses the overall execution time of delivery while suppressing the imbalance in the workload of delivery personnel.
  • a delivery plan is a delivery plan that uses at least one delivery vehicle (for example, a truck) to deliver from a base to multiple delivery destinations within a predetermined period (for example, one day).
  • This is a delivery route plan for delivering cargo (goods) to.
  • the delivery route corresponds to the running order of multiple delivery destinations.
  • Delivery plan generation device 100 is communicably connected to one or more client terminals 200 via network 300 .
  • the delivery plan generation device 100 may be configured as an on-premise server device at a delivery company's base, or may be configured as a cloud type on a network.
  • the delivery plan generation device 100 is configured to include a processing section 110, a storage section 120, a UI (User Interface) section 130, and a communication section 140.
  • the processing unit 110 includes, for example, a CPU (Central Processing Unit), a GPU (Graphical Processing Unit), an MPU (Micro Processing Unit), and a DSP (Digital Processing Unit). It is configured using a Signal Processor) or an FPGA (Field-Programmable Gate Array).
  • the processor may be
  • the processing unit 110 realizes various functions described below 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 includes volatile/nonvolatile storage such as RAM (Random Access Memory), ROM (Read Only Memory), and HDD (Hard Disk Drive). It may consist of a storage device.
  • the UI unit 130 is a unit for accepting operations by the user of the delivery plan generation device 100 and outputting various information.
  • the UI unit 130 may include a display, a mouse, a keyboard, and the like.
  • the communication unit 140 is an interface for communicating with an external device via the network 300.
  • the communication standards that can be supported by the communication unit 140 are not particularly limited, and may be wired or wireless. Further, it may be possible to support multiple communication standards.
  • the client terminal 200 is a terminal device that can be used by a delivery person during delivery work, and may be, for example, a mobile terminal such as a smartphone, a tablet terminal, or a POS terminal. Further, the client terminal 200 may be installed in a delivery vehicle (hereinafter also simply referred to as a "vehicle") used for delivery.
  • the client terminal 200 includes a processing section 201, a storage section 202, a communication section 203, a UI section 204, and a sensor section 205.
  • the processing unit 201 may be configured using, for example, a CPU, GPU, MPU, DSP, or FPGA.
  • the processing unit 201 realizes various functions described below by, for example, referring to various data stored in the storage unit 202 and reading programs.
  • the storage unit 202 is a storage unit for storing various data and programs, and is configured from a volatile/nonvolatile storage device such as RAM, ROM, HDD, flash memory, or SSD (Solid State Drive). It's okay to be.
  • the communication unit 203 is an interface for wirelessly communicating with an external device via the network 300.
  • the communication standards compatible with the communication unit 203 are not particularly limited.
  • the sensor unit 205 is composed of one or more sensors for detecting status information of the client terminal 200, and includes, for example, a position sensor based on a GNSS (Global Navigation Satellite System) represented by a GPS (Global Positioning System), and a magnetic sensor. , an acceleration sensor, a camera as a photographing device, and the like.
  • GNSS Global Navigation Satellite System
  • GPS Global Positioning System
  • the processing unit 110 of the delivery plan generation device 100 includes 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.
  • a road cost calculation unit 111 a delivery cost generation unit 112
  • a delivery plan calculation unit 113 a delivery plan calculation unit 113
  • a screen generation unit 114 a DB management unit 115
  • a data linkage unit 116 a data linkage unit 116.
  • the road cost calculation unit 111 calculates the cost of a road used as a delivery route.
  • the delivery cost generation unit 112 calculates the delivery cost based on the road cost, the size of the package to be delivered, and the like.
  • the delivery plan calculation unit 113 calculates a delivery plan for the package based on the delivery cost and road cost.
  • the screen generation unit 114 generates various UI screens to be provided to the delivery plan generation device 100 and the client terminal 200.
  • the DB management unit 115 updates and manages various DBs configured in the storage unit 120.
  • the data cooperation unit 116 acquires various information necessary for the delivery plan from an external device (client terminal 200 and other external devices) and provides it.
  • 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.
  • the configuration of the DB is an example, and one DB may be divided into more detailed sections, or a plurality of DBs may be configured together.
  • the road information DB 121 is a database for managing road information and map information of the delivery area. Road information and map information may be updated, for example, by accessing an external map server (not shown) and acquiring the latest information. In addition to the shape of the road, the road information may also include information on traffic congestion, passability, past driving history, and the like. Based on this information, the cost of each road is defined.
  • the delivery information DB 122 is a database for managing delivery information of packages to be delivered. The delivery information may include the delivery destination, delivery source, delivery base, delivery date and time, and the like.
  • the person in charge information DB 123 is a database for managing information on persons in charge of delivery. The person in charge information may include assigned deliveries, the person's delivery history, work schedule, current position during delivery, delivery skills of the person in charge, and the like.
  • the delivery plan generation device 100 may be accessed using a web browser (not shown) included in the client terminal 200, or a web browser installed on the client terminal 200 may be used. It may also be used by activating an application corresponding to the delivery plan generation device 100.
  • the division of functions between the delivery plan generation device 100 and the client terminal 200 is not limited to the configuration shown in FIG. There may be.
  • FIG. 2 is a diagram for explaining aggregation using a mesh according to this embodiment.
  • the mesh 210 in FIG. 2(a) shows the state before aggregation
  • the mesh in FIG. 2(b) shows the state after aggregation.
  • 6 ⁇ 6 mesh 36 unit areas in total
  • the vertical and horizontal sizes of one unit area of the mesh are not particularly limited, and any rectangular value may be set.
  • one circle indicates one delivery destination.
  • the unit area 211 includes three delivery destinations.
  • the unit area 212 includes two delivery destinations.
  • the delivery destinations are grouped (aggregated) for each unit area.
  • the unit area 211 in FIG. 2(a) becomes the unit area 221 in FIG. 2(b) by aggregating three delivery destinations.
  • aggregated delivery destinations are indicated by squares.
  • the unit area 212 in FIG. 2(a) becomes the unit area 222 in FIG. 2(b) by aggregating two delivery destinations. This makes it possible to simplify the handling during route generation and reduce the processing load.
  • FIG. 3 is a diagram showing an example of mesh and route generation according to this embodiment. Similar to FIG. 2, an example of a 6 ⁇ 6 mesh set on a map is shown.
  • FIG. 3(a) shows the state before aggregation. The position indicated by the black triangle in FIG. 3 indicates the delivery base (hereinafter also simply referred to as "base") of the package.
  • base the delivery base
  • multiple delivery destinations are indicated by circles around it.
  • the classification is performed using three types of circles (solid line, thick line, and broken line), and an example is shown in which there are 6 solid line circles, 5 thick line circles, and 5 broken line circles. These three types of circles indicate the division status (assignment) of each of the three delivery personnel.
  • FIG. 3(b) shows an example in which the mesh in FIG. 3(a) is adjusted in a 2 ⁇ 2 unit area. In this case, it becomes a 3 ⁇ 3 mesh.
  • FIG. 3(b) the number of delivery destinations belonging to each 2 ⁇ 2 unit area is shown.
  • FIG. 3(c) shows a state where delivery destinations are aggregated in a 2 ⁇ 2 unit area from the state of FIG. 3(b).
  • the aggregated state is shown by a white triangle.
  • the position on the map when aggregated here may be the center position of each delivery destination or the center position of a unit area.
  • arrows indicate delivery routes from the delivery base to the consolidated locations. Here, the return route from the final delivery destination to the delivery base is omitted.
  • Fig. 3(d) shows the state of Fig. 3(a), in which delivery destinations are aggregated in a 1 x 1 unit area in a 6 x 6 mesh, and further, starting from the delivery base, the aggregated locations are The delivery route is indicated by an arrow. Here, the return route from the final delivery destination to the delivery base is omitted.
  • a more appropriate delivery plan is determined by deriving an initial solution of the delivery plan and then applying three types of improvement methods and delivery cost optimization to the initial solution. Optimization of delivery costs includes, for example, reducing delivery costs by changing the travel route between two delivery destinations. More specifically, since the cost (road cost) differs depending on the road, the delivery cost differs depending on which road the vehicle travels when traveling from one delivery destination to another. Which road to drive on may be determined, for example, by performing machine learning based on the driving history of an experienced driver, or may be determined by the well-known Dijkstra method based on a preset road cost. Good too.
  • Replacement is a process of changing the order of delivery destinations.
  • Exchange is a process of exchanging delivery destinations between multiple delivery routes.
  • Transfer is a process of moving the delivery destination to another delivery route. Specific examples of substitution, exchange, and transfer will be described below based on the explanatory diagram of FIG. 4. Note that when there are two routes from each delivery destination, the route with higher cost is represented by a dotted line, and the route with lower cost is represented by a solid line.
  • a delivery plan is set in which delivery is performed by one delivery vehicle in the order of base S ⁇ delivery destination D1 ⁇ delivery destination D2 ⁇ delivery destination D3 ⁇ delivery destination D4.
  • the delivery cost in other words, distance
  • a delivery plan is set in which deliveries are performed in the order of base S ⁇ delivery destination D1 ⁇ delivery destination D3 ⁇ delivery destination D2 ⁇ delivery destination D4 using one delivery vehicle.
  • a delivery plan is set in which delivery is performed by one delivery vehicle in the order of base S ⁇ delivery destination D1 ⁇ delivery destination D2 ⁇ delivery destination D3 ⁇ delivery destination D4.
  • a delivery plan is set in which deliveries are performed in the order of base S ⁇ delivery destination D1 ⁇ delivery destination D3 ⁇ delivery destination D2 ⁇ delivery destination D4 using one delivery vehicle.
  • a delivery plan is set for the first delivery vehicle in which deliveries are made in the order of base S ⁇ delivery destination D1 ⁇ delivery destination D2 ⁇ delivery destination D3 ⁇ delivery destination D4. Furthermore, a delivery plan is set for the second delivery vehicle in which deliveries are made in the order of base S ⁇ delivery destination D5 ⁇ delivery destination D6 ⁇ delivery destination D7 ⁇ delivery destination D8.
  • a delivery plan is set for the first delivery vehicle in which deliveries are made in the order of base S ⁇ delivery destination D1 ⁇ delivery destination D6 ⁇ delivery destination D3 ⁇ delivery destination D4. Furthermore, a delivery plan is set for the second delivery vehicle in which deliveries are made in the order of base S ⁇ delivery destination D5 ⁇ delivery destination D2 ⁇ delivery destination D7 ⁇ delivery destination D8.
  • a delivery plan is set for the first delivery vehicle in which deliveries are made in the order of base S ⁇ delivery destination D1 ⁇ delivery destination D2 ⁇ delivery destination D3 ⁇ delivery destination D4. Furthermore, a delivery plan is set for the second delivery vehicle in which deliveries are made in the order of base S ⁇ delivery destination D5 ⁇ delivery destination D6 ⁇ delivery destination D7 ⁇ delivery destination D8.
  • a delivery plan is set for the first delivery vehicle in which deliveries are made in the order of base S ⁇ delivery destination D1 ⁇ delivery destination D6 ⁇ delivery destination D3 ⁇ delivery destination D4. Furthermore, a delivery plan is set for the second delivery vehicle in which deliveries are made in the order of base S ⁇ delivery destination D5 ⁇ delivery destination D2 ⁇ delivery destination D7 ⁇ delivery destination D8.
  • a delivery plan is set for the first delivery vehicle in which deliveries are made in the order of base S ⁇ delivery destination D1 ⁇ delivery destination D2 ⁇ delivery destination D3 ⁇ delivery destination D4. Furthermore, a delivery plan is set for the second delivery vehicle in which deliveries are made in the order of base S ⁇ delivery destination D5 ⁇ delivery destination D6 ⁇ delivery destination D7 ⁇ delivery destination D8.
  • a delivery plan is set for the first delivery vehicle in which deliveries are made in the order of base S ⁇ delivery destination D1 ⁇ delivery destination D3 ⁇ delivery destination D4. Furthermore, a delivery plan is set for the second delivery vehicle in which deliveries are made in the order of base S ⁇ delivery destination D5 ⁇ delivery destination D6 ⁇ delivery destination D2 ⁇ delivery destination D7 ⁇ delivery destination D8.
  • a delivery plan is set for the first delivery vehicle in which deliveries are made in the order of base S ⁇ delivery destination D1 ⁇ delivery destination D2 ⁇ delivery destination D3 ⁇ delivery destination D4. Furthermore, a delivery plan is set for the second delivery vehicle in which deliveries are made in the order of base S ⁇ delivery destination D5 ⁇ delivery destination D6 ⁇ delivery destination D7 ⁇ delivery destination D8.
  • a delivery plan is set for the first delivery vehicle in which deliveries are made in the order of base S -> delivery destination D1 -> delivery destination D3 -> delivery destination D4. Furthermore, a delivery plan is set for the second delivery vehicle in which deliveries are made in the order of base S ⁇ delivery destination D5 ⁇ delivery destination D6 ⁇ delivery destination D2 ⁇ delivery destination D7 ⁇ delivery destination D8.
  • FIG. 5 is a conceptual diagram for explaining the flow of mesh improvement (here, transfer) using a conventional method. The description will be made assuming that the processing proceeds sequentially from the left in FIG.
  • Vehicle A is assigned a delivery destination with a mesh number of 3 ("1" to "3")
  • vehicle B is assigned a delivery destination with a mesh number of 5 ("1" to "3”).
  • "4" to "8" are assigned.
  • each delivery destination is shown as being aggregated in a unit area of the mesh. Further, the arrows indicate the order of delivery.
  • FIG. 6 is a conceptual diagram for explaining the flow of mesh transfer using the method according to the present embodiment.
  • Delivery vehicle A is assigned a delivery destination with a mesh number of 3 ("1" to “3")
  • vehicle B is assigned a delivery destination with a mesh number of 5.
  • the destination (“4” to “8”) is assigned.
  • each delivery destination is shown as being aggregated in a unit area of the mesh. Further, the arrows indicate the order of delivery.
  • the number of delivery destinations before aggregation is shown. Therefore, in reality, vehicle A is assigned three delivery destinations, and vehicle B is assigned seven delivery destinations.
  • delivery destination "7" and delivery destination “8" are transferred from vehicle B to vehicle A.
  • the delivery order is set so that delivery destination "3" is followed by delivery destination "7” and then delivery destination "8".
  • vehicle A is assigned a mesh number of 5 delivery destinations
  • vehicle B is assigned a mesh number of 3 delivery destinations, and it may seem that leveling is not being performed.
  • the actual number of deliveries (total number of delivery destinations) in this example is equalized, with vehicles A and B both having 5 delivery destinations.
  • FIG. 7 is a flowchart of the delivery plan generation process executed by the delivery plan generation device 100 according to the present embodiment. This processing 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. Here, in order to simplify the explanation, the processing entity of each process will be collectively described as the delivery plan generation device 100.
  • the delivery plan generation device 100 receives and inputs information regarding the delivery range (step S701).
  • the information regarding the delivery range may specify a region on a map or the area in charge, or may specify a list of delivery destinations. Furthermore, information regarding the delivery range may be received from the client terminal 200 or may be input via the UI unit 130.
  • the delivery plan generation device 100 refers to road information from the road information DB 121 based on the information input in step S701 (step S702).
  • the road information DB 121 is updated from time to time, and the latest road information may be referred to.
  • the delivery plan generation device 100 calculates road costs corresponding to the road information referenced in step S702 and a plurality of roads included in the delivery range input in step S701 (step S703).
  • the road cost may be defined in advance, or may be changed depending on conditions such as traffic congestion and construction. Furthermore, the road cost may be set depending on the shape and characteristics of the road, traffic regulations, and the like.
  • the delivery plan generation device 100 Based on the road information referenced in step S702, the delivery plan generation device 100 sequentially identifies nodes of two delivery destinations (including bases) for which delivery routes are to be determined (step S704).
  • the delivery plan generation device 100 uses a predetermined algorithm to determine a delivery route having the two delivery destination nodes identified in sequence, and calculates the delivery cost corresponding to the determined delivery route (step S705).
  • the well-known Dijkstra method may be used as an algorithm for determining the delivery route.
  • the delivery route is determined in such a manner that it is drawn in one stroke for each unit area assigned to each of a plurality of persons in charge, as shown in FIGS. 3(c) and 3(d).
  • the delivery plan generation device 100 calculates a delivery plan based on the delivery cost determined in step S705 (step S706). Details of this step will be described later using FIG. 8. Then, this processing flow ends.
  • FIG. 8 is a flowchart of the delivery plan calculation process according to this embodiment. This processing flow corresponds to step S706 in FIG.
  • the delivery plan generation device 100 determines an initial solution of the delivery plan using the delivery cost determined in step S705 of FIG. 7 (step S801).
  • the initial solution of the delivery plan is a delivery plan that includes the delivery route and delivery cost determined in step S705.
  • the initial solution may be a delivery plan manually formulated by the user of the delivery plan generation device 100 or the client terminal 200 based on the delivery route and delivery cost determined in step S705 described above.
  • the delivery plan generation device 100 sequentially performs the above-mentioned improvement method for all combinations of delivery destinations based on the delivery plan that is the current solution (step S802).
  • the current solution is the initial solution determined in step S801 or the improved solution obtained in the subsequent step S804.
  • the delivery plan generation device 100 calculates the actual number of deliveries in the mesh to be delivered (that is, the number of deliveries before aggregation) for each improvement candidate vehicle (step S803).
  • the delivery plan generation device 100 determines whether the leveling condition is satisfied for the number of deliveries calculated in step S803 (step S804).
  • the leveling condition is set in advance, and may be set, for example, such that the difference in the number of deliveries of each vehicle is within a predetermined value (for example, "1"). An example of setting the leveling conditions will be described later. If the leveling condition is satisfied (step S804; YES), the process of the delivery plan generation device 100 proceeds to step S805. On the other hand, if the leveling condition is not satisfied (step S804; NO), the process of the delivery plan generation device 100 returns to step S802 and repeats the process.
  • the delivery plan generation device 100 determines whether the delivery plan could be improved as a result of applying the three types of improvement methods to all combinations of delivery destinations in step S802 (step S805). The determination here is made based on whether the delivery cost could be reduced as described above. If the improvement has been achieved (step S805; YES), the process of the delivery plan generation device 100 proceeds to step S806. On the other hand, if the improvement has not been achieved (step S805; NO), the process of the delivery plan generation device 100 proceeds to step S807.
  • the delivery plan generation device 100 sets the improved solution as the current solution (step S806). Then, the process of the delivery plan generation device 100 returns to step S802 and repeats the process.
  • the delivery plan generation device 100 outputs the current solution as the final delivery plan (step S807).
  • the output here may be performed by generating a delivery plan screen and outputting it on the UI unit 130 of the delivery plan generation device 100, or by notifying the client terminal 200. Then, this processing flow ends.
  • 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.
  • FIG. 9 shows a configuration example of a settings screen 900 used when making a delivery plan.
  • the setting screen 900 is displayed, for example, in step S701 of FIG.
  • the input form 901 is an item for specifying delivery destination data.
  • the input form 901 may be configured to accept a list of delivery destination data that can be input, or may be accepted by specifying a predetermined storage location.
  • the delivery destination data is, for example, list data including delivery destination information, package information, etc., and corresponds to the information regarding the delivery range in step S701.
  • the delivery person setting button 902 is a button for making settings regarding each delivery person. When the delivery person setting button 902 is pressed, the screen changes to a setting screen 1100 shown in FIG. 11.
  • the default setting button 903 is a button for setting default values of various parameters used when making a delivery plan. When the default setting button 903 is pressed, the screen changes to a setting screen 1000 shown in FIG. 10.
  • FIG. 10 shows a configuration example of a settings screen 1000 for setting various parameters used when making a delivery plan.
  • the input form 1001 is an item for setting the maximum calculation time based on the current time.
  • a delivery plan is generated with the maximum time specified in the input form 1001. Normally, it takes a certain amount of processing time to generate a delivery plan, so set an upper limit here. If the upper limit is exceeded, the delivery plan generation process will be aborted and the processing at that point will be stopped. Let the solution be the delivery plan.
  • the input form 1002 is an item for setting the maximum mesh width of a unit area (ie, unit area) in a mesh. In this embodiment, a rectangular unit area with the same size in both length and width is used.
  • Input forms 1001 and 1002 may be configured to allow text input, for example.
  • the input form 1003 is an item for specifying parameters to be leveled.
  • the "number of deliveries” was used as an example of the leveling target.
  • the target of leveling is not limited to this.
  • “number of deliveries”, “number of deliveries (unit area)”, “delivery distance”, “delivery time”, etc. may be used as the leveling target.
  • “delivery distance”, “delivery time”, etc. may be used in combination with “number of deliveries” or “number of deliveries (unit area)”. Therefore, the input form 1003 may be configured to display these as a list and accept them.
  • Number of deliveries refers to the case where the number of deliveries before aggregation is the target of leveling
  • “Number of deliveries (unit area)” refers to the case where the number of deliveries after aggregation is the target of leveling. Point.
  • the input form 1004 is an item for specifying the allowable value of the difference (shift) of each allocation when leveling is performed, and the selectable values are switched according to the settings specified in the input form 1003. It will be done. For example, if “number of deliveries” or “number of deliveries (unit area)" is specified in the input form 1003, the input form 1004 displays a list of "5 items,” “10 items,” “15 items,” etc. It may be configured so that it can be accepted. Similarly, when “delivery distance” is specified in the input form 1003, the input form 1004 may be configured to display a list of "5 km,” “10 km,” “15 km,” etc., and accept the request.
  • the input form 1004 may be configured to display a list of "5 minutes,” “10 minutes,” “15 minutes,” etc., so that it can be accepted. .
  • the allowable value may be configured to be settable as a ratio (such as “5%”, “10%”, “15%”, etc.).
  • the allowable value may be the difference between the delivery person with the maximum allocation and the delivery person with the smallest allocation.
  • the enter button 1005 is a button for confirming each setting value input on the setting screen 1000 as a default setting.
  • a cancel button 1006 is a button for canceling each setting value input on the setting screen 1000. When the enter button 1005 and the cancel button 1006 are pressed, the screen may be configured to transition to the setting screen 900.
  • FIG. 11 shows a configuration example of a setting screen 1100 for performing leveling.
  • the 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 the input form 1001 in FIG. 10, the delivery plan generation process is executed using the time specified here as the maximum processing time.
  • the input form 1103 is an item that displays the number of people to be delivered, that is, the number of people to whom leveling is to be performed.
  • the delivery person list 1104 displays information regarding delivery persons in a list format, and is configured so that input can be made for each item.
  • the item "No.” indicates identification information for uniquely identifying the person in charge of delivery.
  • the item "person in charge” indicates the name of the person in charge of delivery.
  • the item “Delivery Skill” indicates the delivery skill of the delivery person, and here it is set that the larger the value is, the more skilled the delivery person is. Furthermore, the item “Delivery Skill” may be configured to be switchable between display and non-display.
  • the item “Shift” indicates the time period in which each delivery person works. Although shown here in units of one hour, it may be configured so that it can be displayed in larger or smaller periods. Furthermore, the item “shift” may be configured to display additional time periods by switching the display range using a slide bar or the like.
  • the item “Delivery” is an item for specifying the person in charge of delivery who is to be leveled, and is checked if selected. The number of delivery personnel selected here is displayed on an input form 1103.
  • the item “delivery ratio” is an item for specifying the delivery ratio to be assigned to each of the selected delivery persons. The total delivery ratio is 100 (%).
  • the setting item 1105 is an item for displaying the delivery forecast period as the leveling result.
  • “delivery”, “today”, “this week”, “this month”, and any period can be set.
  • the "number of deliveries”, “working hours”, and “delivery distance” for each delivery person this month are displayed in a graph as a result of the leveling. Displayed at 1107, 1108, and 1109. If the period includes the past, a portion of it will be aggregated as actual results.
  • leveling processing and graph 1107 are performed only for the delivery destination data specified in the input form 901 of the setting screen 900. , 1108, and 1109 are displayed. In this case, only the delivery persons selected in the delivery persons list 1104, that is, those who are the targets of leveling, may be displayed in the graph.
  • FIG. 12 shows an example of the configuration of data related to delivery by each delivery person.
  • the data here includes the items “ID”, “delivery start time”, “delivery end time”, “person in charge”, “delivery time”, “distance”, and “number of items”.
  • This data may be historical data if the item has been delivered, or may be configured as scheduled data if the item has not been delivered. When “today”, “this week”, “this month”, or any period is selected in the setting item 1105, it is used when tabulating the graph as the result.
  • This data may be updated at appropriate times, such as when a delivery destination is assigned or when delivery is completed, and may be managed in the delivery information DB 122, the person in charge information DB 123, or the like.
  • the structure of the history data is an example, and is not limited to this. For example, other items may be included as long as the data is necessary for generating a graph.
  • FIG. 13 shows a configuration example of a UI screen showing the result of the leveling process according to this embodiment when "Delivery" is selected in the setting item 1105 and the leveling button 1106 is pressed.
  • FIG. 13A shows an example of a UI screen 1300 that is displayed when the leveling is successfully performed as a result of the leveling process.
  • FIG. 13(b) shows an example of a UI screen 1310 that is displayed when leveling is not performed normally as a result of the leveling process.
  • Leveling target Number of cases (actual number of deliveries) Delivery person: 2 people (Delivery person A, Delivery person B) Maximum calculation time: 30 minutes Mesh width: 100m Error: 2 items
  • the error in the number of cases leveled and assigned to each delivery person is 1 case, which is less than 2 cases, which is the parameter for leveling. There is. Therefore, the leveling is displayed as having been performed normally.
  • a decision button 1302 is a button that is pressed when the current leveling result is adopted.
  • a recalculation button 1303 is a button that is pressed to perform the leveling process again.
  • the error in the number of cases leveled and assigned to each delivery person is 4 cases, which is the parameter for leveling 2 or more cases. It has become. Therefore, the leveling is displayed as not being performed normally. Furthermore, the calculation time is 30 minutes, which is the same value as the leveling parameter of 30 minutes, indicating that the leveling process was aborted midway.
  • a decision button 1312 is a button that is pressed when the current leveling result is adopted.
  • the recalculation button 1313 is a button that is pressed to perform the leveling process again.
  • UI screen 1400 for displaying the results of the leveling process, and are, for example, screens displayed on the UI unit 130 of the delivery plan generation device 100 operated by the administrator. .
  • the OK button is pressed on any of the UI screens in FIG. 13, the screen may transition to the UI screen 1400.
  • FIG. 14 shows a display example (normal mode) in which delivery destinations are individually shown in a mesh unit area.
  • a broken line 1402 indicating the unit area of the set mesh is superimposed on a map 1401.
  • Assignment information 1403 indicates the result of the leveling process for each delivery person (in this example, two delivery persons A and B).
  • the confirm button 1404 is a button that is pressed when confirming the leveling result and notifying each delivery person.
  • a recalculation button 1405 is a button that is pressed to perform the leveling process again.
  • the mode switching button 1406 is a button for switching to the display example (mesh mode) shown in FIG. 15.
  • an icon 1407 indicates the location of the delivery person.
  • the position of the icon 1407 may also 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, by operating the icon 1408, corresponding more detailed delivery information (eg, delivery address, etc.) may be displayed. The numbers within the icon 1408 indicate the order of delivery.
  • Icon 1409 like icon 1408, indicates the location of the delivery destination, and since it is assigned to a different delivery person here, it has a display format different from hatching (in this example, it is outlined).
  • FIG. 15 shows a display example (mesh mode) in which the mesh is aggregated for each unit area. Totalizes and shows the delivery destinations belonging to each unit area.
  • a solid line 1502 indicating the set mesh is shown superimposed on a map 1501.
  • Assignment information 1503 indicates the results of the leveling process for each delivery person (in this example, two delivery persons A and B).
  • a confirm button 1504 is a button that is pressed when confirming the leveling result and notifying each delivery person.
  • a recalculation button 1505 is a button that is pressed to perform the leveling process again.
  • the mode switching button 1506 is a button for switching to the display example (normal mode) shown in FIG. 14.
  • an icon 1507 indicates the location of the delivery person.
  • the position of the icon 1507 may also change as the delivery person (more specifically, the client terminal 200) moves.
  • Icon 1508 indicates the total result of delivery destinations belonging to the unit area (indicated by "(x)") and delivery order, and is displayed with hatching. For example, by operating the icon 1508, a list of corresponding more detailed delivery information (eg, delivery address, etc.) may be displayed.
  • the icon 1509 indicates the location of the delivery destination, and since it is assigned to a different delivery person here, it has a different display format (in this example, it is outlined).
  • 16 and 17 are configuration examples of UI screens for displaying the results of the leveling process, and are, for example, screens displayed on the UI section 204 of the client terminal 200 operated by delivery person A.
  • the UI screen 1600 shown in FIG. 16 is also referred to as a first screen
  • the UI screen 1700 shown in FIG. 17 is also referred to as a second screen.
  • first and second are only used to distinguish and explain different components, and should not be interpreted to be limited to specific components. is not intended.
  • the OK button is pressed on any of the UI screens in FIG. 13, the UI screen 1600 is displayed by notifying the client terminal 200 owned by delivery person A of the delivery plan as the leveling result. It's okay to be.
  • FIG. 16 shows an example (normal mode) in which delivery destinations assigned to delivery person A are individually displayed.
  • a broken line 1602 indicating the set mesh is shown superimposed on a map 1601.
  • Assignment information 1603 indicates information regarding delivery assigned to delivery person A. The information here includes the number of deliveries, mileage, estimated time required for delivery, etc.
  • the mode switching button 1604 is a button for switching to the display example (mesh mode) shown in FIG. 17.
  • an icon 1605 indicates the position of delivery person A.
  • the position of the icon 1605 may also change as the delivery person A (more specifically, the client terminal 200) moves.
  • Icon 1606 indicates the location of the delivery destination. For example, by operating the icon 1606, corresponding more detailed delivery information (eg, delivery address, etc.) may be displayed.
  • the numbers within the icon 1606 indicate the order of delivery.
  • Delivery route 1607 indicates a delivery route for each assigned delivery destination. This route is derived based on the delivery cost as described above.
  • FIG. 17 shows a display example (mesh mode) in which the mesh is aggregated for each unit area. Totalizes and shows the delivery destinations belonging to each unit area.
  • a solid line 1702 indicating the set mesh is shown superimposed on a map 1701.
  • Assignment information 1703 indicates information regarding delivery assigned to delivery person A. The information here includes the number of deliveries, mileage, estimated time required for delivery, etc.
  • the mode switching button 1704 is a button for switching to the display example (normal mode) shown in FIG. 16.
  • an icon 1705 indicates the position of delivery person A.
  • the position of the icon 1705 may also change as the delivery person A (more specifically, the client terminal 200) moves.
  • Icon 1706 indicates the total result of delivery destinations belonging to the unit area (indicated by "(x)") and the order of delivery. For example, by operating the icon 1706, a list of corresponding more detailed delivery information (eg, delivery address, etc.) may be displayed.
  • the delivery plan generation device 100 is capable of generating delivery routes for each of a plurality of persons in charge identified by connecting unit areas including one or more delivery destinations, and for each of the plurality of persons in charge.
  • a settings screen (for example, settings screen 900, settings screen) that allows the user to input setting items used when generating delivery routes for each of multiple personnel by repeatedly performing the process of leveling the deliveries included in the delivery route 1000 and a setting screen 1100).
  • the setting screen 1000 is configured to allow specification of the maximum calculation time for repeating the process of generating a delivery route and leveling the delivery.
  • the setting screen 1000 is configured to allow the size of the unit area to be specified.
  • the setting screen 1000 is configured to allow designation of targets for delivery leveling.
  • the target of delivery leveling is the number of deliveries, delivery distance, or delivery time.
  • the setting screen 1000 is configured to allow specification of a tolerance value for the difference in delivery leveling.
  • the screen generation unit 114 further provides a setting screen 1100 on which at least the person in charge to whom the delivery destination is assigned and the period can be set.
  • the setting screen 1100 is configured to be able to display the total value of the leveling results for each of the plurality of persons in charge for each leveling item.
  • the screen generation unit 114 further provides a UI screen 1600 that displays delivery routes for multiple delivery destinations assigned to the person in charge, superimposed on a map of the delivery range.
  • the screen generation unit 114 further provides a UI screen 1700 that displays the total number of delivery destinations assigned to the person in charge for each unit area superimposed on a map of the delivery range.
  • the present disclosure also applies to programs and storage media that are supplied to the device via a network or various storage media to realize the functions of the device of the embodiments described above, and that are read and executed by a computer in the device. range.
  • the present disclosure effectively supports the formulation of an optimal package delivery plan according to the road conditions to the delivery destination when delivering multiple packages, and significantly reduces the burden on the delivery personnel who deliver each package. It is useful as a delivery plan generation device and a delivery plan generation method that reduce the amount of money.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Marketing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Development Economics (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Game Theory and Decision Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

配送範囲を所定の単位エリアに区切って、物品の配送先が割り当てられる複数の担当者それぞれの配送ルートの生成を行う配送計画生成装置は、１つ以上の配送先が含まれる単位エリアを繋いで特定される前記複数の担当者それぞれの配送ルートの生成と、当該複数の担当者それぞれの配送ルートに含まれる配送を平準化する処理とを繰り返し実行して前記複数の担当者それぞれの配送ルートを生成する際に用いられる設定項目をユーザに入力させる設定画面を提供する提供部を有する。

Description

配送計画生成装置、および配送計画生成方法
　本開示は、配送対象となる複数の荷物の配送を支援する配送計画生成装置、および配送計画生成方法に関する。
　商品の配送計画を行う先行技術として、例えば、特許文献１が挙げられる。特許文献１では、配送範囲をメッシュ法を利用して網目で分け、網目を最短距離条件を用いて一筆書きで繋げることで最適配送ルートを生成する方法が開示されている。
日本国特開平１０－１３４３００号公報
　本開示は、上述した従来の状況に鑑みて案出され、荷物の配送ルートを配送担当者間で平準化することで、配送の全体の実行時間を抑えつつ、配送担当者の作業負荷の偏りを抑制する配送計画を生成する配送計画生成装置、および配送計画生成方法を提供することを目的とする。
　本開示は、配送範囲を所定の単位エリアに区切って、物品の配送先が割り当てられる複数の担当者それぞれの配送ルートの生成を行う配送計画生成装置であって、１以上の配送先が含まれる単位エリアを繋いで特定される前記複数の担当者それぞれの配送ルートの生成と、当該複数の担当者それぞれの配送ルートに含まれる配送を平準化する処理とを繰り返し実行して前記複数の担当者それぞれの配送ルートを生成する際に用いられる設定項目をユーザに入力させる設定画面を提供する提供部を有する、配送計画生成装置を提供する。
　また、本開示は、配送範囲を所定の単位エリアに区切って、物品の配送先が割り当てられる複数の担当者それぞれの配送ルートの生成を行う配送計画生成方法であって、プロセッサとメモリが協働して、１以上の配送先が含まれる単位エリアを繋いで特定される前記複数の担当者それぞれの配送ルートの生成と、当該複数の担当者それぞれの配送ルートに含まれる配送を平準化する処理とを繰り返し実行して前記複数の担当者それぞれの配送ルートを生成する際に用いられる設定項目をユーザに入力させる設定画面を提供する、配送計画生成方法を提供する。
　本開示によれば、荷物の配送ルートを配送担当者間で平準化して、配送の全体の実行時間を抑えつつ、配送担当者の作業負荷の偏りを抑制する配送計画を生成することが可能となる。
本発明の実施の形態１に係るシステム構成の例を示すブロック図 本発明の実施の形態１に係るメッシュを説明するための概念図 本発明の実施の形態１に係る配送計画の集約を説明するための概念図 本発明の実施の形態１に係る配送計画の手法を説明するための説明図 本発明の実施の形態１に係る配送計画の手法を説明するための説明図 本発明の実施の形態１に係る配送計画の手法を説明するための説明図 本発明の実施の形態１に係る配送計画生成処理のフローチャート 本発明の実施の形態１に係る配送計画算出処理のフローチャート 本発明の実施の形態１に係る配送計画生成装置のＵＩ画面の構成例を示す図 本発明の実施の形態１に係る配送計画生成装置のＵＩ画面の構成例を示す図 本発明の実施の形態１に係る配送計画生成装置のＵＩ画面の構成例を示す図 本発明の実施の形態１に係る配送計画生成装置にて用いられるデータ構成の例を示す図 本発明の実施の形態１に係る配送計画生成装置のＵＩ画面の構成例を示す図 本発明の実施の形態１に係る配送計画生成装置のＵＩ画面の構成例を示す図 本発明の実施の形態１に係る配送計画生成装置のＵＩ画面の構成例を示す図 本発明の実施の形態１に係る配送計画生成装置のＵＩ画面の構成例を示す図 本発明の実施の形態１に係る配送計画生成装置のＵＩ画面の構成例を示す図
（各実施の形態の内容に至る経緯）
　上述した特許文献１では、メッシュ法を利用した単位エリアを対象として配送ルートの決定や必要な配送車両の車種や台数等の決定を自動的に行うことで配送コストの低減や配送の効率化を実現している。しかしながら、複数の配送担当者において、その作業負荷の偏りが生じ、その作業負荷の平準化を行うことまでは考慮されていない。実際の現場では、膨大な物品の配送を複数の配送担当者（ドライバ）で分担することになり、所定の配送範囲の最適配送ルートだけでは、ドライバごとの配送ルートの決定および各ドライバの配送件数量などを平準化することはできなかった。特に、メッシュの単位エリア内に何件の配送先が含まれるかは、状況に応じて異なるため、平準化の精度が低下してしまう。また、特許文献１では、各配送担当者が実際に配送を行う際に利用可能なＵＩ画面などの利便性までは考慮されていない。
　また、各配送担当者のスケジュールやスキル、過去の作業実績などを考慮して配送計画を行うことまでは考慮されていなかった。そのため、ある時点での配送ルートを算出することは可能であるが、過去の作業実績などを反映させた作業分担までは特許文献１では実現できていなかった。
　そこで、以下の実施の形態では、配送担当者の作業を平準化し、配送の全体の実行時間を抑えつつ、配送担当者の作業負荷の偏りを抑制した配送計画を生成することが可能な配送計画生成装置、および配送計画生成方法の例を説明する。
　以下、適宜図面を参照しながら、本開示に係る配送計画生成装置、および配送計画生成方法を具体的に開示した各実施の形態を詳細に説明する。但し、必要以上に詳細な説明は省略する場合がある。例えば、既によく知られた事項の詳細説明や実質的に同一の構成に対する重複説明を省略する場合がある。これは、以下の説明が不必要に冗長になるのを避け、当業者の理解を容易にするためである。なお、添付図面及び以下の説明は、当業者が本開示を十分に理解するために提供されるのであって、これらにより特許請求の範囲に記載の主題を限定することは意図されていない。
＜実施の形態１＞
　以下、本発明の実施の形態１として、複数の荷物を配送する時の配送計画を策定（生成）する例について説明する。なお、本実施の形態において、配送計画とは、所定の期間内（例えば当日である１日の間）に、少なくとも１台の配送車両（例えば、トラック）を用いて、拠点から複数の配送先に荷物（物品）を配送する際の配送ルートの計画である。配送ルートは、複数ある配送先の走行順序に相当する。配送計画を生成する場合、例えば、道路コストに基づいて、その配送コストを下げるように決定される。
［装置構成］
　本実施の形態に係る配送計画生成装置１００は、ネットワーク３００を介して１または複数のクライアント端末２００と通信可能に接続される。なお、配送計画生成装置１００は、配送業者の拠点にてオンプレミス型のサーバ装置として構成されてもよいし、ネットワーク上にてクラウド型にて構成されてもよい。
　配送計画生成装置１００は、処理部１１０、記憶部１２０、ＵＩ（Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）部１３０、および通信部１４０を含んで構成される。処理部１１０は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）、ＧＰＵ（Ｇｒａｐｈｉｃａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）、ＭＰＵ（Ｍｉｃｒｏ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）、ＤＳＰ（Ｄｉｇｉｔａｌ　Ｓｉｇｎａｌ　Ｐｒｏｃｅｓｓｏｒ）、またはＦＰＧＡ（Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）などを用いて構成されるプロセッサであってよい。処理部１１０は、例えば、記憶部１２０に記憶された各種データベース（以下、ＤＢ）を参照したり、プログラムを読み出したりすることで、後述する各種機能を実現する。記憶部１２０は、各種データやプログラムなどを記憶するための記憶部であり、例えば、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）などの揮発性／不揮発性の記憶装置から構成されてよい。
　ＵＩ部１３０は、配送計画生成装置１００の利用者による操作を受け付けたり、各種情報を出力したりするための部位である。ＵＩ部１３０は、ディスプレイやマウス、キーボードなどから構成されてもよい。通信部１４０は、ネットワーク３００を介して外部装置と通信するためのインタフェースである。通信部１４０にて対応可能な通信規格は特に限定するものではなく、有線／無線も問わない。また、複数の通信規格に対応可能であってもよい。
　クライアント端末２００は、配送担当者が配送作業の際に利用可能な端末装置であって、例えば、スマートフォンやタブレット端末、ＰＯＳ端末などのモバイル端末であってよい。また、クライアント端末２００は、配送の際に利用する配送車両（以下、単に「車両」とも称する）などに備え付けられていてもよい。クライアント端末２００は、処理部２０１、記憶部２０２、通信部２０３、ＵＩ部２０４、およびセンサ部２０５を含んで構成される。
　処理部２０１は、例えば、ＣＰＵ、ＧＰＵ、ＭＰＵ、ＤＳＰ、またはＦＰＧＡなどを用いて構成されてよい。処理部２０１は、例えば、記憶部２０２に記憶された各種データを参照したり、プログラムを読み出したりすることで、後述する各種機能を実現する。記憶部２０２は、各種データやプログラムなどを記憶するための記憶部であり、例えば、ＲＡＭ、ＲＯＭ、ＨＤＤ、フラッシュメモリ、またはＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）などの揮発性／不揮発性の記憶装置から構成されてよい。
　通信部２０３は、ネットワーク３００を介して外部装置と無線通信するためのインタフェースである。通信部２０３にて対応可能な通信規格は特に限定するものではない。センサ部２０５は、クライアント端末２００の状態情報を検出するための１または複数のセンサから構成され、例えば、ＧＰＳ（Ｇｌｏｂａｌ　Ｐｏｓｉｔｉｏｎｉｎｇ　Ｓｙｓｔｅｍ）に代表されるＧＮＳＳ（Ｇｌｏｂａｌ　Ｎａｖｉｇａｔｉｏｎ　Ｓａｔｅｌｌｉｔｅ　Ｓｙｓｔｅｍ）による位置センサ、磁気センサ、加速度センサ、撮影装置であるカメラなどを含んで構成されてよい。
　本実施の形態において配送計画生成装置１００の処理部１１０は、道路コスト算出部１１１、配送コスト生成部１１２、配送計画算出部１１３、画面生成部１１４、ＤＢ管理部１１５、およびデータ連携部１１６を実装する。なお、機能ブロックの構成は一例であり、１のブロックの機能を更に詳細に分割してもよいし、複数のブロックの機能をまとめて構成してもよい。
　道路コスト算出部１１１は、配送ルートとして利用される道路のコストを算出する。配送コスト生成部１１２は、道路コストや配送対象の荷物のサイズなどに基づき、配送コストを算出する。配送計画算出部１１３は、配送コストや道路コストに基づき、荷物の配送計画を算出する。画面生成部１１４は、配送計画生成装置１００やクライアント端末２００に提供する各種ＵＩ画面を生成する。ＤＢ管理部１１５は、記憶部１２０に構成された各種ＤＢの更新や管理を行う。データ連携部１１６は、配送計画に必要な各種情報を外部装置（クライアント端末２００やその他の外部装置）から取得したり、提供したりする。
　本実施の形態において、配送計画生成装置１００の記憶部１２０は、道路情報ＤＢ１２１、配送情報ＤＢ１２２、および担当者情報ＤＢ１２３を有する。なお、ＤＢの構成は一例であり、１のＤＢを更に詳細に分割してもよいし、複数のＤＢをまとめて構成してもよい。
　道路情報ＤＢ１２１は、配送エリアの道路情報や地図情報を管理するためのデータベースである。道路情報や地図情報は、例えば、外部の地図サーバ（不図示）にアクセスして、最新の情報を取得することで更新されてよい。道路情報には、道路の形状の他、渋滞状況や通行可否の情報、過去の走行履歴などが含まれてもよい。これらの情報に基づいて、各道路のコストが定義される。配送情報ＤＢ１２２は、配送対象となる荷物の配送情報を管理するためのデータベースである。配送情報には、配送先、配送元、配送拠点、配送日時などが含まれてよい。担当者情報ＤＢ１２３は、配送担当者の情報を管理するためのデータベースである。担当者情報には、割り当てられた配送、担当者の配送履歴、勤務スケジュール、配送途中における現在位置、担当者の配送スキルなどが含まれてよい。
　なお、クライアント端末２００から配送計画生成装置１００を利用する場合、クライアント端末２００が有するＷｅｂブラウザ（不図示）を用いて配送計画生成装置１００へアクセスしてもよいし、クライアント端末２００にインストールされた配送計画生成装置１００に対応するアプリケーションを起動することで利用してもよい。また、配送計画生成装置１００とクライアント端末２００の機能の分担は、図１の構成に限定するものではなく、配送計画生成装置１００の機能の一部をクライアント端末２００側で実施させるような構成であってもよい。
［メッシュによる集約］
　図２は、本実施の形態に係るメッシュによる集約を説明するための図である。図２（ａ）のメッシュ２１０は集約前の状態を示し、図２（ｂ）のメッシュは集約後の状態を示す。ここでは、地図上に設定される６×６のメッシュ（計３６個の単位エリア）の例を示す。なお、メッシュの１つの単位エリアの縦横のサイズは特に限定するものではなく、任意の矩形の値が設定されてよい。図２において、１つの丸は、１つの配送先を示す。図２（ａ）において、単位エリア２１１には３つの配送先が含まれる。また、単位エリア２１２には２つの配送先が含まれる。集約では、１つの単位エリアに含まれる複数の配送先が含まれている場合に、単位エリアごとに配送先をまとめる（集約する）。例えば、図２（ａ）の単位エリア２１１は、３つの配送先を集約することで、図２（ｂ）の単位エリア２２１のようになる。図２において、集約された配送先は四角にて示している。同様に、図２（ａ）の単位エリア２１２は、２つの配送先を集約することで、図２（ｂ）の単位エリア２２２のようになる。これにより、経路生成上の際の扱いを簡略化し、処理負荷を軽減することが可能となる。
　図３は、本実施の形態に係るメッシュおよび経路生成の例を示す図である。図２と同様、地図上に設定される６×６のメッシュの例を示す。図３（ａ）は、集約前の状態を示す。図３においての黒三角にて示す位置は、荷物の配送拠点（以下、単に「拠点」とも称する）を示す。また、その周辺に複数の配送先が丸にて示されている。ここでは、３つの種類の丸（実線、太線、破線）にて分類し、実線の丸が６個、太線の丸が５個、破線の丸が５個である例を示している。この３種類の丸は、３人の配送担当者それぞれの分担状況（割り当て）を示している。
　図３（ｂ）は、図３（ａ）のメッシュを２×２の単位エリアで調整した例を示している。この場合、３×３のメッシュとなる。図３（ｂ）において、２×２の単位エリアそれぞれに属する配送先の数が示されている。
　図３（ｃ）は、図３（ｂ）の状態から、２×２の単位エリアにて配送先を集約した状態を示す。集約した状態を白三角にて示している。ここで集約した際の地図上の位置は、各配送先の中心位置であってもよいし、単位エリアの中心位置であってもよい。更に、図３（ｃ）において、配送拠点を起点として、集約された位置に対する配送経路を矢印にて示している。ここでは、最後の配送先から配送拠点までの戻りの経路は省略している。
　図３（ｄ）は、図３（ａ）の状態、すなわち、６×６のメッシュにおける１×１の単位エリアにて配送先を集約し、更に、配送拠点を起点として、集約された位置に対する配送経路を矢印にて示している。ここでは、最後の配送先から配送拠点までの戻りの経路は省略している。
［配送計画］
　本実施の形態では、配送計画の初期解を導出し、更にその初期解に対して３種類の改善方法および配送コストの最適化を適用することで、より適切な配送計画を決定する。配送コストの最適化は、例えば、２つの配送先間の走行経路を変更することで、配送コストを削減することが挙げられる。より具体的には、道路ごとにコスト（道路コスト）が異なるため、ある配送先から他の配送先へ向かう際に、どの道路を走行するかによって配送コストが異なる。いずれの道路を走行するかは、例えば、熟練ドライバの走行履歴に基づいて機械学習を行うことで決定されてもよいし、予め設定された道路コストに基づいて、公知のダイクストラ法により決定されてもよい。
　また、本実施の形態に係る配送計画の改善方法として、「置換」、「交換」、「移管」を例に挙げて説明する。置換は、配送先の順序を入れ替える処理である。交換は、複数の配送ルートの間で配送先を入れ替える処理である。移管は、別の配送ルートに配送先を移す処理である。図４の説明図に基づき、置換、交換、移管の具体例について、以下に説明する。なお、各配送先から経路が２ルートある場合、コストが高い方の経路が点線、コストが低い方の経路が実線で表している。
　（置換）
　パターン１において、１台の配送車両により、拠点Ｓ→配送先Ｄ１→配送先Ｄ２→配送先Ｄ３→配送先Ｄ４の配送順で配送が行われる配送計画を設定する。この場合、配送コスト（言い換えると、距離）は、「１０＋１０＋１０＝３０」である。
　一方、パターン１において、１台の配送車両により、拠点Ｓ→配送先Ｄ１→配送先Ｄ３→配送先Ｄ２→配送先Ｄ４の配送順で配送が行われる置換が行われた配送計画を設定する。この場合、配送コストは、「１５＋１０＋１５＝４０」である。したがって、置換前よりも大きい配送コストとなり、配送計画の解としては採用しない。
　また、パターン２において、１台の配送車両により、拠点Ｓ→配送先Ｄ１→配送先Ｄ２→配送先Ｄ３→配送先Ｄ４の配送順で配送が行われる配送計画を設定する。この場合、配送コストは、「１０＋１０＋１０＝３０」である。
　一方、パターン２において、１台の配送車両により、拠点Ｓ→配送先Ｄ１→配送先Ｄ３→配送先Ｄ２→配送先Ｄ４の配送順で配送が行われる置換が行われた配送計画を設定する。この場合、配送コストは、「５＋１０＋５＝２０」である。したがって、配送コストを削減することができ、配送計画の解として採用される。
　（交換）
　パターン３において、１台目の配送車両に対し、拠点Ｓ→配送先Ｄ１→配送先Ｄ２→配送先Ｄ３→配送先Ｄ４の配送順で配送が行われる配送計画を設定する。また、２台目の配送車両に対し、拠点Ｓ→配送先Ｄ５→配送先Ｄ６→配送先Ｄ７→配送先Ｄ８の配送順で配送が行われる配送計画を設定する。この配送計画の場合、１台目の配送車両の配送コストは「１０＋１０＋０＝２０」となり、２台目の配送車両の配送コストは「１０＋１０＋０＝２０」となる。このとき、２台の配送車両の配送コストの総和は「２０＋２０＝４０」となる。
　一方、パターン３において、１台目の配送車両に対し、拠点Ｓ→配送先Ｄ１→配送先Ｄ６→配送先Ｄ３→配送先Ｄ４の配送順で配送が行われる配送計画を設定する。また、２台目の配送車両に対し、拠点Ｓ→配送先Ｄ５→配送先Ｄ２→配送先Ｄ７→配送先Ｄ８の配送順で配送が行われる配送計画を設定する。この配送計画の場合、１台目の配送車両の配送コストは「１５＋１０＋０＝２５」となり、２台目の配送車両の配送コストは「１０＋１０＋０＝２０」となる。このとき、２台の配送車両の配送コストの総和は「２０＋２５＝４５」となる。そのため、交換前よりも大きい配送コストとなり、配送計画の解としては採用しない。
　また、パターン４において、１台目の配送車両に対し、拠点Ｓ→配送先Ｄ１→配送先Ｄ２→配送先Ｄ３→配送先Ｄ４の配送順で配送が行われる配送計画を設定する。また、２台目の配送車両に対し、拠点Ｓ→配送先Ｄ５→配送先Ｄ６→配送先Ｄ７→配送先Ｄ８の配送順で配送が行われる配送計画を設定する。この配送計画の場合、１台目の配送車両の配送コストは「１０＋１０＋０＝２０」となり、２台目の配送車両の配送コストは「１０＋１０＋０＝２０」となる。このとき、２台の配送車両の配送コストの総和は「２０＋２０＝４０」となる。
　一方、パターン４において、１台目の配送車両に対し、拠点Ｓ→配送先Ｄ１→配送先Ｄ６→配送先Ｄ３→配送先Ｄ４の配送順で配送が行われる配送計画を設定する。また、２台目の配送車両に対し、拠点Ｓ→配送先Ｄ５→配送先Ｄ２→配送先Ｄ７→配送先Ｄ８の配送順で配送が行われる配送計画を設定する。この配送計画の場合、１台目の配送車両の配送コストは「５＋１０＋０＝１５」となり、２台目の配送車両の配送コストは「１０＋１０＋０＝２０」となる。このとき、２台の配送車両の配送コストの総和は「１５＋２０＝３５」となる。したがって、配送コストを削減することができ、配送計画の解として採用される。
　（移管）
　パターン５において、１台目の配送車両に対し、拠点Ｓ→配送先Ｄ１→配送先Ｄ２→配送先Ｄ３→配送先Ｄ４の配送順で配送が行われる配送計画を設定する。また、２台目の配送車両に対し、拠点Ｓ→配送先Ｄ５→配送先Ｄ６→配送先Ｄ７→配送先Ｄ８の配送順で配送が行われる配送計画を設定する。このパターン５の場合、１台目の配送車両の配送コストは「１０＋１０＋０＝２０」となり、２台目の配送車両の配送コストは「１０＋１０＋０＝２０」となる。このとき、２台の配送車両の配送コストの総和は「２０＋２０＝４０」となる。
　一方、パターン５において、１台目の配送車両に対し、拠点Ｓ→配送先Ｄ１→配送先Ｄ３→配送先Ｄ４の配送順で配送が行われる配送計画を設定する。また、２台目の配送車両に対し、拠点Ｓ→配送先Ｄ５→配送先Ｄ６→配送先Ｄ２→配送先Ｄ７→配送先Ｄ８の配送順で配送が行われる配送計画を設定する。このパターン５の場合、１台目の配送車両の配送コストは「２５＋０＝２５」となり、２台目の配送車両の配送コストは「１０＋１０＋１０＋０＝３０」となる。このとき、２台の配送車両の配送コストの総和は「２５＋３０＝５５」となる。そのため、移管前よりも大きい配送コストとなり、配送計画の解としては採用しない。
　また、パターン６において、１台目の配送車両に対し、拠点Ｓ→配送先Ｄ１→配送先Ｄ２→配送先Ｄ３→配送先Ｄ４の配送順で配送が行われる配送計画を設定する。また、２台目の配送車両に対し、拠点Ｓ→配送先Ｄ５→配送先Ｄ６→配送先Ｄ７→配送先Ｄ８の配送順で配送が行われる配送計画を設定する。このパターン６の場合、１台目の配送車両の配送コストは「１０＋１０＋０＝２０」となり、２台目の配送車両の配送コストは「１０＋１０＋０＝２０」となる。このとき、２台の配送車両の配送コストの総和は「２０＋２０＝４０」となる。
　一方、パターン６において、１台目の配送車両に対し、拠点Ｓ→配送先Ｄ１→配送先Ｄ３→配送先Ｄ４の配送順で配送が行われる配送計画を設定する。また、２台目の配送車両に対し、拠点Ｓ→配送先Ｄ５→配送先Ｄ６→配送先Ｄ２→配送先Ｄ７→配送先Ｄ８の配送順で配送が行われる配送計画を設定する。このパターン６の場合、１台目の配送車両の配送コストは「５＋０＝５」となり、２台目の配送車両の配送コストは「１０＋１０＋１０＋０＝３０」となる。このとき、２台の配送車両の配送コストの総和は「５＋３０＝３５」となる。したがって、配送コストを削減することができ、配送計画の解として採用される。
（従来手法によるメッシュでの課題）
　図５は、従来手法によるメッシュでの改善（ここでは、移管）の流れを説明するための概念図である。図５の左から順に処理が進むものとして説明する。ここでは２台の車両Ａ、Ｂを例に挙げ、車両Ａにはメッシュ数が３つの配送先（「１」～「３」）が割り当てられ、車両Ｂにはメッシュ数が５つの配送先（「４」～「８」）が割り当てられている。ここでは、１台の車両に１人の配送担当者が対応しているものとする。このとき、各配送先は、メッシュの単位エリアにて集約された状態のものを示している。また、矢印は配送順を示している。
　本例において、配送先「８」が車両Ｂから車両Ａへ移管されたとする。このとき、車両Ａでは、配送先「３」の次に配送先「８」が来るように配送順を設定したとする。この状態では、一見すると、車両Ａ、Ｂいずれもメッシュ数が４つずつの割り当てが行われており、配送先が平準化されているように考えられる。しかし、配送先はメッシュの単位エリアで集約された結果であるため、本例の場合の実配送件数（配送先の総和）は、車両Ａが４件、車両Ｂが６件となり、平準化は十分に行われていない。なお、ここでは移管を例に挙げて説明したが、交換についても同様の課題が生じ得る。
（本実施の形態の手法によるメッシュでの改善）
　上記のようなメッシュでの平準化の課題を鑑み、本実施の形態では、メッシュにて集約された配送先の件数を考慮して改善を行う。図６は、本実施の形態に係る手法によるメッシュでの移管の流れを説明するための概念図である。
　図６の左から順に処理が進むものとして説明する。ここでは２台の配送車両Ａ、Ｂを例に挙げ、配送車両Ａにはメッシュ数が３つの配送先（「１」～「３」）が割り当てられ、車両Ｂにはメッシュ数が５つの配送先（「４」～「８」）が割り当てられている。このとき、各配送先は、メッシュの単位エリアにて集約された状態のものを示している。また、矢印は配送順を示している。配送先の横には、集約前の配送先の件数を示している。したがって、実際には、車両Ａには３件の配送先が割り当てられており、車両Ｂには７件の配送先が割り当てられている。
　本例において、配送先、「７」および配送先「８」を車両Ｂから車両Ａへ移管する。このとき、車両Ａでは、配送先「３」の次に配送先「７」、その次に配送先「８」が来るように配送順を設定する。この状態では、一見すると、車両Ａには配送先が５つのメッシュ数、車両Ｂには配送先が３つのメッシュ数が割り当てられ、平準化が行われていないようにも考えられる。しかし、集約前の件数で考えると、本例の場合の実配送件数（配送先の総和）は、車両Ａ、Ｂもいずれも配送先が５件となり、平準化が行われている。
［配送計画生成処理］
　図７は、本実施の形態に係る配送計画生成装置１００により実行される配送計画生成処理のフローチャートである。本処理フローは、配送計画生成装置１００の処理部１１０が記憶部１２０に格納されたプログラムやデータを読み出して実行することにより実現されてよい。ここでは説明を簡単にするために、各工程の処理主体を配送計画生成装置１００としてまとめて記載する。
　配送計画生成装置１００は、配送範囲に関する情報を受信して入力する（ステップＳ７０１）。配送範囲に関する情報は、地図上の地域や担当エリアを指定してもよいし、配送先の一覧情報を指定してもよい。また、配送範囲に関する情報は、クライアント端末２００から受信してもよいし、ＵＩ部１３０を介して入力されてもよい。
　配送計画生成装置１００は、ステップＳ７０１にて入力された情報に基づいて、道路情報ＤＢ１２１から道路情報を参照する（ステップＳ７０２）。道路情報ＤＢ１２１は適時更新され、その最新状態の道路情報が参照されてよい。
　配送計画生成装置１００は、ステップＳ７０２にて参照した道路情報と、ステップＳ７０１にて入力された配送範囲に含まれる複数の道路に対応した道路コストをそれぞれ算出する（ステップＳ７０３）。道路コストは、予め規定されていてもよいし、渋滞や工事などの状況に応じて変更されてもよい。また、道路コストは、道路の形状や特徴、交通規制などに応じて、設定されてよい。
　配送計画生成装置１００は、ステップＳ７０２にて参照した道路情報に基づいて、配送ルートを決定したい２つの配送先（拠点を含む）のノードを順次特定する（ステップＳ７０４）。
　配送計画生成装置１００は、所定のアルゴリズムを用いて、順次特定された２つの配送先のノードを有する配送ルートを決定し、その決定された配送ルートに対応する配送コストを算出する（ステップＳ７０５）。配送ルートを決定するためのアルゴリズムは、例えば、公知のダイクストラ法を用いてよい。本実施の形態では、配送ルートは、図３（ｃ）や図３（ｄ）に示すように、複数の担当者それぞれに割り当てられた単位エリアごとに一筆書きとなるように決定される。
　配送計画生成装置１００は、ステップＳ７０５にて決定された配送コストに基づいて、配送計画を算出する（ステップＳ７０６）。本工程の詳細については、図８を用いて後述する。そして、本処理フローを終了する。
　（配送計画算出処理）
　図８は、本実施の形態に係る配送計画算出処理のフローチャートである。本処理フローは、図７のステップＳ７０６の工程に対応する。
　配送計画生成装置１００は、図７のステップＳ７０５にて決定された配送コストを用いて、配送計画の初期解を決定する（ステップＳ８０１）。配送計画の初期解は、ステップＳ７０５で決定された配送ルートおよび配送コストを含む配送計画である。なお、初期解は、上述したステップＳ７０５で決定された配送ルート及び配送コストを基にして、配送計画生成装置１００やクライアント端末２００の利用者が手動で策定した配送計画であってもよい。
　配送計画生成装置１００は、現時点の解である配送計画を基に、上述した改善方法を、全ての配送先の組み合わせに対して順番に行う（ステップＳ８０２）。ここで、現時点の解は、ステップＳ８０１で決定された初期解、または、後段のステップＳ８０４で得られる改善できた解である。
　配送計画生成装置１００は、改善候補の各車両に対して、配送するメッシュの中の実際の配送件数（すなわち、集約前の配送件数）を算出する（ステップＳ８０３）。
　配送計画生成装置１００は、ステップＳ８０３にて算出した配送件数に対して、平準化条件が満たされているか否かを判定する（ステップＳ８０４）。平準化条件は、予め設定されているものとし、例えば、各車両の配送件数の差が所定の値（例えば、「１」）以内であるなどの条件が設定されてよい。平準化条件の設定例については後述する。平準化条件を満たす場合（ステップＳ８０４；ＹＥＳ）、配送計画生成装置１００の処理はステップＳ８０５へ進む。一方、平準化条件を満たさない場合（ステップＳ８０４；ＮＯ）、配送計画生成装置１００の処理はステップＳ８０２へ戻り処理を繰り返す。
　配送計画生成装置１００は、ステップＳ８０２にて３種類の改善方法を全ての配送先の組み合わせに対して行った結果、配送計画を改善することができたか否かを判定する（ステップＳ８０５）。ここでの判定は、上述したように配送コストを下げることができたか否か基づいて行われる。改善できた場合（ステップＳ８０５；ＹＥＳ）、配送計画生成装置１００の処理はステップＳ８０６へ進む。一方、改善できていない場合（ステップＳ８０５；ＮＯ）、配送計画生成装置１００の処理はステップＳ８０７へ進む。
　配送計画生成装置１００は、改善できた解を現時点での解とする（ステップＳ８０６）。そして、配送計画生成装置１００の処理はステップＳ８０２へ戻り、処理を繰り返す。
　配送計画生成装置１００は、現時点での解を最終の配送計画として出力を行う（ステップＳ８０７）。ここでの出力は、配送計画の画面を生成して、配送計画生成装置１００のＵＩ部１３０にて出力してもよいし、クライアント端末２００へ通知してもよい。そして、本処理フローを終了する。
　なお、本処理フローの途中にて、配送計画算出処理が開始されてから予め設定された時間が経過した場合には、その時点での解を配送計画として出力し、本処理フローを終了する。この場合、途中で中断した旨の画面を表示してよい。また、ここでの時間の設定例については後述する。
［ＵＩ画面］
　以下、本実施の形態において、配送計画生成装置１００にて生成された配送計画に基づいて構成されるＵＩ画面の構成例について説明する。各ＵＩ画面は、例えば、配送計画生成装置１００の画面生成部１１４にて生成され、配送計画生成装置１００のＵＩ部１３０、または、クライアント端末２００のＵＩ部２０４にて表示されて提供される。
　図９は、配送計画を行う際に利用される設定画面９００の構成例を示す。設定画面９００は、例えば、図７のステップＳ７０１の工程にて表示される。入力フォーム９０１は、配送先データを指定するための項目である。入力フォーム９０１は、入力可能な配送先データをリスト表示して受付可能に構成してもよいし、所定の格納先を指定することで受け付けてもよい。配送先データは、例えば、配送先の情報、荷物の情報などを含んで構成される一覧データであり、ステップＳ７０１の配送範囲に関する情報に対応する。配送担当者設定ボタン９０２は、各配送担当者に関する設定を行うためのボタンである。配送担当者設定ボタン９０２が押下された場合、図１１に示す設定画面１１００に遷移する。デフォルト設定ボタン９０３は、配送計画を行う際に用いられる各種パラメータのデフォルト値を設定するためのボタンである。デフォルト設定ボタン９０３が押下された場合、図１０に示す設定画面１０００に遷移する。
　図１０は、配送計画を行う際に利用する各種パラメータを設定するための設定画面１０００の構成例を示す。入力フォーム１００１は、現時点を基準として、最大計算時間を設定するための項目である。入力フォーム１００１にて指定された時間を最大として、配送計画が生成される。通常、配送計画の生成の際には、一定の処理時間を要するため、ここで上限値を設定しておき、上限値を超えた場合には、配送計画の生成処理を打ち切り、その時点での解を配送計画とする。入力フォーム１００２は、メッシュにおける単位エリアの最大メッシュ幅（すなわち、単位エリア）を設定するための項目である。本実施の形態では、縦横が同じサイズである矩形の単位エリアを用いる。入力フォーム１００１、１００２は、例えば、テキスト入力が可能なように構成されてよい。
　入力フォーム１００３は、平準化対象となるパラメータを指定するための項目である。図８にて示した処理の例では、平準化対象として「配送件数」を例に挙げて説明した。しかし、平準化対象はこれに限定するものではない。例えば、平準化対象として、「配送件数」、「配送件数（単位エリア）」、「配送距離」、「配送時間」などが用いられてよい。また、「配送件数」もしくは「配送件数（単位エリア）」に対して、「配送距離」、「配送時間」などを組み合わせて用いられてもよい。したがって、入力フォーム１００３では、これらをリスト表示して受付可能に構成されてよい。なお、上記の例において「配送件数」は集約前の配送件数を平準化の対象とする場合を指し、「配送件数（単位エリア）」は集約後の配送件数を平準化の対象とする場合を指す。
　入力フォーム１００４は、平準化を行った場合の各割り当ての差分（ズレ）の許容値を指定するための項目であり、入力フォーム１００３にて指定された設定に応じて、選択可能な値が切り替えられる。例えば、入力フォーム１００３にて「配送件数」や「配送件数（単位エリア）」が指定された場合、入力フォーム１００４では、「５件」、「１０件」、「１５件」などをリスト表示して受付可能に構成されてよい。同様に、入力フォーム１００３にて「配送距離」が指定された場合、入力フォーム１００４では、「５ｋｍ」、「１０ｋｍ」、「１５ｋｍ」などをリスト表示して受付可能に構成されてよい。同様に、入力フォーム１００３にて「配送時間」が指定された場合、入力フォーム１００４では、「５分」、「１０分」、「１５分」などをリスト表示して受付可能に構成されてよい。もしくは、許容値は、比率（「５％」、「１０％」、「１５％」など）にて設定可能なように構成されてもよい。また、許容値は、３以上の配送担当者を対象として平準化を行う場合には、割り当てが最大の配送担当者と最小の配送担当者との差を対象としてよい。
　決定ボタン１００５は、設定画面１０００にて入力された各設定値をデフォルト設定として確定するためのボタンである。キャンセルボタン１００６は、設定画面１０００にて入力された各設定値を破棄するためのボタンである。決定ボタン１００５およびキャンセルボタン１００６が押下された場合には、設定画面９００に遷移するように構成されてよい。
　図１１は、平準化を行うための設定画面１１００の構成例を示す。入力フォーム１１０１は、配送計画における配送開始時刻を指定するための項目である。入力フォーム１１０２は、配送計画の作成のための実行時間を指定する。図１０の入力フォーム１００１と同様、ここで指定された時間を最大処理時間として、配送計画生成処理が実行される。
　入力フォーム１１０３は、配送人数、すなわち、平準化を行う対象の人数が表示される項目である。配送担当者リスト１１０４は、配送担当者に関する情報が一覧形式にて表示され、各項目に対して入力可能なように構成される。項目「Ｎｏ．」は、配送担当者を一意に識別するための識別情報を示す。項目「担当者」は、配送担当者の名称を示す。項目「デリバリスキル」は、配送担当者の配送スキルを示し、ここでは、数値が大きいほど熟練の配送担当者であるものとして設定する。また、項目「デリバリスキル」は、表示／非表示を切り替え可能に構成してもよい。
　項目「シフト」は、各配送担当者の業務を行う時間帯を示す。ここでは一時間単位で示しているが、更に大きな期間または小さな期間にて表示可能なように構成してもよい。また、項目「シフト」は、スライドバーなどで表示範囲を切り替えることで、更なる時間帯を表示させるような構成であってもよい。項目「配送」は、平準化を行う対象の配送担当者を指定するための項目であり、選択された場合にチェックが示される。ここで選択された配送担当者の数が入力フォーム１１０３にて表示される。項目「配送比率」は、選択した複数の配送担当者それぞれに対して割り当てる配送比率を指定するための項目である。配送比率の合計は１００（％）となる。
　設定項目１１０５は、平準化結果としての配送予測の期間を表示するための項目である。本例では、「配送」、「今日」、「今週」、「今月」、および任意の期間が設定可能なように構成されている。ここでは、「今月」が選択され、平準化ボタン１１０６が押下された結果、その平準化の結果として、今月の配送担当者ごとの「配送件数」、「勤務時間」、「配送距離」がグラフ１１０７、１１０８、１１０９にて表示される。期間に過去が含まれる場合には、その一部が実績として集計される。なお、設定項目１１０５にて「配送」が選択され、平準化ボタン１１０６が押下された場合、設定画面９００の入力フォーム９０１にて指定された配送先データのみを対象として、平準化処理およびグラフ１１０７、１１０８、１１０９の表示が行われる。この場合、配送担当者リスト１１０４にて選択された、すなわち、平準化の対象となっている配送担当者のみをグラフにて表示してよい。
　図１２は、各配送担当者の配送に関するデータの構成例を示す。ここでのデータには、項目「ＩＤ」、「配送開始時刻」、「配送終了時刻」、「担当者」、「配送時間」、「距離」、および「件数」が含まれる。本データは、配送済みであれば履歴データであってもよいし、未配送であれば予定データとして構成されてもよい。設定項目１１０５にて、「今日」、「今週」、「今月」、もしくは任意の期間が選択された場合に、その実績としてグラフの集計を行う際に用いられる。本データは、配送先の割り当て時や配送完了時などに適時更新され、配送情報ＤＢ１２２や担当者情報ＤＢ１２３などにて管理されてよい。なお、履歴データの構成は一例であり、これに限定するものではない。例えば、グラフの生成に要するデータであれば、他の項目が含まれてよい。
　図１３は、設定項目１１０５にて「配送」が選択され、平準化ボタン１１０６が押下されることで、本実施の形態に係る平準化処理が行われた結果を示すＵＩ画面の構成例を示す。図１３（ａ）は、平準化処理の結果、平準化が正常に行われた場合に表示されるＵＩ画面１３００の例を示す。図１３（ｂ）は、平準化処理の結果、平準化が正常に行われなかった場合に表示されるＵＩ画面１３１０の例を示す。
　ここでは、平準化のパラメータとして、図１０に示す設定画面１０００にて以下のパラメータを指定して用いた例を示す。これらのパラメータは、画面上にて平準化処理の結果と併せて表示される。
　平準化対象：件数（実配送件数）
　配送担当者：２人（配送担当者Ａ、配送担当者Ｂ）
　最大計算時間：３０分
　メッシュ幅：１００ｍ
　誤差：２件
　図１３（ａ）のＵＩ画面１３００に結果１３０１に示すように、各配送担当者に平準化されて割り当てられた件数の誤差は１件であり、平準化のパラメータである２件以下となっている。そのため、平準化は正常に行われたものとして表示されている。決定ボタン１３０２は、今回の平準化結果を採用する場合に押下されるボタンである。再計算ボタン１３０３は、再度、平準化処理を行わせる場合に押下されるボタンである。
　一方、図１３（ｂ）のＵＩ画面１３１０に結果１３１１に示すように、各配送担当者に平準化されて割り当てられた件数の誤差は４件であり、平準化のパラメータである２件以上となっている。そのため、平準化は正常に行われていないものとして表示されている。また、計算時間が３０分となっており、平準化のパラメータである３０分と同じ値となっているため、平準化処理が途中で打ち切られたことを示している。決定ボタン１３１２は、今回の平準化結果を採用する場合に押下されるボタンである。再計算ボタン１３１３は、再度、平準化処理を行わせる場合に押下されるボタンである。
　図１４、図１５は、平準化処理の結果を表示するためのＵＩ画面１４００の構成例であり、例えば、管理者が操作する配送計画生成装置１００のＵＩ部１３０にて表示される画面である。例えば、図１３のいずれかのＵＩ画面にて決定ボタンが押下された場合にＵＩ画面１４００に遷移してよい。
　図１４は、メッシュの単位エリアにおいて配送先を個別に示した表示例（通常モード）を示している。ＵＩ画面１４００には、地図１４０１に対して、設定されたメッシュの単位エリアを示す破線１４０２が重畳して示される。割り当て情報１４０３は、各配送担当者（本例では、配送担当者Ａ、Ｂの２名）の平準化処理の結果を示す。決定ボタン１４０４は、平準化結果を確定し、各配送担当者に通知する際に押下されるボタンである。再計算ボタン１４０５は、再度、平準化処理を行わせる場合に押下されるボタンである。モード切替ボタン１４０６は、図１５に示す表示例（メッシュモード）と切り替えるためのボタンである。
　ＵＩ画面１４００において、アイコン１４０７は、配送担当者の位置を示す。本例では、配送担当者Ａ、Ｂが同じ位置にいるものとし、「×２」として示されている。配送担当者（より具体的には、クライアント端末２００）の移動に伴って、アイコン１４０７の位置も変化してよい。アイコン１４０８は、配送先の位置を示し、ハッチングを付して表示されている。例えば、アイコン１４０８を操作することで、対応するより詳細な配送情報（例えば、配送先の住所など）が表示されてもよい。アイコン１４０８内の数字は、配送順を示す。アイコン１４０９は、アイコン１４０８と同様、配送先の位置を示し、ここでは異なる配送担当者に割り当てられているため、ハッチングとは異なる表示形式（本例では白抜き）となっている。
　図１５は、メッシュの単位エリアごとに集計した状態での表示例（メッシュモード）を示している。単位エリアごとに属する配送先を集計して示す。ＵＩ画面１５００には、地図１５０１に対して、設定されたメッシュを示す実線１５０２が重畳して示される。割り当て情報１５０３は、各配送担当者（本例では、配送担当者Ａ、Ｂの２名）の平準化処理の結果を示す。決定ボタン１５０４は、平準化結果を確定し、各配送担当者に通知する際に押下されるボタンである。再計算ボタン１５０５は、再度、平準化処理を行わせる場合に押下されるボタンである。モード切替ボタン１５０６は、図１４に示す表示例（通常モード）と切り替えるためのボタンである。
　ＵＩ画面１５００において、アイコン１５０７は、配送担当者の位置を示す。本例では、配送担当者Ａ、Ｂが同じ位置にいるものとし、「×２」として示されている。配送担当者（より具体的には、クライアント端末２００）の移動に伴って、アイコン１５０７の位置も変化してよい。アイコン１５０８は、単位エリアに属する配送先の集計結果（「（×）」にて示す）および配送順を示し、ハッチングを付して表示されている。例えば、アイコン１５０８を操作することで、対応するより詳細な配送情報（例えば、配送先の住所など）の一覧が表示されてもよい。アイコン１５０９は、アイコン１５０８と同様、配送先の位置を示し、ここでは異なる配送担当者に割り当てられているため、異なる表示形式（本例では白抜き）となっている。
　図１６、図１７は、平準化処理の結果を表示するためのＵＩ画面の構成例であり、例えば、配送担当者Ａが操作するクライアント端末２００のＵＩ部２０４にて表示される画面である。ここでは便宜上、図１６に示すＵＩ画面１６００を第１の画面とも記載し、図１７に示すＵＩ画面１７００を第２の画面とも記載する。なお、本実施の形態の説明において、「第１」、「第２」とは、異なる構成要素を区別して説明する際に用いているに過ぎず、特定の構成要素に限定して解釈することを意図するものではない。例えば、図１３のいずれかのＵＩ画面にて決定ボタンが押下された場合に、平準化結果としての配送計画を配送担当者Ａが所持するクライアント端末２００に通知することで、ＵＩ画面１６００が表示されてよい。
　図１６は、配送担当者Ａに割り当てられた配送先を個別に表示した例（通常モード）を示している。ＵＩ画面１６００には、地図１６０１に対して、設定されたメッシュを示す破線１６０２が重畳して示される。割り当て情報１６０３は、配送担当者Ａに対して割り当てられた配送に関する情報を示す。ここでの情報としては、配送件数、走行距離、配送に要する予定時間などが示されている。モード切替ボタン１６０４は、図１７に示す表示例（メッシュモード）と切り替えるためのボタンである。
　ＵＩ画面１６００において、アイコン１６０５は、配送担当者Ａの位置を示す。配送担当者Ａ（より具体的には、クライアント端末２００）の移動に伴って、アイコン１６０５の位置も変化してよい。アイコン１６０６は、配送先の位置を示す。例えば、アイコン１６０６を操作することで、対応するより詳細な配送情報（例えば、配送先の住所など）が表示されてもよい。アイコン１６０６内の数字は、配送順を示す。配送経路１６０７は、割り当てられた各配送先に対する配送経路を示す。本経路は、上述したように配送コストに基づいて導出される。
　図１７は、メッシュの単位エリアごとに集計した状態での表示例（メッシュモード）を示している。単位エリアごとに属する配送先を集計して示す。ＵＩ画面１７００には、地図１７０１に対して、設定されたメッシュを示す実線１７０２が重畳して示される。割り当て情報１７０３は、配送担当者Ａに対して割り当てられた配送に関する情報を示す。ここでの情報としては、配送件数、走行距離、配送に要する予定時間などが示されている。モード切替ボタン１７０４は、図１６に示す表示例（通常モード）と切り替えるためのボタンである。
　ＵＩ画面１７００において、アイコン１７０５は、配送担当者Ａの位置を示す。配送担当者Ａ（より具体的には、クライアント端末２００）の移動に伴って、アイコン１７０５の位置も変化してよい。アイコン１７０６は、単位エリアに属する配送先の集計結果（「（×）」にて示す）および配送順を示す。例えば、アイコン１７０６を操作することで、対応するより詳細な配送情報（例えば、配送先の住所など）の一覧が表示されてもよい。
　以上、本実施の形態に係る配送計画生成装置１００は、１以上の配送先が含まれる単位エリアを繋いで特定される複数の担当者それぞれの配送ルートの生成と、当該複数の担当者それぞれの配送ルートに含まれる配送を平準化する処理とを繰り返し実行して複数の担当者それぞれの配送ルートを生成する際に用いられる設定項目をユーザに入力させる設定画面（例えば、設定画面９００、設定画面１０００、設定画面１１００）を提供する画面生成部１１４を有する。
　これにより、荷物の配送ルートを配送担当者間で平準化して、配送の全体の実行時間を抑えつつ、配送担当者の作業負荷の偏りを抑制する配送計画を生成することが可能となる。
　また、設定画面１０００は、配送ルートの生成と配送を平準化する処理を繰り返す最大計算時間を指定可能に構成される。
　これにより、処理負荷の高い平準化処理を実行する場合でも、所望の処理時間にて打ち切ることが可能となり、必要以上に長い処理の実行を抑制することが可能となる。
　また、設定画面１０００は、単位エリアのサイズを指定可能に構成される。
　これにより、所望の単位エリアのサイズにて配送先の集約処理を行うことが可能となり、配送ルートの生成処理を任意の粒度で行って、処理負荷を軽減することが可能となる。
　また、設定画面１０００は、配送の平準化の対象を指定可能に構成される。
　これによりに所望の対象を平準化の対象として指定可能となる。
　また、配送の平準化の対象は、配送件数、配送距離、配送時間のいずれかである。
　これにより、単位エリアごとの配送件数、配送距離、配送時間のいずれかを指定して平準化を行わせることが可能となる。
　また、設定画面１０００は、配送の平準化の差分の許容値を指定可能に構成される。
　これにより、所望の精度、許容範囲にて平準化を実行させることが可能となる。
　また、画面生成部１１４は更に、配送先の割り当て対象となる担当者、および期間を少なくとも設定可能な設定画面１１００を提供する。
　これにより、所望の担当者や期間を指定して配送ルートの生成や平準化を行わせることが可能となる。
　また、設定画面１１００は、複数の担当者それぞれに対する平準化の結果の集計値を、平準化の項目ごとに表示可能に構成される。
　これにより、平準化の結果の集計値、および、配送実績の集計値を容易に把握可能と市、状況に応じた平準化を実行させることが可能となる。
　また、画面生成部１１４は更に、担当者に対して割り当てられた複数の配送先の配送ルートを、配送範囲の地図上に重畳して表示するＵＩ画面１６００を提供する。
　これにより、配送担当者は、自身に対して平準化して割り当てられた配送ルートを容易に把握することが可能となり、配送時の利便性を向上させることが可能となる。
　また、画面生成部１１４は更に、担当者に対して割り当てられた複数の配送先の、単位エリアごとに集計した数を配送範囲の地図上に重畳して表示するＵＩ画面１７００を提供する。
　これにより、配送担当者は、自身に対して平準化して割り当てられた配送を単位エリアごとに簡略化して把握することが可能となる。
　また、本開示は、上述した実施の形態の装置の機能を実現するプログラムを、ネットワークあるいは各種記憶媒体を介して装置に供給し、この装置内のコンピュータが読み出して実行するプログラム及び記憶媒体も適用範囲である。
　以上、図面を参照しながら各種の実施形態について説明したが、本開示は係る例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例、修正例、置換例、付加例、削除例、均等例に相当し得ることは明らかであり、それらについても当然に本開示の技術的範囲に属するものと了解される。また、発明の趣旨を逸脱しない範囲において、上述した各種の実施形態における各構成要素を任意に組み合わせてもよい。
　以上、各種の実施の形態について説明したが、本発明はかかる例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例又は修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。また、発明の趣旨を逸脱しない範囲において、上記実施の形態における各構成要素を任意に組み合わせてもよい。
　なお、本出願は、２０２２年４月１５日出願の日本特許出願（特願２０２２－０６７７１７）に基づくものであり、その内容は本出願の中に参照として援用される。
　本開示は、複数の荷物の配送において、配送先までの道路の状況に応じて最適な荷物の配送計画の策定を効果的に支援し、それぞれの荷物を配送する配送担当者の負担を相当に軽減する配送計画生成装置、および配送計画生成方法として有用である。
１００…配送計画生成装置
１１０…処理部
１１１…道路コスト算出部
１１２…配送コスト生成部
１１３…配送計画算出部
１１４…画面生成部
１１５…ＤＢ管理部
１１６…データ連携部
１２０…記憶部
１２１…道路情報ＤＢ
１２２…配送情報ＤＢ
１２３…担当者情報ＤＢ
１３０…ＵＩ部
１４０…通信部
２００…クライアント端末
２０１…処理部
２０２…記憶部
２０３…通信部
２０４…ＵＩ部
２０５…センサ部
３００…ネットワーク
９００、１０００、１１００…設定画面
１３００、１３１０、１４００、１５００、１６００、１７００…ＵＩ画面

Claims (11)

  1. 　配送範囲を所定の単位エリアに区切って、物品の配送先が割り当てられる複数の担当者それぞれの配送ルートの生成を行う配送計画生成装置であって、
    　１以上の配送先が含まれる単位エリアを繋いで特定される前記複数の担当者それぞれの配送ルートの生成と、当該複数の担当者それぞれの配送ルートに含まれる配送を平準化する処理とを繰り返し実行して前記複数の担当者それぞれの配送ルートを生成する際に用いられる設定項目をユーザに入力させる設定画面を提供する提供部を有する、
    　配送計画生成装置。
  2. 　前記設定画面は、前記配送ルートの生成と前記配送を平準化する処理を繰り返す最大計算時間を指定可能に構成される、請求項１に記載の配送計画生成装置。
  3. 　前記設定画面は、前記単位エリアのサイズを指定可能に構成される、請求項１に記載の配送計画生成装置。
  4. 　前記設定画面は、前記配送の平準化の対象を指定可能に構成される、請求項１に記載の配送計画生成装置。
  5. 　前記配送の平準化の対象は、配送件数、配送距離、配送時間のいずれかである、請求項４に記載の配送計画生成装置。
  6. 　前記設定画面は、前記配送の平準化の差分の許容値を指定可能に構成される、請求項１に記載の配送計画生成装置。
  7. 　前記提供部は更に、配送先の割り当て対象となる担当者、および期間を少なくとも設定可能な第２の設定画面を提供する、請求項１に記載の配送計画生成装置。
  8. 　前記第２の設定画面は、前記複数の担当者それぞれに対する平準化の結果の集計値を、平準化の項目ごとに表示可能に構成される、請求項７に記載の配送計画生成装置。
  9. 　前記提供部は更に、担当者に対して割り当てられた複数の配送先の配送ルートを、前記配送範囲の地図上に重畳して表示する第１の画面を提供する、請求項１に記載の配送計画生成装置。
  10. 　前記提供部は更に、担当者に対して割り当てられた複数の配送先の、前記単位エリアごとに集計した数を前記配送範囲の地図上に重畳して表示する第２の画面を提供する、請求項１に記載の配送計画生成装置。
  11. 　配送範囲を所定の単位エリアに区切って、物品の配送先が割り当てられる複数の担当者それぞれの配送ルートの生成を行う配送計画生成方法であって、
    　プロセッサとメモリが協働して、
    　１以上の配送先が含まれる単位エリアを繋いで特定される前記複数の担当者それぞれの配送ルートの生成と、当該複数の担当者それぞれの配送ルートに含まれる配送を平準化する処理とを繰り返し実行して前記複数の担当者それぞれの配送ルートを生成する際に用いられる設定項目をユーザに入力させる設定画面を提供する、
    　配送計画生成方法。
PCT/JP2023/013446 2022-04-15 2023-03-30 配送計画生成装置、および配送計画生成方法 WO2023199755A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022067717A JP2023157662A (ja) 2022-04-15 2022-04-15 配送計画生成装置、および配送計画生成方法
JP2022-067717 2022-04-15

Publications (1)

Publication Number Publication Date
WO2023199755A1 true WO2023199755A1 (ja) 2023-10-19

Family

ID=88329506

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/013446 WO2023199755A1 (ja) 2022-04-15 2023-03-30 配送計画生成装置、および配送計画生成方法

Country Status (2)

Country Link
JP (1) JP2023157662A (ja)
WO (1) WO2023199755A1 (ja)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08161404A (ja) * 1994-12-09 1996-06-21 Tadashi Yamamoto フレキシブル配送計画装置
JPH10134300A (ja) * 1996-11-05 1998-05-22 Nagoya Joho Syst Kk 最適配送ルート・配送車両決定装置および方法、並びに最適配送ルート・配送車両を決定するプログラムを記録した媒体
JPH1131177A (ja) * 1997-07-10 1999-02-02 Akabou Yamaguchi Pref Gov Keijidoushiya Unso Kyodo Kumiai 宅配システム
JP2004062363A (ja) * 2002-07-26 2004-02-26 Riosu Corp:Kk 経路調整装置
JP2004210413A (ja) * 2002-12-26 2004-07-29 Japan Tobacco Inc コース作成システムおよびコース作成方法
JP2020004181A (ja) * 2018-06-29 2020-01-09 株式会社日立製作所 配送計画装置、配送計画システムおよび配送計画方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08161404A (ja) * 1994-12-09 1996-06-21 Tadashi Yamamoto フレキシブル配送計画装置
JPH10134300A (ja) * 1996-11-05 1998-05-22 Nagoya Joho Syst Kk 最適配送ルート・配送車両決定装置および方法、並びに最適配送ルート・配送車両を決定するプログラムを記録した媒体
JPH1131177A (ja) * 1997-07-10 1999-02-02 Akabou Yamaguchi Pref Gov Keijidoushiya Unso Kyodo Kumiai 宅配システム
JP2004062363A (ja) * 2002-07-26 2004-02-26 Riosu Corp:Kk 経路調整装置
JP2004210413A (ja) * 2002-12-26 2004-07-29 Japan Tobacco Inc コース作成システムおよびコース作成方法
JP2020004181A (ja) * 2018-06-29 2020-01-09 株式会社日立製作所 配送計画装置、配送計画システムおよび配送計画方法

Also Published As

Publication number Publication date
JP2023157662A (ja) 2023-10-26

Similar Documents

Publication Publication Date Title
US10012998B2 (en) Transportation management system with route optimization tools using non-work stops to generate trip plans
US9921070B1 (en) System for planning trips with estimated time of arrival (ETA) and projected time of availability (PTA) calculated for each stop
US11162803B2 (en) Providing alternative routing options to a rider of a transportation management system
US10528062B2 (en) Computerized vehicle control system for fleet routing
US20200104965A1 (en) Systems and methods for managing ridesharing vehicles
US10260893B2 (en) System for integrating hours of service (HOS) with a vehicle's navigation system
US11386359B2 (en) Systems and methods for managing a vehicle sharing facility
US11300416B2 (en) Dynamic route recommendation and progress monitoring for service providers
JP7053253B2 (ja) 蓄電池モジュール貸与システム、貸与方法および貸与プログラム
JP6790103B2 (ja) 評価装置、評価方法、および評価プログラム
US11392861B2 (en) Systems and methods for managing a vehicle sharing facility
US9978111B2 (en) Method and system for recommending one or more vehicles for one or more requestors
US20140108663A1 (en) Control system for real-time complex resource allocation
US11132626B2 (en) Systems and methods for vehicle resource management
CA2876204A1 (en) Vehicle fleet routing system
JP2020057050A (ja) 情報処理装置及び情報処理プログラム
WO2023199755A1 (ja) 配送計画生成装置、および配送計画生成方法
JP3911225B2 (ja) エリア分割システム
JP4677119B2 (ja) 配車計画システム
JP7454926B2 (ja) 集配業務管理装置、集配業務管理方法及びプログラム
JP2020067677A (ja) 配送管理システム
WO2020170168A1 (en) Systems and methods for filling driver positions
JP4451622B2 (ja) 業務支援システム
JP4945794B2 (ja) 配車支援システム
JP7407395B2 (ja) 情報処理装置、情報処理システム及び情報処理方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23788175

Country of ref document: EP

Kind code of ref document: A1