EP1668454A2 - Systemes et procedes destines a la gestion d'une chaine d'approvisionnement - Google Patents

Systemes et procedes destines a la gestion d'une chaine d'approvisionnement

Info

Publication number
EP1668454A2
EP1668454A2 EP04784109A EP04784109A EP1668454A2 EP 1668454 A2 EP1668454 A2 EP 1668454A2 EP 04784109 A EP04784109 A EP 04784109A EP 04784109 A EP04784109 A EP 04784109A EP 1668454 A2 EP1668454 A2 EP 1668454A2
Authority
EP
European Patent Office
Prior art keywords
product
seller
buyer
received
combinations
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP04784109A
Other languages
German (de)
English (en)
Other versions
EP1668454A4 (fr
Inventor
Thomas R. Kroswek
Anthony D. Han
James W. Moore
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ryder Integrated Logistics Inc
Original Assignee
Ryder Integrated Logistics Inc
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
Priority claimed from US10/669,277 external-priority patent/US7711602B2/en
Application filed by Ryder Integrated Logistics Inc filed Critical Ryder Integrated Logistics Inc
Publication of EP1668454A2 publication Critical patent/EP1668454A2/fr
Publication of EP1668454A4 publication Critical patent/EP1668454A4/fr
Withdrawn legal-status Critical Current

Links

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/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management

Definitions

  • the present invention is directed to systems and methods for supply chain management. More specifically, without limitation, the present invention relates to enhanced integration and management of logistics for supply chains.
  • the current logistics process is a tower of Babel. The process of procuring, replenishing, transporting and storing a part or product involves hundreds of disparate, discontinuous and disconnected information systems. For example, a large manufacturer may broadcast its plan raw material requirements and work-in-process requirements using EDI (Electronic Data
  • Interchange formats such as the TDCC 830 format (Transportation Data Coordinating Committee). This format will provide material forecast, but this format does not authorize the release of material.
  • the 862 EDI authorizes the release of a specified quantity of a part and dictates the arrival date of the part quantity. In general this arrival date is a "must arrive by" rather than "must arrive on this unique date”. Following this, a supplier must develop an internal process and information system to parse the 862 into a package quantity, then into a ship quantity, then into a shipment containerization. Currently a part release is not subdivided into an optimum frequency. Rather, the entire release quantity is assume to be shipped at one time, to arrive on or before the scheduled date.
  • the next step in this process is the selection of a transportation mode — LTL (Less Than Truckload), TL (Truckload), Parcel, TOFC (Trailer-On-Flatcar) — followed then by the selection of a specific carrier within that modal selection.
  • This process also is produced by discrete, unique information systems that are not integrated back to the material release itself.
  • the tender of the part shipment is now required. This is a specific communication to a carrier that outlines the shipment, its attributes, time of pick-up and its expected arrival date, (and often specific time appointment). To this point, the buyer's purchase order is the controlling document. At the point of shipment, six new documents are created that are interrelated but historically have been disconnected.
  • BOL Bill of Lading
  • SO Shipping Order
  • FB Freight Bill
  • Manifest Receipt and Packing List.
  • the present invention provides a common, web-enabled communication utility that serves the entire community involved in a product shipment: buyer, transporter, logistics manager and seller.
  • a method of supply chain management includes a variety of steps as describe herein below.
  • An order is received from a buyer or from a seller.
  • the received order includes information regarding one or more ordered products.
  • a buyer and a seller are determined.
  • a product shipment configuration and a logistics plan are generated.
  • a transporter is determined.
  • the generated logistics plan is transmitted to a recipient.
  • the generated product shipment configuration is transmitted to a recipient.
  • the recipient in both cases is usually the buyer, the seller, the transporter or a supply chain management administrator.
  • the scope of the present invention is not limited to the order of steps or segregation of steps described above; rather, the aggregation of steps into single steps or reordering of such steps are specifically contemplated.
  • the above described method may be executed, in whole or in part, by the environment summarized below.
  • one or more of the described steps may be stored as computer executable instructions in and/or on any suitable combination of computer- readable media.
  • one or more steps may be executed by special purpose hardware designed to perform such steps.
  • One preferred embodiment according to the present invention includes a system data store (SDS) and a system processor.
  • SDS system data store
  • the SDS stores data needed to provide the desired supply chain management functionality and may include, for example, product data, manifests, capacity data, schedule data, routing data, event data, exception reports, buyer data, seller data and transporter data.
  • the SDS may include multiple physical and/or logical data stores for storing the various types of information.
  • Data storage and retrieval functionality may be provided by either the system processor or data storage processors associated with, or included within, the SDS.
  • the system processor is in communication with the SDS via any suitable communication channel(s).
  • the system processor may include one or more processing elements that provide and/or support the desired supply chain management functionality. In some embodiments, the system processor can include local, central and/or peer processing elements depending upon equipment and the configuration thereof.
  • FIG. 1 graphically depicts an environment architecture framework that could be used to support one or more embodiments of the present invention, or portions thereof.
  • FIG. 2 is a diagram of a logical architecture for supporting various embodiments of the present invention.
  • FIG. 3 is a flow chart depicting an exemplary process according to the present invention.
  • FIG. 4 is a flow chart depicting the steps in an exemplary process for product shipment configuration and logistics plan generation.
  • FIG. 5 is a diagram showing potential software modules in an exemplary logistics management suite according to the present invention.
  • FIG. 6 is a flow chart depicting data flow in the logistics planning and data management systems.
  • FIG. 7 is a flow chart depicting data flow in the release management system.
  • FIG. 8 is a flow chart depicting data flow in the execution management system.
  • FIG. 1 depicts one logical architecture framework 100 for implementing various aspects of the present invention.
  • the framework 100 includes various computers interconnected via an Ethernet 150.
  • the Ethernet 150 in terms connects to the Internet 160 via router 140 and firewall 145.
  • Various users of the environment such as sellers 170A, 170B, buyer 190 and transporters 180A, 180B can access the environment via the Internet 160; it will be readily appreciated by those skilled in the art that any number of sellers, buyers and/or transporters can access the environment and that the depiction of a limited number is purely for exemplary purposes.
  • the users typically access the environment through access servers 120 which can include any combination of suitable servers such as Web servers, e-mail servers, automated voice response systems, etc.
  • the access servers 120 query the processing servers 130 to process and format data for return to the users via the access servers.
  • the processing servers 130 in term retrieve data from data storage servers 110.
  • the collective processing elements of the various servers form the system processor that supports the supply chain management functionality of the present invention.
  • the data storage devices and servers form the system data store (SDS) that supports the storage of data required for providing the desired functionality of the present invention.
  • SDS system data store
  • the access servers 120 and other resources of the framework 100 connected to Ethernet 150 can be connected behind firewall 145 that protects these resources from the unauthorized intrusion by users attempting to gain access to the framework 100 via the Internet 160.
  • the access servers 120 can be connected between firewall 145 and a second firewall (not shown) to further insulate the remaining resources of the framework 100 from unauthorized access.
  • the supply chain management methods of the present invention may be utilized
  • processing element 210 may refer to (1) a process running on a particular piece, or across particular pieces, of hardware, (2) a particular piece of hardware, or either (1) or (2) as the context allows.
  • Each processing element may be supported by one or more general purpose processors such as Intel-compatible processor platforms including PENTIUM IV or CELERON (Intel Corp., Santa Clara, CA), UltraSPARC (Sun Microsystems, Palo Alto, CA) and/or Athlon (Advanced Micro Devices, Sunnyvale, CA) and/or one or more optimized local processors such as a digital signal processors (DSPs), application specific integrated circuits (ASICs) and/or field programmable gate arrays (FPGAs).
  • DSPs digital signal processors
  • ASICs application specific integrated circuits
  • FPGAs field programmable gate arrays
  • the depicted hardware components include an SDS 215 that could include a variety of primary 220 and secondary 230 storage elements.
  • an SDS 215 could include RAM as part of the primary storage 220; the amount of RAM might typically range from 64 MB to 2 GB in each individual hardware device although these amounts could vary.
  • the primary storage 220 may in some embodiments include other forms of memory such as cache memory, registers, non-volatile memory (e.g., FLASH, ROM, EPROM, etc.), etc.
  • the primary storage 220 may communicate with the system processor, or particular elements thereof, in a standard manner or manners (pathway 222), including without limitation on chip communication path and/or serial and/or parallel bus pathways inter- and/or intra-board.
  • SDS 215 may also include secondary storage 130 containing single, multiple and/or varied servers and storage elements.
  • SDS 215 may use internal storage devices connected to the system processor 210.
  • one or more local hard disk drives and/or one or more removable media drives may serve as the secondary storage of the SDS 215 communicating with the processing element via a suitable direct connection 232 such as an IDE, USB or SCSI bus connection or through a network connection to locally accessible network connected storage (not shown), and a disk operating system executing on such a single processing element may act as a data server receiving and servicing data requests.
  • a suitable direct connection 232 such as an IDE, USB or SCSI bus connection or through a network connection to locally accessible network connected storage (not shown)
  • a disk operating system executing on such a single processing element may act as a data server receiving and servicing data requests.
  • the architecture of the secondary storage of the computer storage 215 may vary significantly in different environments.
  • database(s) can be used to store and manipulate the data such as resources and/or version metadata; in some such embodiments, one or more relational database management systems, such as DB2 (IBM, White Plains, NY), SQL Server (Microsoft, Redmond, WA), ACCESS (Microsoft, Redmond, WA), ORACLE 8i (Oracle Corp., Redwood Shores, CA), Ingres (Computer Associates, Islandia, NY), MySQL (MySQL AB, Sweden) or Adaptive Server Enterprise (Sybase Inc., Emeryville, CA), may be used in connection with a variety of storage devices/file servers that may include one or more standard magnetic and/or optical disk drives using any appropriate interface including, without limitation, IDE and SCSI.
  • DB2 IBM, White Plains, NY
  • SQL Server Microsoft, Redmond, WA
  • ACCESS Microsoft, Redmond, WA
  • ORACLE 8i Oracle Corp., Redwood Shores, CA
  • Ingres Computer Associates, Islandia, NY
  • a tape library such as Exabyte X80 (Exabyte Corporation, Boulder, CO), a storage attached network (SAN) solution such as available from (EMC, Inc., Hopkinton, MA), a network attached storage (NAS) solution such as a NetApp Filer 740 (Network Appliances, Sunnyvale, CA), or combinations thereof may be used.
  • the data store may use database systems with other architectures such as object-oriented, spatial, object- relational, network or hierarchical. Instead of, or in addition to, those organization approaches discussed above, certain embodiments may use other storage implementations such as hash tables or flat files or combinations of such architectures.
  • Such alternative approaches may use data servers other than database management systems such as (1) a hash table look-up server, procedure and/or process and/or (2) a flat file retrieval server, procedure and/or process.
  • the computer storage 215 may use a combination of any of such approaches in organizing its secondary storage architecture.
  • the hardware components may each have an appropriate operating system such as WINDOWS/NT, WINDOWS 2000 or WLNDOWS/XP Server (Microsoft, Redmond, WA), Solaris (Sun Microsystems, Palo Alto, CA), or LINUX (or other UNIX variant).
  • a typical environment includes a WLNDOWS/XP (or other WINDOWS family) operating system.
  • Client platforms accessing the supply chain management servers such as wireless devices and/or PDAs may use an appropriate operating system such as Windows/CE, PalmOS, or other suitable mobile phone or PDA operating system.
  • appropriate server software may be included to support the desired access for the purpose of configuration, monitoring and/or reporting.
  • Web server functionality may be provided via an Internet Infonnation Server (Microsoft, Redmond, WA), an Apache HTTP Server (Apache Software Foundation, Forest Hill, MD), an iPlanet Web Server (iPlanet E-Commerce Solutions - A Sun - Netscape Alliance, Mountain View, CA) or other suitable Web server platform.
  • the e-mail services may be supported via an Exchange Server (Microsoft, Redmond, WA), LotusNotes, Groupwise, sendmail or other suitable e-mail server.
  • Some embodiments may include one or more automated voice response (AVR) systems that are in addition to, or instead of, the aforementioned access servers.
  • AVR automated voice response
  • Such an AVR system could support a purely voice/telephone driven interface to the environment with hard copy output delivered electronically to suitable hard copy output device (e.g., printer, facsimile, etc.), and forward as necessary through regular mail, courier, inter-office mail, facsimile or other suitable forwarding approach.
  • the present invention synchronizes the logistics information regarding a product shipment with the material release information throughout the life of a product shipment from material release through receipt of the material specified in the release. It also provides a common communication utility to all parties in the chain. This communication utility is available by internet access to any party using commonly available web browsing software.
  • Systems and methods according to the present invention in various embodiments can process the raw information of the material release — e.g., number of products and time to deliver by — and produces a rich data product that provides, for example,: the number of packages required for a material release the number of shippable containers — packages, pallets, containers — for a material release the planned schedule for the sequence of events that comprise the life of a shipment an electronic link between the shipment and the original material release an electronic link between the shipment information and the shipper's Bill of Lading.
  • a logistics release is the capability to configure a specific product amount within a Bill of Material into an optimum shipment. This capability includes weight, cube, packaging, stackability, pallet configuration and mode determination. It further includes the planned schedule of events for a shipment and a process to measure plan progress to actual.
  • the present invention produces the synchronization of the manufacturing release with inventory requirements and a broad logistics network.
  • the present invention solves the logistics communication problem and provides a logistics plan for every included product.
  • the present invention establishes the base logistics plan for the shipment events, and the event management capability monitors and intervenes appropriately as shipments vary from planned performance. Subsequent to the logistic release, the shipments flow through a sequence of events that are managed using the alert system within an operational management system (JIT EMS), which can be included in some embodiments of the present invention. Accordingly, the present invention synchronizes the manufacturing release with the logistics network eliminating miscommunication between manufacturing, the supplier, the logistics provider and the carrier. Any participant in the shipment can link the product, the FB, the PO (purchase order), the SO, the BOL with the original material release. At the same time, all participants share the plan for the shipment and are simultaneously informed regarding changes to that plan.
  • step 310 an order for one or more products is received from a supply chain participant such as a buyer or a seller. If the order originates from a buyer, the order represents items to be purchased from one or more sellers. If the order originates with a buyer, the order represents items sold to one or more buyers. In some instances, the received order may originate with another participant in the supply chain. This may occur if neither buyer nor seller uses supply management according to the present invention, however, the participant does and wishes to receive the benefits of such use and/or provide the buyer and/or the seller with access to information regarding the processing of an order.
  • the order is received via one or more access server; these access servers can include, without limitation, web servers, e-mail servers, ftp servers, interactive voice/tone response systems, and/or fax servers.
  • these access servers can include, without limitation, web servers, e-mail servers, ftp servers, interactive voice/tone response systems, and/or fax servers.
  • the received order can be formatted according to a format independent from any format used by any supply chain participant and specific to the supply chain management administrator.
  • the received order can, in some embodiments, be stored in a system data store.
  • steps 320 and 330 as further described below can involve accessing the system data store for the stored order, or portions thereof.
  • a buyer and a seller are determined for each product in the received order. In some cases, multiple buyers and/or sellers can be determined.
  • determination of the buyer and the seller for each product involves accessing a system data store for data relevant to the determination such as product data and/or the received order.
  • the determination can occur in a variety of ways and depend upon a variety of criteria.
  • the buyer and/or seller can be determined through direct reference to the received order. For instance, the received order could directly include a specific reference to the buyer and/or seller. Alternatively, for a given product in the received order, only a single buyer may exist who uses the product, and/or only a single seller may make the product.
  • the determination can include the steps of: (a) retrieving an entry for each product from a system data store, (b) identifying the buyer for each product from the received order, the retrieved entry or combinations thereof, and (c) identifying the seller for each product from the received order, the retrieved entry or combinations thereof.
  • the identification of the seller in such embodiments, or the determination of the seller in other embodiments can include selecting a seller based upon one or more criteria such as pricing constraints, volume constraints, distance constraints, time constraints, performance constraints, financial constraints, and/or combinations thereof. Such criteria could be used for selecting among a several potential sellers for a given product.
  • a product shipment configuration and a logistics plan are generated. In some instances, multiple configurations and/or logistics plan can be generated.
  • the product shipment configuration and logistics plan are generated based upon a variety of factors that can include, without limitation, the received order, the determined seller, the determined buyer and combinations thereof. In some embodiments, this step involves accessing a system data store for data relevant to the determination.
  • FIG. 4 is a flow chart depicting the steps in an exemplary process for generating a product shipment configuration and a logistics plan.
  • a product entry for each product in the order is retrieved from a system data store.
  • the product entry at least contains containerization constraints for each such product. Alternatively, some embodiments can forego the entry retrieval step where containerization constraints are provided in the received order.
  • containerization constraints for each product are identified. The containerization constraints can be determined from the entry retrieved in step 410..
  • the containerization constraints can be identified through direct reference to the received order.
  • containerization constraints could be retrieved via a query to the determined seller over a suitable communication channel; for example, the product information could be requested via a suitable web or ftp request to a site hosted by the determined seller.
  • a containerization plan for each product is developed based upon its associated containerization constraints and the received order. The development of the plan can occur according to any of the approaches generally known to those skilled in the art.
  • the received order is allocated into one or more shipments based upon the containerization plan.
  • the allocation of the order into shipments involves comparing the capacity requirements of the order as defined in the containerization plan with capacity information for a selected cargo space (e.g., particular trailer, cargo bay of plane or ship, boxcar, etc.).
  • a cargo space selection process such a process could base selection on a number of criteria including, without limitation, he received order, the containerization plan, cargo space availability, destination of a shipment, cost, cargo space capacity, origin of a shipment and/or combinations thereof.
  • a route plan is developed to satisfy the one or more shipments. The developed route plan is based at least in part upon the allocation of the received order into shipments and the received order.
  • the route planning can occur according to any of the approaches generally known to those skilled in the art.
  • the route plan development can include optimizing mode of shipment, cost of transport, speed of shipment and/or combinations thereof.
  • a transporter is determined.
  • multiple transporters can be determined. This determination can occur in a variety of ways and depend upon a variety of criteria. In some instances, the determination is limited to a select set of one or more transporters. This can occur, for instance, where the order is received from a particular transporter; in such an instance, the set from which to determine the transporter could be limited to the transporter providing the order.
  • the buyer or seller may have relationships with a predefined set of transporters, and the determination of transporter may therefore be limited to this predefined set, or possibly the intersection of the buyer's predefined set and the seller's predefined set.
  • the determination of transporter can be based upon a variety of factors including, without limitation, the generated logistics plan, the determined buyer, the determined seller, the received order or combinations thereof.
  • the received order could be required to dictate a particular transporter; in such embodiments, the transporter is directly determined by referencing the received order.
  • determination of the transporter involves accessing a system data store for data relevant to the determination.
  • a product shipment configuration is transmitted to one or more participants (e.g., buyer, seller, transporter, depot operator, etc.) in the supply chain, to one or more computer systems or to one or more supply chain management administrator.
  • the delivery platform for the transmitted product shipment configuration can be any suitable platform providing the product shipment configuration in a format perceivable by the recipient such as e-mail, web, ftp, fax, courier service, postal mail, pager, telephone and/or combinations thereof.
  • the product shipment configuration can include a three-dimensional model of a selected cargo with the configured shipment rendered therein.
  • This transmission can occur automatically, as the result of a trigger event and/or as a result of the receipt of a product shipment configuration request from a participant depending upon the mechanism(s) supported in a particular embodiment.
  • a request can be received by any suitable access server.
  • the recipient of the product shipment configuration can be determined from the request (e.g., requestor, other recipient indicated by an identifier in the request, etc.).
  • a notification of the readiness of a generated product shipment configuration can be sent to one or more supply chain participants.
  • the notification can include a link that upon activation generates a product shipment configuration request.
  • a logistics plan is transmitted to one or more participants in the supply chain (e.g., buyer, seller, transporter, warehouse operator, freight yard, etc.), to one or more computer systems or to one or more supply chain management administrator.
  • the delivery platform for the transmitted product shipment configuration can be any suitable platform providing the product shipment configuration in a format perceivable by the recipient such as e-mail, web, ftp, fax, courier service, postal mail, pager, telephone and/or combinations thereof.
  • This transmission can occur automatically, as the result of a trigger event and/or as a result of the receipt of a logistics plan request from a participant depending upon the mechanism(s) supported in a particular embodiment.
  • such a request can be received by any suitable access server.
  • the recipient of the logistics plan can be determined from the request (e.g., requestor, other recipient indicated by an identifier in the request, etc.).
  • a notification of the readiness of a generated logistics plan can be sent to one or more supply chain participants.
  • the notification can include a link that upon activation generates a logistics plan request.
  • product data can be received from one or more product sellers. This received product data is stored in a system data store. The received product data can include information such as price, capacity, containerization constraints or other data relevant to the product.
  • Containerization constraints can include product height, weight, volume, packaging, stackability and/or other data defining product characteristics relevant to developing containerizaiton plans with respect to the product.
  • the received data is formatted in accordance with a format specified by the supply chain management administrator that is independent from any format used by any supply chain participant.
  • the product data can be received in some embodiments via one or more access servers; these access servers can include, without limitation, web servers, e-mail servers, ftp servers, interactive voice/tone response systems, and/or fax servers. Further, the above process has been described with respect to a single received order.
  • event data associated with a logistics plan can be received.
  • the event data can represent any desired occurrence or circumstance associated with the logistics plan.
  • the event data can be generated manually (e.g., manual entry of receipt of shipment at depot, phone call from driver indicating delay due to construction, etc.) or automatically (e.g., sensor on truck determining flat tire and wirelessly signaling same, etc.).
  • the event data can originate from any suitable source including, without limitation, a supply chain participant, a supply chain management administrator, a governmental authority (e.g., police report, weight station, etc.) and/or combinations thereof.
  • an access server can be used to received submitted event data.
  • the receipt of event data can trigger transmission of notifications to one or more recipients in certain embodiments.
  • the recipient can be a user or a computer system.
  • the recipient for the notification can be predetermined or selected; selection of the recipient can be based upon a number of factors including, without limitation, the received event data, the logistics plan and/or combinations thereof.
  • the notification can include identification information associated with the received event data.
  • the identification information can include a link that upon activation by the recipient provides access to the received event data.
  • one or more exception reports can be generated based upon the received event data and the generated logistics plan.
  • a notification of the generation of exception reports can be transmitted to one or more recipients.
  • the notification can include identification information associated with each member of a subset of the generated exception reports; the subset includes at least one, but potentially all, of the generated exception reports.
  • the subset of exception reports included within a notification can be selected based upon a variety of factors including, without limitation, priority of the exception report, recipient of the notification, configuration information associated with the logistics plan and/or combinations thereof.
  • the recipient of the notification can be any suitable user or computer system.
  • the notification can be delivered via any suitable delivery platform including without limitation, e-mail, web, ftp, fax, courier service, postal mail, telephone, pager and/or combinations thereof.
  • one or more generated exception reports can be outputted to any suitable recipient such as a user or a computer system.
  • any suitable delivery platform can be used for delivering the generated exception report such as e-mail, web, ftp, fax, courier service, postal mail, telephone, pager and/or combinations thereof.
  • the delivery platform is determined based upon the intended recipient.
  • the user recipient of the exception report will typically be a supply chain participant or a supply chain management recipient; however, nothing precludes delivery to an interest user who is not a member of these communities of users.
  • the computer recipient of the exception report will typically be an analytical system such as an evaluation systems that evaluates buyers, sellers and/or transporters, notification generation systems, etc.
  • an exception report is selected for output; in some such embodiment, the selection is based upon a priority associated with each exception report, the identity of intended recipient and/or combinations thereof.
  • output of the generated exception report can result from the receipt of an exception report request.
  • a request could, in some of these embodiments, be received via any suitable access server.
  • a notification of the exception report including a link to the exception report could be triggered by a user thereby generating a request to a Web server that provides an HTML formatted version of the generated report.
  • the various steps, or subsets thereof, can be implemented through one or more software modules.
  • FIG. 5 provides a block diagram for software modules in one preferred embodiment.
  • a logitics management suite (LMS) 500 includes software modules: logistics planning system (LPS) 520, data management system (DMS) 530, release management system (RMS) 540 and execution management system (XMS) 550.
  • LMS logistics planning system
  • DMS data management system
  • RMS release management system
  • XMS execution management system
  • LMS database 510 connects to software modules.
  • the supply chain management functionality can be distributed among these software modules that in some embodiments execute on the system processor and system data stores discussed above.
  • the foregoing discussion provides an exemplary allocation of a variety of functionality among these software modules; it will be understood that different embodiments can employ other allocations. Further, other embodiments could employ alternative software modules for providing the desired functionality.
  • the LPS 520 performs various tasks associated with logistics planning.
  • FIG. 6 is a flow chart of data flow through the LPS 520 and DMS 530 modules.
  • the release forecast 610 receives a raw release forecast as input. This raw release forecast can be imported into the LPS from an external source or from an internal source such as the LMS database. The output of this process is the release forecast.
  • the release forecast is fed into the planning session process 620 that creates, updates, revises and/or deletes planning session loads and/or shipments.
  • the output of this process is combined with shipment product container to generate the session loads and shipments 650.
  • the shipment product containerization is generated through the shipment configuration process 630.
  • the shipment configuration process in turn relies on product data (containerization constraints) supplied by the data management process 640.
  • This process 640 retrieves this information from an external source such as a product manufacturer or from an internal source such as the LMS database 550. In certain embodiments, this process 640 is responsible for caputre and validation of containerization information for products.
  • the session loads and shipments 650 are fed as input into the RMS 540. In one preferred embodiment, the RMS 540 of FIG.
  • FIG. 7 is a flow chart of data flow through the RMS 540 module. Session loads and shipments from the LPS and DMS are fed into the load generator (dispatch) 710.
  • This process 710 scans loads and shipments and generates loads and shipments for a specified date in the future.
  • the output dispatched loads from this process 710 are fed into the loads to release matching process 720.
  • This process 720 matches releases with proposed loads and shipments; it assigns products and their quantities to each shipment. It receives release information from release processing 730 that transforms raw release information 735 into a form usable in the matching process 720.
  • the results of the matching process are fed into the proposed load review process 760.
  • This process creates, updates, revises and/or deletes loads and shipments in order to satisfy releases.
  • the process can in certain embodiments include sending proposed shipments to an optimization engine and importing the resultant load plans.
  • the status of the loads and shipments that satisfy the releases are changed from proposed to actual, resulting in the actual loads, shipments and/or releases 725. These actual loads, shipments and releases are then optionally subject to review 740.
  • the actual logistics release information is made available 750 to participants in the supply chain or other interested users such as via a Web site.
  • the actual loads, shipments and/or releases 725 are made available to the XMS for further use.
  • the XMS 550 of FIG. 5 performs various tasks associated with release management.
  • Such tasks can include: (1) activating loads and turning them into trips, (2) creating, editing, updating, and/or deleting trips and shipments, (3) monitoring active trips, (4) capturing trip and shipment events, (5) generating reports and other required documents (e.g., BOL, product manifest, etc.), (6) maintaining transporter information such as driver information, tractor information, cargo space information, etc., (7) tendering shipments and/or (8) exception management and/or reporting.
  • FIG. 8 is a flow chart of data flow through the XMS 550 module. Actual loads, shipments and/or releases 725 are provided from the RMS 540. The trip activation process 810 takes this information and generates active trips, shipments and/or releases 820.
  • a trip maintenance process 830 monitors event data 840 representing occurrences during the trip.
  • the process reads the active trips, shipments and/or releases 820 and updates as required based upon the monitored event data.
  • the active trips, shipments and/or release information can also, in certain embodiments, be made available to supply chain participants and/or other interested parties through any suitable access server such as via a Web site.
  • various publications may have been referenced. The disclosures of these publications in their entireties are hereby incorporated by reference into this application in order to more fully describe the state of the art to which this invention pertains. The embodiments described above are given as illustrative examples only.

Landscapes

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

Abstract

L'invention concerne des systèmes et des procédés destinés à la gestion d'une chaîne d'approvisionnement. Une commande d'un ou plusieurs produits est reçue d'un acheteur ou d'un vendeur. Pour chaque produit dans la commande reçue, un acheteur et un vendeur sont déterminés. Dans quelques modes de réalisation, plusieurs acheteurs et/ou vendeurs peuvent être déterminés. Une conception de livraison des produits et un plan logistique sont produits. Un transporteur est déterminé. La conception de livraison des produits générée est transmise à un acheteur, un vendeur, un transporteur ou des combinaisons de ceux-ci. Le plan logistique produit est transmis un acheteur, un vendeur, un transporteur ou des combinaisons de ceux-ci. Dans de tels modes de réalisation, des données d'événements relatives au plan logistique produit sont reçues. Dans quelques modes de réalisation, des rapports d'exception sont produits à partir des données d'événement reçues. Ces procédés, ou des sous-ensembles de ceux-ci, peuvent, dans certains modes de réalisation, être mis en oeuvre sur un processeur de système en communication avec un magasin de données du système ou être stockés sous la forme d'instructions pouvant être exécutées sur un ou plusieurs supports lisibles par ordinateur.
EP04784109A 2003-09-23 2004-09-13 Systemes et procedes destines a la gestion d'une chaine d'approvisionnement Withdrawn EP1668454A4 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US10/669,277 US7711602B2 (en) 2003-09-23 2003-09-23 Systems and methods for supply chain management
US56163804P 2004-04-13 2004-04-13
PCT/US2004/030140 WO2005033849A2 (fr) 2003-09-23 2004-09-13 Systemes et procedes destines a la gestion d'une chaine d'approvisionnement

Publications (2)

Publication Number Publication Date
EP1668454A2 true EP1668454A2 (fr) 2006-06-14
EP1668454A4 EP1668454A4 (fr) 2007-06-20

Family

ID=34426347

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04784109A Withdrawn EP1668454A4 (fr) 2003-09-23 2004-09-13 Systemes et procedes destines a la gestion d'une chaine d'approvisionnement

Country Status (4)

Country Link
EP (1) EP1668454A4 (fr)
AR (1) AR045946A1 (fr)
CA (1) CA2539820A1 (fr)
WO (1) WO2005033849A2 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210272037A1 (en) * 2018-07-24 2021-09-02 Truckl Llc Systems for supply chain event management

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050149453A1 (en) * 2003-12-30 2005-07-07 United Parcel Service Of America, Inc. Systems and methods for integrated global shipping and visibility

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
No Search *
See also references of WO2005033849A2 *

Also Published As

Publication number Publication date
WO2005033849A2 (fr) 2005-04-14
WO2005033849A3 (fr) 2006-12-21
EP1668454A4 (fr) 2007-06-20
AR045946A1 (es) 2005-11-16
CA2539820A1 (fr) 2005-04-14

Similar Documents

Publication Publication Date Title
US7711602B2 (en) Systems and methods for supply chain management
US7130771B2 (en) System and method for optimization of and analysis of insulated systems
KR102495084B1 (ko) 컴퓨터에 의해 결정되는 효율적인 패키징 결정을 위한 시스템 및 방법
JP2007524937A (ja) 国際統合追跡及び仮想在庫システム
US20090125425A1 (en) Auditable merchandise delivery using an electronic bill of lading
US11379907B1 (en) Systems and computerized methods for item correlation and prioritization
KR102410342B1 (ko) 네트워크 혼잡을 완화시키기 위해 다수 사용자 요청을 풀링하기 위한 시스템 및 방법
KR102575655B1 (ko) 데이터의 동적 집계와 데이터 손실의 최소화를 위한 시스템 및 방법
KR20200111091A (ko) 배송 웨이브 시스템을 사용하여 자동 패키지 재주문을 하기 위한 시스템 및 방법
KR20210033871A (ko) 주문된 물품의 컴퓨터-결정된 효율적인 배깅을 위한 시스템 및 방법
KR20240046468A (ko) 극히 높은 서버 가용성을 위해 네트워크 부하를 밸런싱하는 시스템 및 방법
JP2023058668A (ja) 配送ウェーブシステムを使用した自動荷物再注文のためのシステムおよび方法
EP1668454A2 (fr) Systemes et procedes destines a la gestion d'une chaine d'approvisionnement
KR20210099536A (ko) 전자 재고 및 반품 물품 조정을 위한 시스템 및 방법
US20030233291A1 (en) System and method for managing cargo shipment
MXPA06003311A (es) Sistemas y metodos para la administracion de cadenas de suministros
US11687880B2 (en) Aggregated supply chain management interfaces
US8131573B1 (en) Method to facilitate the transport of shipments via hub based facilities
US20220207449A1 (en) Order management with supply chain management system and platform
CA3170807A1 (fr) Systeme et methode de surveillance d'un stock et transport des materiaux entre les parties
WO2003017163A1 (fr) Systeme destine a faciliter les transactions entre des acheteurs de marchandises et des fournisseurs de services
JP2006018442A (ja) サーバ装置、及びその制御方法
IE85546B1 (en) Method and apparatus for delivery rescheduling

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060407

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL HR LT LV MK

DAX Request for extension of the european patent (deleted)
PUAK Availability of information related to the publication of the international search report

Free format text: ORIGINAL CODE: 0009015

REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1090721

Country of ref document: HK

RIC1 Information provided on ipc code assigned before grant

Ipc: G06G 1/14 20060101AFI20070129BHEP

RIN1 Information on inventor provided before grant (corrected)

Inventor name: MOORE, JAMES, W.

Inventor name: HAN, ANTHONY, D.

Inventor name: KROSWEK, THOMAS, R.

A4 Supplementary search report drawn up and despatched

Effective date: 20070518

17Q First examination report despatched

Effective date: 20071119

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20080530

REG Reference to a national code

Ref country code: HK

Ref legal event code: WD

Ref document number: 1090721

Country of ref document: HK