JP4324911B2 - Delivery management system - Google Patents

Description

  The present invention relates to a delivery management system useful in recovery processing and verification processing of a failed automobile part.

Since there are so many kinds and types of automobile parts, it is difficult to store all the repair parts at each supplier's sales base. According to the technology described in Patent Document 1, an appropriate type and an appropriate number of repair parts are stored in a limited space at a supplier sales base, and the immediate delivery ratio from the sales base is improved in response to customer orders. We are considering an inventory management system.
JP 2002-342431A.

  By the way, in general, in the automobile industry, parts manufacturers (suppliers) supply car parts to car manufacturers, car makers assemble parts to complete cars, and finally car sales companies (dealers) are users. A form of transaction has been established, such as selling completed cars. In particular, since the user has a close relationship with the dealer, if any part of the automobile fails, the user brings the automobile or the failed part to the dealer and requests repair.

  The cause of a failed part can be analyzed and verified, and if necessary, the part can be improved.

  Therefore, the dealer asks the manufacturer to collect the failed part, and the manufacturer collects the failed part, verifies the cause of the failure, establishes a countermeasure for the failure, improves the part, and the like. These tasks are generally handled by the manufacturer's quality assurance department, but depending on the type of component, the manufacturer may perform primary verification work, and then the supplier may be responsible for secondary verification of the cause of failure. Many.

  In some cases, there is a faulty part that cannot be verified by the manufacturer. Conventionally, even in such a case, the faulty part is always delivered to the manufacturer's quality assurance department, and then the faulty part is sent to the supplier. It was being forwarded.

  Thus, if primary verification by the manufacturer is not required, efficiency can be improved in terms of both cost and time if the failed part can be delivered directly from the dealer to the supplier. For example, assuming that the manufacturer is in Hiroshima, the dealer is in Hokkaido, and the supplier is in the Kanto region, it would be sufficient to deliver the failed part from Hokkaido to a Kanto supplier. However, in the past, defective parts were delivered from a dealer in Hokkaido to a manufacturer in Hiroshima and then from Hiroshima to a supplier in Kanto, which was wasteful in terms of both cost and time.

  However, since the dealer has no direct business relationship with the supplier, the dealer could not deliver the failed part directly to the supplier without knowing which part was provided by which supplier. . In addition, it was not possible to grasp whether it was a part that required primary verification of the manufacturer or an unnecessary part.

  On the other hand, if a failed part is delivered between the dealer and the supplier without going through the manufacturer, the manufacturer cannot obtain information on the failure, and the manufacturer's initiative may be impaired. In particular, customer satisfaction may be reduced if an automobile manufacturer does not fully grasp information such as failure.

  Accordingly, an object of the present invention is to improve delivery efficiency associated with verification of a failed part.

First, a technical idea that is a superordinate concept of the present invention will be described. A first aspect of the present invention is a delivery management system for managing a delivery process of a failed automobile part collected from an automobile sales company among an automobile sales company, an automobile manufacturer, a parts manufacturer, and a logistics company , A delivery destination database that stores information on a delivery destination when the automobile part has failed for each automobile part, a collection request receiving means for receiving a collection request transmitted from a terminal of an automobile sales company for the failed automobile part, and Based on the identification information of the failed automobile part included in the received collection request, search and extraction means for retrieving and extracting information on the delivery destination of the failed automobile part from the delivery destination database; and the retrieved and extracted delivery destination A distribution request for delivering the failed automobile part to the delivery destination according to the information of Characterized in that it comprises a delivery request transmitting means for transmitting powder to. Further, with respect to the recovery of the failed automobile part, a recovery information transmission unit may be provided that transmits recovery information such as a recovery schedule to a first address indicating the automobile manufacturer and the parts manufacturer . Further, when the delivery of the failed automobile part to the delivery destination by the logistics person is completed, delivery completion information transmitting means for sending delivery completion information relating to the failed automobile part to a second address registered in advance May be provided. Needless to say, the first address and the second address may be the same address or different addresses.

  According to a second aspect of the present invention, in the first aspect, the delivery destination database further stores the delivery destination information and the failure content in association with each other, and the search and extraction unit includes the collection request. The information on the delivery destination of the failed automobile part is retrieved and extracted from the delivery destination database based on the identification information of the failed automobile part and the content of the failure contained in the delivery destination database.

  According to a third aspect of the present invention, in the first or second aspect, when the delivery destination database stores information on a plurality of delivery destinations in association with one automobile part, the plurality of delivery destinations are further stored. Priority order information indicating which of the priorities should be prioritized is also stored in association with the identification information of the automobile part.

  According to a fourth aspect of the present invention, in the third aspect, at the time of the search and extraction of the delivery destination, the search and extraction means also searches and extracts the priority information of the delivery destination related to the automobile parts to be collected. A delivery order determining means for determining a delivery order according to the priority order information, and inquiry information as to whether or not to accept the determined delivery order with respect to each address of the searched and extracted delivery destinations. Inquiry information transmitting means for transmitting, consent information receiving means for receiving consent information transmitted from each delivery destination as a response to the inquiry information, and delivery if necessary based on the received consent information Delivery order changing means for changing the order, wherein the collection information reflects the delivery order.

  According to a fifth aspect of the present invention, in the first to fourth aspects, when the delivery destination database stores information on necessity / unnecessity of collection for each automobile part, the collection request is received. And whether the information relating to the necessity / unnecessity of the collection of the automobile parts related to the collection request is retrieved and extracted by the search / extraction means, and whether the information relating to the necessity / unnecessity of the retrieval extracted indicates whether the collection is unnecessary. A recovery necessity / unnecessity determining means for determining, and a recovery unnecessary information transmitting means for transmitting information indicating that recovery is not required to the terminal of the automobile sales company that has transmitted the recovery request when it is determined that the recovery is unnecessary. It is characterized by including.

  A sixth aspect of the present invention, in the fifth aspect, when it is determined that there is a failure correspondence database that stores information on the cause of failure in association with identification information of the unrecoverable automobile parts, and the recovery is unnecessary. A failure cause search and extraction unit that searches and extracts information about the cause of the failure from the failure handling database, and the recovery unnecessary information transmission unit performs the search and extraction with respect to the terminal of the automobile company that has transmitted the recovery request. Information on the cause of failure is also transmitted.

  According to a seventh aspect of the present invention, in any one of the first to sixth aspects, the verification person database that stores the address of the person in charge of verifying the failed automobile part and the identification information of the automobile part in association with each other; Based on the identification information of the failed automobile part related to the collection list, the verification person search extracting means for searching and extracting the corresponding address of the verification person, and the failure for the address of the verification person extracted and extracted It further includes delivery destination information transmitting means for transmitting information on the delivery destination of the automobile parts and information on the delivery schedule.

  According to an eighth aspect of the present invention, in the first to seventh aspects, a verification database that stores the destination address of the verification result of the failed automobile part and the identification information of the automobile part in association with each other; When a result is input, a verification result address search extraction unit that searches and extracts a transmission destination address of the corresponding verification result based on identification information of a failed automobile part related to the collection list, and the search extracted It further includes verification result transmission means for transmitting the input verification result to the transmission destination address of the verification result.

  According to a ninth aspect of the present invention, in the first to eighth aspects, when information relating to the delivery destination is retrieved and extracted, information on the delivery destination and information relating to the failure content of the failed automobile part, A delivery approval request transmission means for sending a delivery approval request including a request to a predetermined address for approval, and an approval / rejection information receiving means for receiving approval / rejection information as a response to the delivery approval request. When the received approval propriety information means approval of delivery, the delivery request transmission means transmits a delivery request to the approved delivery destination, and the approval propriety information is the approval rejection or the delivery destination When the change is meant, the delivery request is transmitted to the delivery destination designated from the terminal in charge of the approval.

  According to a tenth aspect of the present invention, in the first to ninth aspects, the apparatus further comprises a parts database storing information on the size and mass of each automobile part, and the delivery request transmitting means is a delivery target. The delivery request is transmitted to the terminal in charge of logistics together with information on the size and mass read from the parts database for the failed automobile part.

  According to an eleventh aspect of the present invention, in the first to tenth aspects, a change request receiving means for receiving a change request for contents stored in the delivery destination database; A change approval request transmitting means for transmitting a change approval request to the address of the change approval person in charge, and a change in the contents stored in the delivery destination database when a response to the change approval request means change approval And a change control means for permitting the above.

  Note that methods and computer programs corresponding to the above aspects are also one aspect of the present invention.

  According to the present invention, the failed part and the information of the delivery destination (supplier, manufacturer, etc.) are managed by the database. Therefore, when the dealer requests the collection of the failed part, the delivery destination of the failed part Are identified by the database, and a delivery request is made to the logistics manager (distributor or delivery department). Therefore, it is possible to directly deliver a failed part that does not require verification by a manufacturer or the like from the dealer to the supplier. In addition, because collection information such as the collection schedule is notified to manufacturers and suppliers, it becomes possible for the manufacturer to monitor the delivery status of failed parts, etc. Can save. In addition, when the logistics staff completes the delivery of the faulty part, the delivery completion is reported to the verification staff such as the manufacturer's quality assurance department or supplier, so the time to start the verification work will be shortened.

  Further, even for the same part, there are cases where a supplier or the like should verify depending on the content of the failure, or a manufacturer or the like should verify. Therefore, the delivery efficiency of faulty parts will be further improved by changing the delivery destination according to the contents of the fault.

  In addition, depending on the type of failure part and the content of the failure, not only the quality assurance department of the manufacturer but also a plurality of verification staff members such as the design department and supplier of the manufacturer may perform the verification. Therefore, multiple delivery destinations can be specified for the same failed part. Also, when there are multiple delivery destinations, the delivery order and delivery priority can be specified. For example, if the manufacturer priority is designated, the manufacturer can be set as the first delivery destination. For example, when time priority is designated, delivery can be made from a dealer to a delivery destination that can be delivered in the shortest time. For example, when the cost priority is designated, the failed part can be delivered using a route that can save the delivery cost most.

  Further, among a plurality of delivery destinations, delivery efficiency may be poor in a predetermined delivery order. For example, if the delivery destination with a high priority is inconvenient, the failed part can be smoothly routed by changing the delivery order. Therefore, it will be possible to improve the efficiency of delivery by inquiring about the delivery of the failed parts to multiple delivery destinations, and changing the delivery order if the acceptance is not possible.

  Also, depending on the part, the cause of the failure has been fully elucidated, and further verification may not be necessary. If such a part is delivered every time it fails, the delivery cost is wasted. Therefore, the fact that collection is not required is registered, and when the request for collection is received from the dealer, the database is referred to, and if the part does not require collection, the fact is notified to the dealer. As a result, useless delivery can be suppressed.

  In addition, it is expected that the dealer wants to know the reason why collection is unnecessary and the cause of the failure. Therefore, by notifying the reason for no need for collection or the cause of failure, the question of dealers and maintenance staff can be solved.

  In addition, when a failed part arrives at the delivery destination, the verification work can be started smoothly by notifying the company in charge of verification of the failed part. Also, if you inform manufacturers, dealers, suppliers, etc., there will be an advantage that you can grasp the delivery status of the failed parts.

  In addition, since the verification result is reported through a preset address (eg, e-mail address, URL address, instant messenger address, etc.) such as a dealer or manufacturer, there is an advantage that can be used in planning countermeasures for faulty parts. In addition, when only the supplier verifies, it is possible to send the verification result to the quality assurance department of the manufacturer, so that the manufacturer can grasp the cause of the failure.

  In addition, when sending a delivery request to a logistics person, the approval of the manufacturer or the like is obtained. For example, the normal verification procedure may not be sufficient depending on the failed part and the failure content. It seems to be a special case where the content of the failure has not been reported before. Therefore, in order to be able to cover even in such cases, the delivery request can be sent after obtaining approval from the manufacturer. In addition, if necessary, the person in charge of approval can change the delivery order and delivery destination. For example, if the default setting of the database was to be delivered directly to the supplier, but the content of the failure is critical, it may be desirable to perform a primary verification at the manufacturer before forwarding it to the supplier. In the present invention, flexibility in the delivery order can be ensured in this way.

  In addition, data such as the size and mass of the failed part is managed by the database, and the data is attached when sending the delivery request for the failed part. Can be saved.

  When a supplier, etc., changes the database for managing delivery destinations, it can be changed with the approval of the manufacturer. For example, if the manufacturer is the primary delivery destination and the supplier is set as the secondary delivery destination and the database, and the supplier can change the supplier to the primary delivery destination without permission, the manufacturer It can undermine the initiative for understanding. Therefore, by requiring the manufacturer's approval, it will be possible to prevent the failure part from being processed without the manufacturer's knowledge.

  As described above, according to the present invention, a failed part can be quickly and reliably delivered to an appropriate delivery location without going through a manufacturer or the like.

  In the following, some embodiments that will be helpful to those skilled in the art when practicing the above invention are shown. Of course, the following embodiments are merely subordinate concepts of the present invention disclosed as a superordinate concept.

  In addition, about the invention of the low-order concept described in the following embodiment, all are not necessarily described in the claim. However, this is not intentionally excluded from the technical scope of the patented invention, but has an equivalent relationship with the patented invention, and may not be described in the claims.

  FIG. 1 is a diagram showing an overview of a delivery management system for faulty parts according to the present embodiment. Conventionally, a part collected from a dealer always passes through a manufacturer, but in this embodiment, the part is delivered to an appropriate delivery destination according to the characteristic or failure of the part. For example, a failed part that does not require primary verification by the manufacturer can be delivered directly to the supplier, thus improving the efficiency of the delivery process.

  The dealer is provided with a computer terminal 100 for transmitting a collection request for a failed part. A computer that executes at least one of these processes such as approval of delivery destination registration / change, approval of delivery, reception and display of parts collection information, reception and display of parts arrival information, and display of verification results A terminal 110 is provided. The supplier is provided with a computer terminal 120 for executing at least one of delivery destination setting, delivery acceptance, parts collection information reception and display, parts arrival information reception and display, and verification result input. ing. The logistics company is provided with a computer terminal 130 that executes reception / display of a delivery request regarding a failed part. Note that these computer terminals do not have to be a single computer terminal, and a plurality of similar terminals may be installed. Alternatively, one or more different types of computers such as desktop computers, mobile computers, and dedicated terminals may be installed. Needless to say, these terminals may be dedicated terminals, but may also be general computer terminals that can execute the computer program according to the present embodiment.

  The delivery management server 101 is a computer that is connected to each of the computer terminals described above via a network (eg, the Internet, a dedicated line, etc.) and executes delivery management processing. The delivery management server 101 further stores a delivery destination setting database 102 that stores information on a delivery destination when the automobile part has failed for each automobile part, a parts database 103 that stores part identification information, and a cause of failure. The failure cause database 104, the recovered parts database 105 storing various information about the parts to be recovered, the failure code database 106 for managing failure codes, and the address database 107 for managing address information of related companies and related departments Connected with.

  Each computer terminal and server includes a central processing unit (CPU) that executes various processes and controls based on a computer program stored in a ROM or a hard disk drive. As the control program, for example, a WEB server program, a CGI program, an e-mail server program, a WEB client (so-called browser) program, an e-mail client program, various scripts, and the like are executed according to a flowchart described later. is there. Temporary data is stored in RAM. A display device is also provided to display processing contents, processing results, and the like. Input devices such as a touch panel device, a numeric keypad, and a pointing device are also provided. The CPU transmits / receives the following data to / from other devices via the communication interface circuit.

  FIG. 2 is a diagram illustrating an exemplary data structure of the delivery destination database according to the present embodiment. In the database 102, for example, data representing a vehicle type, a part number for identifying each part, a failure code for identifying each fault, a collection necessity data representing whether a part needs to be collected or an unnecessary part, Failure cause data that indicates the cause of failure (code, etc.), delivery destination data that indicates the company code of the delivery destination, contact data of the design department and the department in charge of verification, etc. that require information on the failed part Report destination data that represents the manufacturer's quality assurance department, etc., delivery approval data that indicates whether prior approval is required when sending a delivery request, and when multiple delivery destinations are registered, Priority condition data related to the order and priority are included.

  FIG. 3 is a diagram showing an exemplary data structure of the component database according to the present embodiment. In the database 103, for example, data representing a vehicle type, a part number for identifying each part, part name data, one or more failure codes, size data representing the external size of the part, and weight of the part are represented. Includes weight data.

  FIG. 4 is a diagram showing an exemplary data structure of the failure cause database according to the present embodiment. The database 104 includes, for example, a cause code for identifying the cause of the failure and detailed information corresponding to each cause code.

  FIG. 5 is a diagram showing an exemplary data structure of the collected parts database according to the present embodiment. The database 105 includes, for example, an ID issued for each collection request, data representing a vehicle type, a part number for identifying each part, a fault code for identifying each fault, and a faulty part at a delivery source such as a dealer. Collection date data indicating the date to go to (collect), arrival date data indicating the date when the failed part arrives at the specified delivery destination, delivery destination data indicating the company code of the delivery destination, contact data, verification result Report destination data that represents the report destination (address, etc.), input data that represents the verification result input person or verifier, etc., verification date and time that the verification was performed, and verification result data that represents the verification result It is. Further, data on a date on which a repair related to a failed part is performed at a dealer or a date on which a repair is scheduled may be included.

  FIG. 6 is a diagram illustrating an exemplary data structure of the failure code database according to the present embodiment. In the database 106, for example, a failure code for identifying each failure, whether or not a predetermined person (eg, a manufacturer's person in charge) needs to be approved when a failed part is delivered to a specified delivery destination is determined. In the case where the content is that the approval is requested with delivery approval data and delivery approval data conditions, condition data indicating the conditions is included.

  FIG. 7 is a diagram illustrating an exemplary data structure of the address database according to the present embodiment. The database 107 includes, for example, company IDs of each related company, company name data, company address data, telephone number data, and the like.

  FIG. 8 is a flowchart showing a data setting process related to the delivery destination according to the present embodiment. Here, the delivery destination of the failed part is set, but not only the quality assurance department of the supplier or manufacturer who is responsible for verifying the failed part, but not wanting to verify, but wants to see the failed part once Other departments such as the design department can be set as delivery destinations themselves. Although delivery is not required, there are developers and researchers who want to go and see the failed parts when they are delivered to a nearby department in charge of verification. In that case, the arrival information of the faulty part can be obtained by registering its own company code, department code, e-mail address, etc. in the contact field.

  In step S800, when the CPU of the supplier terminal 120 is instructed to start the delivery destination setting process from an input device such as a keyboard, the CPU transmits a setting process start request to the delivery management server 101. For example, when this system is constructed on a WEB basis, the URL of the delivery management server 101 will be input.

  In step S <b> 802, when the CPU of the server 101 receives a start request from the supplier terminal 120, it creates screen information for setting a delivery destination.

  FIG. 9 is a diagram showing an example of a delivery destination setting screen according to the present embodiment. The server 101 can create screen information by opening a template file stored in advance on a hard disk drive or the like and writing information to be customized for each setter, such as the name of the operator of the supplier terminal 120. it can. For example, the name of the operator may be set by reading the ID used at the time of login to the server 101 or the name data corresponding to the ID from the database. The screen information can be realized by using an HTML file, an XML file, a Java (registered trademark) script, or the like.

  In step S804, the CPU of the supplier terminal 120 outputs the received screen information to the display device. For example, the screen information is converted into display data by a WEB browser and displayed. The CPU of the supplier terminal 120 inputs vehicle type data and the like according to an instruction input from the input device. For example, when inputting vehicle type data, press the “Browse” button displayed next to the vehicle type column to display a vehicle type list. Select one of the vehicle types with a pointing device, etc., and enter the vehicle type in the vehicle type data column. The code is set. This can be most easily achieved by using the <SELECT> element, which is an HTML technology. The list data such as vehicle type is also received together with the screen information. Other data such as a part number and a delivery destination can be input in the same procedure. The delivery destination here means a department that picks up a part from the dealer when the part fails. Usually, the supplier that manufactured the part will be the delivery destination.

  In step S808, when the CPU of the supplier terminal 120 detects that a setting change request (for example, the OK button in FIG. 9) has been pressed from a pointing device or the like, the CPU sets the settings together with the input vehicle type data and part number data. A change request is transmitted to the server 101.

  In step S810, when the server 101 receives the setting change request via the communication interface, the server 101 stores the delivery destination setting database 102 using the vehicle type data, part number data, failure code, and the like received with the setting change request as search keys. Search, extract corresponding records, and store in RAM. In the example of FIG. 9, assuming that the vehicle type is 0151, the part number is 1234, and the failure code is 012, the top record is extracted. Then, the CPU rewrites the contents of the record using the next received delivery destination data. Finally, a setting change approval screen is created based on the rewritten record.

  In step S812, the CPU of the server 101 transmits the information of the created approval screen together with the approval request to a predetermined terminal (in this example, the manufacturer terminal 110). An e-mail in which a URL for accessing the setting change screen is entered may be transmitted. Further, the approval request may be transmitted in real time by an instant messenger. In addition, since the approval request requires immediacy, it may be desirable to send the approval request using an instant messenger.

  In step S814, the manufacturer's terminal 110 receives the approval request and the setting change approval screen and causes the display device to display them.

  FIG. 10 is a diagram illustrating an example of a setting change approval screen according to the present embodiment. If there is no problem with the contents of the changed record displayed in this way, an approval button is pressed, and an approval response indicating approval is transmitted to the server 101. On the other hand, when the person in charge of approval changes some information, the data is changed by a reference button or direct input of text.

  In step S816, when the CPU of the manufacturer's terminal 110 detects that the change button is pressed, the CPU transmits the changed content as an approval response.

  In step S818, the server 101 registers the contents of the record after the change approval in the delivery destination setting database 102.

  In step S820, the server 101 transmits a change completion notification including the contents of the record after the change approval to the supplier terminal 120. In addition, an e-mail in which a URL for accessing the setting change completion notification is entered may be transmitted. Further, the completion notification may be transmitted in real time by an instant message. With the above procedure, the delivery destination for each part is registered on the database 102. Needless to say, the same procedure can be used to register a contact or report destination.

  FIG. 11 is an exemplary flowchart of the failed part collection process according to the present embodiment. Referring to FIG. 11, a description will be given of a process until a dealer requests recovery of a failed part and the request is registered in the recovered part database 105.

  In step S <b> 1100, when the URL for parts collection request is input from the keyboard or the like, the CPU of the dealer terminal 100 transmits a collection setting screen request to the server 101 according to the input URL.

  In step S1102, when the CPU of the server 101 receives the request, it reads a template file (for example, an HTML file or an image file) of the collection setting screen from the hard disk drive, creates information on the collection setting screen, and sends it to the dealer terminal 110. Send.

  FIG. 12 is a diagram illustrating an example of a collection setting screen according to the present embodiment. Although the name data of each dealer is reflected in the column of the collection requester, for example, it is set based on the ID at the time of login to the server 101 or the like.

  In step S1104, the CPU of the terminal 100 receives the collection setting screen information via the communication interface, and displays it on the display device using a WEB browser. The CPU of the terminal 100 stores the vehicle type data, the part number data, and the failure code in the RAM according to the instruction from the input device.

  In step S1106, when the CPU of the terminal 100 detects the depression of the OK button (for example, the Submit button in the HTML form element), the vehicle type data and the like are read from the RAM, and registration with the read data is performed. A request is transmitted to the server 101.

  In step S1108, when the CPU of the server 101 receives the vehicle type data together with the registration request, the CPU 101 reads the corresponding record from the delivery destination database 102 and stores it in the RAM. As in the example illustrated in FIG. 2, this may include information indicating whether the component needs to be collected or is unnecessary.

  In step S1110, the CPU of the server 101 reads the recovery necessity data from the RAM, and determines whether or not the read recovery necessity is “recovery required”. If “recovery required”, the process proceeds to step S1114.

  On the other hand, if the collection is unnecessary, the process proceeds to step S1112 and the failure cause code is read from the corresponding record stored in the RAM. Further, detailed information on the failure cause corresponding to the read code is retrieved and extracted from the failure cause database 104. Then, collection unnecessary information is created and transmitted to the dealer's terminal 100.

  FIG. 13 is a diagram illustrating an example of the collection unnecessary information according to the present embodiment. According to the drawing, along with the component data accompanying the collection request, it is displayed that the collection is unnecessary and the detailed cause of the failure. As a result, the dealer or the like can grasp that the collection is unnecessary, and can also know the reason, so that it will be easier to deal with a similar failure in the future.

  In step S1114, the CPU of the server 101 reads the data of the delivery destination, the contact destination, and the report destination from the corresponding record stored in the RAM. These data may be company codes, URLs, IP addresses, e-mail addresses, or the like.

  If it is determined in step S1116 that a plurality of delivery destinations are set, the CPU of the server 101 further reads the corresponding record delivery priority data and determines the delivery order according to the delivery priority data. For example, if the delivery order is “maker priority”, the manufacturer is set as the first delivery destination. If “cost priority” is set, the dealer's address data and the address data of each delivery destination are read from the address database 107, and the delivery order is set so that the cost is reduced again. For example, if the delivery costs between the respective bases are stored in a database in advance, the cheapest delivery order can be easily determined by referring to this content by the CPU. In the case of “time priority”, a delivery order that can be delivered efficiently in the shortest time is determined. In this case as well, it can be easily determined by creating a database of standard time required between each base.

  In step S1118, the CPU of the server 101 creates a confirmation screen for the determined delivery destination. The information on the confirmation screen can also be created on a WEB basis as described above.

  In step S <b> 1120, the server 101 transmits confirmation screen information to the dealer terminal 100. An e-mail or an instant message including a URL for accessing the confirmation screen may be transmitted. In step S1122, the CPU of the terminal 110 displays confirmation screen information on the display device using a WEB browser.

  FIG. 14 shows an example of a delivery confirmation screen according to the present embodiment. According to this figure, together with the identification number for each collection request (this was issued when the CPU of the server 101 received the collection registration request), vehicle type data, part number, and failure code, the collection date and repair date (planned date But it is also possible) and a predetermined comment is displayed. Note that the collection date and time, the repair date, and the like may be input from the last 100 at this stage.

In step S <b> 1124, when the CPU of the terminal 100 detects that the collection request button is pressed, the CPU 100 transmits the collection request information to the server 101 together with the input data such as the collection date and time.
In step S <b> 1126, the CPU of the server 101 creates a collection record (FIG. 5) including the received collection date / time data and writes it into the collection part database 105. The collection record is created based on information received from the dealer and data read from the delivery destination database 102 in advance.

  FIG. 15 is an exemplary flowchart of a delivery process according to this embodiment. The process from the delivery approval process to the failure part arrival notification process will be described with reference to FIG.

  In step S1500, the CPU of the server 101 reads a record newly registered in the collected parts database 105, and further, based on the vehicle type data, part number, and failure code included in the read record, the delivery destination database. The necessity data for delivery approval is read from 102. If approval of a predetermined person such as a manufacturer is registered in advance in the database 102 before delivery starts, the process proceeds to step S1502, and if not, the process proceeds to step S1508.

  In step S1502, the CPU creates information on a delivery approval screen based on the corresponding record in the collected parts database 105, and transmits it to the manufacturer terminal 110 as a delivery approval request. In step S1504, upon receiving the delivery approval request, the CPU of the manufacturer terminal 110 outputs a delivery approval screen to the display device using the WEB browser.

  FIG. 16 is a diagram showing an example of a delivery approval screen according to the present embodiment. According to the figure, the data read from the collected parts database 105 are listed. According to FIG. 5, the collection requester's data is not described in the database, but this is merely omitted. If the user agrees with the contents displayed on the delivery approval screen, the approval button is depressed. The delivery destination, contact address, report destination, delivery order, delivery priority rule, etc. may be changed. The contents changed here are transmitted to the server 101 and stored in the collected parts database 105.

  In step S <b> 1506, the CPU of the manufacturer terminal 110 transmits delivery approval information to the server 101 when detecting the depression of the approval button.

  In step S1508, the server 101 determines whether or not the delivery consent of each delivery destination is necessary. For example, when the necessity of delivery approval is registered in the delivery destination setting database 102, the necessity is determined by referring to the contents. If necessary, the process proceeds to step S1510, and if not necessary, the process proceeds to step S1516.

  In step S1510, the CPU of the server 101 transmits a delivery acceptance request to each delivery destination registered in the collected parts database. The delivery acceptance request includes data registered in the collected parts database, such as a part number to be delivered, a failure code, and a collection date (or a scheduled delivery date obtained from the collection date).

  In step S1512, when the supplier terminal 120 designated as the delivery destination receives the acceptance request, the supplier terminal 120 outputs the delivery content to the display device. In step S1514, if the scheduled delivery date or delivery order does not suit the delivery destination, the CPU transmits a delivery order change request (for example, including information on the desired delivery order) to the server 101. The server 101 executes a delivery approval process (S1502 to S1506) for the desired delivery order.

  In step S1516, the server 101 creates and sends delivery request information to the terminal 130 in charge of distribution. For example, the server 101 reads out data regarding the size and weight of the failed part to be delivered from the parts database, and also uses the collection requester's company code and the delivery company code to address and telephone number, etc. The information required for the delivery is read from the address database, and the delivery request information including the read information is created. When the distribution request terminal 130 receives the delivery request information, it outputs it from the display device or the printing device. Based on the delivery request information, the logistics terminal 130 determines a date (shipping date) for picking up the failed part to the delivery source (dealer that sends the failed part) and a date (arrival date) for delivery to the delivery destination. Information on the shipping date and arrival date is transmitted to the server 101. The server 101 stores these date data in corresponding records in the collected parts database 105.

  In step S1518, the CPU of the server 101 reads the record of the collection target component from the collection component database 105, and creates the latest collection information reflecting the contents of the record.

  FIG. 17 is a diagram illustrating an example of the collection information according to the present embodiment. For example, the collection information includes a collection requester, a collection ID, a part number, a failure code, a collection / delivery date for each delivery destination, and the like. As a result, delivery destinations such as manufacturers and suppliers can make preparations for accepting delivery items, and manufacturers can generate and deliver faulty parts even when they are delivered directly to suppliers without going through the manufacturer. I can grasp it.

  In steps S1520 and S1522, the server 101 transmits the collection information to predetermined addresses such as a contact address, a report destination, and a delivery destination. The collection information can be transmitted by e-mail, for example, or may be transmitted as WEB information when a predetermined terminal accesses the collection information page of the server 101. In steps S1524 and S1526, the terminal that has received the collection information outputs the information from the display device or the printing device.

  In step S1528, delivery information indicating completion of delivery is transmitted from the terminal 130 in charge of distribution. In step S 1530, the server 101 creates part arrival information including the received delivery information and the part number of the target part read from the collected part database 105. In steps S1532 and S1534, the server 101 transmits component arrival information to predetermined addresses such as a contact address, a delivery address, and a report address. In steps S1536 and S1538, component arrival information is output at each terminal.

  FIG. 18 is a diagram illustrating an example of component arrival information according to the present embodiment. For example, the part arrival information includes information such as a collection requester, a collection ID, a part number, a failure code, an arrival destination of the failed part, and a next delivery destination.

  FIG. 19 is an exemplary flowchart relating to a verification result registration process according to the present embodiment. The process from the input to the display of the verification result will be described with reference to FIG. In this example, the supplier is in charge of verification, but of course, the manufacturer's quality assurance department may be in charge of verification. Needless to say, the present invention can be similarly applied to the latter case.

  In step S <b> 1900, the supplier terminal 120 transmits an input request for inputting a verification result to the server 101. The input request includes, for example, the URL of the input page. It should be noted that if the URL is described in advance in the failure part delivery slip, verification input will be easier. Alternatively, the access destination information may be converted into a bar code, printed on a delivery slip, read by a bar code reader of the terminal 120, converted into a URL, and accessed to the server 101.

  In step S1902, the server 101 generates input screen information (for example, an HTML file). In step S1904, the server 101 transmits the created input screen information to the terminal 120.

  In step S1906, the terminal 120 receives the input screen information and displays it on the display device. FIG. 20 is a diagram showing an example of a verification result input screen according to the present embodiment. According to this figure, a collection ID, a vehicle type ID, a part number, a failure code, a collection date and time, a cause of failure, a detailed verification result, and the like are included, and are input at the terminal 120, respectively. Alternatively, the input screen may be created by reading the necessary data from the collected parts database by transmitting the collected ID attached to the failed part at the time of the input request to the server 101. Further, the next delivery destination may be registered at this time. In that case, by pressing the GO button, a screen for selecting a delivery destination is called to designate the next delivery destination. In the future, when it is considered that verification is unnecessary (that is, recovery is not required), a registration request that does not require recovery may be transmitted to the server 101. In this case, the contents of the delivery destination database 102 will be updated by the server 101.

  In addition, the verification result does not need to be text only, and may include at least one of audio information, image information, and moving image information. Since this is useful information for future failure targets, it may be desirable to attach it.

  In step S 1908, when the CPU of the terminal 120 detects that the verification result input completion button is pressed, the CPU transmits a registration request including the cause of the failure and the verification result to the server 101.

  In step S1910, the server 101 uses the collection ID included in the received registration request as a search key to search and extract the corresponding record from the collection component database 105, and reflects the received verification result and other information in the record. Write to the database again. In step S1912, the server 101 creates verification result information based on the changed record. FIG. 21 is a diagram showing an example of a verification result display screen according to the present embodiment. The display screen of the verification result includes a part number, a failure code, a failure cause, and a verification result registered in the collected component database.

  In steps S <b> 1914 and S <b> 1918, the server 101 transmits the verification result display screen information to a predetermined report destination. Further, in steps S1916 and S1920, each terminal that receives the information outputs display screen information of the verification result. The verification result may be transmitted to the e-mail address.

  By the way, the server 101 reads the arrival date and the verification date and time of the recovered parts database 105 at an appropriate timing, and if the verification date is not input even after the predetermined date and time has elapsed from the arrival date and time, the delivery destination (verification person in charge) An e-mail or the like that prompts verification may be transmitted.

  Further, when the server 101 has created a database relating to the statistical occurrence status of each failed part, a delivery destination setting screen (FIG. 9), a delivery destination change approval screen (FIG. 10), or a delivery approval screen By providing a reference button for the occurrence state in FIG. 16 or the like, statistical materials (tables or graphs) regarding the past occurrence state may be displayed. Alternatively, when the server 101 receives a certain collection request, it reads the related past occurrence status from the database, and determines whether or not the occurrence frequency within a predetermined period exceeds a threshold (for example, 10 cases per month). If the threshold value is exceeded, a message prompting a warning may be displayed in the guidance information window. In this way, if the frequency of occurrence of a specific failure for a specific part is high, the delivery destination or the like can be changed accordingly.

  Further, the server 101 may store the current possessed department and the possession period (the elapsed date from the delivery completion date) in the collected parts database 105 for each collection ID. For example, if the possession period is longer than a predetermined period, the server 101 may transmit warning information because the failure verification is late. In this way, there will be an advantage that the stagnation of the failed part can be prevented.

  In the above-described embodiment, the case where the present invention is implemented on a WEB basis has been described. However, a part or the whole of the present invention may be realized using a technique other than the WEB base such as e-mail, facsimile, and a unique communication protocol. Further, the network does not have to be the Internet, and may be a closed network using a dedicated line, or both may be appropriately combined.

  Further, it will be apparent that those steps that do not affect the result even if the order is changed among the steps in the above-described embodiment may be appropriately replaced. That is, it can be said that the flow in which these steps are interchanged is substantially disclosed in the present application.

FIG. 1 is a diagram showing an overview of a delivery management system for faulty parts according to the present embodiment. FIG. 2 is a diagram illustrating an exemplary data structure of the delivery destination database according to the present embodiment. FIG. 3 is a diagram showing an exemplary data structure of the component database according to the present embodiment. FIG. 4 is a diagram showing an exemplary data structure of the failure cause database according to the present embodiment. FIG. 5 is a diagram showing an exemplary data structure of the collected parts database according to the present embodiment. FIG. 6 is a diagram illustrating an exemplary data structure of the failure code database according to the present embodiment. FIG. 7 is a diagram illustrating an exemplary data structure of the address database according to the present embodiment. FIG. 8 is a flowchart showing a data setting process related to the delivery destination according to the present embodiment. FIG. 9 is a diagram showing an example of a delivery destination setting screen according to the present embodiment. FIG. 10 is a diagram illustrating an example of a setting change approval screen according to the present embodiment. FIG. 11 is an exemplary flowchart of the failed part collection process according to the present embodiment. FIG. 12 is a diagram illustrating an example of a collection setting screen according to the present embodiment. FIG. 13 is a diagram illustrating an example of the collection unnecessary information according to the present embodiment. FIG. 14 shows an example of a delivery confirmation screen according to the present embodiment. FIG. 15 is an exemplary flowchart of a delivery process according to this embodiment. FIG. 16 is a diagram showing an example of a delivery approval screen according to the present embodiment. FIG. 17 is a diagram illustrating an example of the collection information according to the present embodiment. FIG. 18 is a diagram illustrating an example of component arrival information according to the present embodiment. FIG. 19 is an exemplary flowchart relating to a verification result registration process according to the present embodiment. FIG. 20 is a diagram showing an example of a verification result input screen according to the present embodiment. FIG. 21 is a diagram showing an example of a verification result display screen according to the present embodiment.

Claims (23)

A delivery management system for managing a delivery process of a broken automobile part collected from an automobile sales company among an automobile sales company, an automobile manufacturer, a parts manufacturer and a logistics company ,
A delivery destination database that stores information on delivery destinations when the automobile parts have failed for each automobile part;
A collection request receiving means for receiving a collection request transmitted from a terminal of an automobile sales company for a broken automobile part;
Search and extraction means for searching and extracting information on a delivery destination of the failed automobile part from the delivery destination database based on the identification information of the failed automobile part included in the received collection request;
A delivery request transmitting means for transmitting a delivery request for delivering the failed automobile part to the delivery destination according to the information of the retrieved delivery destination;
With regard to the recovery of the failed automobile part, recovery information transmitting means for transmitting recovery information such as the recovery schedule to the first addresses respectively indicating the automobile manufacturer and the parts manufacturer ;
Delivery completion information transmitting means for transmitting delivery completion information relating to the failed automobile part to a pre-registered second address when delivery of the failed automobile part to the delivery destination by the logistics staff is completed. Including delivery management system. The delivery destination database further stores the delivery destination information and failure contents in association with each other,
The search and extraction means searches and extracts information on a delivery destination of the failed automobile part from the delivery destination database based on the identification information of the failed automobile part and the content of the failure included in the collection request. The delivery management system according to claim 1.   In the case where the delivery destination database stores information on a plurality of delivery destinations in association with one automobile part, priority information indicating which of the delivery destinations should be given priority is also included in the automobile parts. The delivery management system according to claim 1 or 2, wherein the delivery management system is stored in association with identification information. When the retrieval and extraction means also retrieves and extracts the priority information of the delivery destination related to the car parts to be collected by the retrieval and extraction means, the delivery order is determined according to the priority information. Order determining means;
Inquiry information transmitting means for transmitting inquiry information as to whether or not to accept the determined delivery order, for each address of the delivery destination that has been searched and extracted,
Consent information receiving means for receiving permission information transmitted from each delivery destination as a response to the inquiry information;
Delivery order changing means for changing the delivery order if necessary based on the received acceptance information;
4. The delivery management system according to claim 3, wherein the collection information reflects the delivery order. When the delivery destination database stores information on the necessity / unnecessity of collection for each automobile part, when the collection request is received, information on the necessity / unnecessity of collection of the automobile part related to the collection request A retrieval necessity / unnecessity determining means for determining whether or not the information relating to the necessity / unnecessity of the retrieval extracted by the search extraction means indicates whether or not the retrieval is necessary.
5. The collection unnecessary information transmitting means for transmitting information indicating that collection is not required to a terminal of an automobile sales company that has transmitted the collection request when it is determined that the collection is unnecessary. The delivery management system according to any one of the above. A failure handling database that stores information on the cause of failure in association with identification information of the automobile parts that are not required to be collected;
A failure cause search and extraction means for searching and extracting information on the cause of failure from the failure handling database when it is determined that recovery is unnecessary;
The delivery management system according to claim 5, wherein the collection unnecessary information transmission unit also transmits information on the cause of the failure extracted and extracted to the terminal of the automobile company that has transmitted the collection request. A verification person database that stores the address of the person in charge of verifying the failed automobile part and the identification information of the automobile part in association with each other;
Based on the identification information of the failed automobile part related to the collection list, a verification person search extraction unit that searches and extracts the corresponding address of the verification person;
7. A delivery destination information transmitting means for transmitting information on a delivery destination of the failed automobile part and information on a delivery schedule to the retrieved address in charge of verification. The delivery management system according to item. A database in charge of verification that stores the transmission destination address of the verification result of the failed automobile part in association with the identification information of the automobile part;
When a verification result is input, a verification result address search extraction unit that searches and extracts a transmission destination address of the corresponding verification result based on identification information of a failed automobile part related to the collection list;
8. The delivery management system according to claim 7, further comprising verification result transmission means for transmitting the input verification result to the transmission destination address of the verification result extracted and extracted. When the information on the delivery destination is retrieved and extracted, a delivery approval request including the information on the delivery destination and the information on the failure content of the failed automobile part is transmitted to a predetermined approval address. A delivery approval request sending means;
Approval approval information receiving means for receiving approval approval information as a response to the delivery approval request;
When the received approval propriety information means approval of delivery, the delivery request transmission means transmits a delivery request to the approved delivery destination, and the approval propriety information is the approval rejection or the delivery destination 9. The delivery management system according to claim 1, wherein when the change is meant, the delivery request is transmitted to a delivery destination designated from the terminal in charge of approval. . Further comprising a parts database storing information on the size and mass of each automobile part;
The delivery request transmission means transmits the delivery request to the terminal in charge of distribution together with information on the size and mass read from the parts database for the failed automobile part to be delivered. The delivery management system according to any one of claims 1 to 9. Change request receiving means for receiving a change request for content stored in the delivery destination database;
When receiving the change request, a change approval request transmission means for transmitting a change approval request to a previously registered change approval address,
11. The delivery according to any one of claims 1 to 10, further comprising a change control means for permitting a change of contents stored in the delivery destination database when a response to the change approval request means a change approval. Management system. A delivery management method for managing a delivery process of a failed automobile part collected from an automobile sales company among an automobile sales company, an automobile manufacturer, a parts manufacturer and a logistics company ,
Receiving a collection request sent from the terminal of the car sales company for the failed auto part;
Based on the identification information of the failed automobile part included in the received collection request, from the delivery destination database storing the information of the delivery destination when the automobile part has failed for each automobile part. Searching for and extracting information about the shipping destination;
Transmitting a delivery request for delivering the failed automobile part to the delivery destination according to the information on the retrieved delivery destination;
With regard to the recovery of the failed automobile parts, the collection information such as the collection schedule is transmitted to the first addresses respectively indicating the automobile manufacturer and the parts manufacturer ;
A delivery management method including the step of, when delivery of the failed automobile part to the delivery destination by the logistics person is completed, sending delivery completion information relating to the failed automobile part to a pre-registered second address . The delivery destination database further stores the delivery destination information and failure contents in association with each other,
In the search and extraction step, based on the identification information of the failed automobile part and the content of the failure included in the collection request, information on the delivery destination of the failed automobile part is retrieved and extracted from the delivery destination database. The delivery management method according to claim 12, wherein:   In the case where the delivery destination database stores information on a plurality of delivery destinations in association with one automobile part, priority information indicating which of the delivery destinations should be given priority is also included in the automobile parts. 14. The delivery management method according to claim 12, wherein the delivery management method is stored in association with identification information. Determining the delivery order according to the priority information when the delivery destination priority information on the collection target automobile parts is also retrieved and extracted during the search and extraction of the delivery destination;
Transmitting inquiry information as to whether or not to approve the determined delivery order to the addresses of the search and extracted delivery destinations;
Receiving consent information transmitted from each delivery destination in response to the inquiry information;
Changing the delivery order if necessary based on the received acceptance information,
The delivery management method according to claim 14, wherein the collection information reflects the delivery order. When the delivery destination database stores information on the necessity / unnecessity of collection for each automobile part, when the collection request is received, information on the necessity / unnecessity of collection of the automobile part related to the collection request A step of determining whether or not the information regarding the necessity / unnecessity of the collection extracted by the search indicates that the collection is unnecessary;
16. The method according to claim 12, further comprising a step of transmitting information indicating that collection is not required to a terminal of an automobile sales company that has transmitted the collection request when it is determined that the collection is not required. The delivery management method described in 1. Searching and extracting information on the cause of failure from a failure handling database that stores information on the cause of failure in association with identification information of the auto parts that are not required to be collected when it is determined that the recovery is unnecessary;
The delivery management method according to claim 16, further comprising a step of transmitting information relating to the cause of the failure extracted by searching to the terminal of the automobile company that has transmitted the collection request. Corresponding based on the identification information of the failed automobile part related to the collection list from the verification person database storing the address of the person in charge of verifying the failed automobile part and the identification information of the automobile part in association with each other Retrieving and extracting the address in charge of the verification;
18. The method according to claim 12, further comprising a step of transmitting information on a delivery destination of the failed automobile part and information on a delivery schedule to the retrieved address in charge of verification. Delivery management method. When the verification result is input, from the verification person in charge database that stores the transmission destination address of the verification result of the failed auto part and the identification information of the auto part in association with each other, the faulty auto part related to the collection list is stored. Searching and extracting the corresponding transmission destination address of the verification result based on the identification information;
The delivery management method according to any one of claims 12 to 18, further comprising a step of transmitting the input verification result to a transmission destination address of the verification result extracted and extracted. When the information on the delivery destination is retrieved and extracted, a delivery approval request including the information on the delivery destination and the information on the failure content of the failed automobile part is transmitted to a predetermined approval address. Steps,
Receiving approval approval / disapproval information as a response to the delivery approval request;
When the received approval / disapproval information means approval of delivery, a delivery request is transmitted to the approved delivery destination, and the approval / disapproval information means rejection of approval or change of the delivery destination 20. The delivery management method according to claim 12, further comprising: transmitting the delivery request to a delivery destination designated from the terminal in charge of approval.   A step of transmitting, to the terminal in charge of logistics, information relating to the size and mass read out from the parts database storing information relating to the size and mass for each of the automobile parts, with respect to the failed automobile part being delivered The delivery management method according to claim 12, further comprising: Receiving a change request for content stored in the delivery destination database;
Receiving the change request, transmitting a change approval request to a pre-registered address for change approval;
The delivery according to any one of claims 12 to 21, further comprising a step of permitting a change of contents stored in the delivery destination database when a response to the change approval request means change approval. Management method.   A computer program for causing a computer to execute each step of the delivery management method according to any one of claims 12 to 22.

Images