The present disclosure relates to mobile systems and methods for transportation management.
A transportation management (TM) system is a subset of supply chain management concerning transportation operations and may be part of or associated with an enterprise resource planning (ERP) system. A TM system sits between an ERP or legacy order processing and warehouse/distribution module or company. A typical scenario can include both inbound (procurement) and outbound (shipping) orders to be evaluated by the TM system, the TM system offering the user various suggested routing solutions. These solutions are evaluated by the user for reasonableness and are passed along to the transportation provider analysis module to select the best mode and least cost provider.
The present disclosure involves systems, software, and computer implemented methods for mobile transport tendering. One process includes operations for identifying at least one transportation management server providing information on at least one shipping opportunity, each transportation management server associated with a shipper, identifying the at least one shipping opportunity associated with at least one of the identified transportation management servers at a mobile device, and presenting at least a subset of the at least one identified shipping opportunity at the mobile device. Identifying the at least one shipping opportunity associated with the at least one of the identified transportation management servers can include sending a request to each of the at least one identified transportation management servers for shipping opportunities associated with the shipper and receiving a set of shipping opportunities from at least one of the identified transportation management servers.
While generally described as computer implemented software embodied on non-transitory media that processes and transforms the respective data, some or all of the aspects may be computer-implemented methods or further included in respective systems or other devices for performing this described functionality. The details of these and other aspects and embodiments of the present disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the disclosure will be apparent from the description and drawings, and from the claims.
As markets expand globally and supply chain velocity and complexity increases, entities desire to leverage and optimize their company's transportation management competitively. To do so, entities request sensing changes and appropriate real-time reactions to network events, while improving visibility and responsiveness. Current transportation management applications allow consolidation of orders and optimization of shipments across a company or entity to maximize return on transportation costs. Information can be shared and orders can be combined with carriers and forwarders, allowing the integration of business partners into a company's or entity's transportation processes. Transportation management planning capabilities can enable an entity to, for instance:
Transportation management applications can allow users and entities to calculate and settle freight costs based on actual shipments and current freight rates, and use this information to verify invoices sent from carriers or from self-billing transportation service providers.
More generally, transportation management (TM) can manage the transport of goods from one party to another. TM can also assist a shipper to find an external carrier in the case that it does not want to carry out the transport itself. In this so-called tendering process, transport opportunities (freight requests for quotation) are sent out to one or multiple carriers who can, in turn, submit offers back to the shipper. The offers are then evaluated by the TM system, and the carrier submitting the best offer will be awarded and will later carry out the transport. An effective tendering process requires short reaction times from the carriers. Therefore, it is important that the carriers have ad-hoc access to their opportunities wherever they are (at their office, en route, at the customer, etc.) in order to react as soon as possible.
A carrier can be in contact with multiple shippers, providing the carrier with an overview regarding a set of current opportunities and his own availability. With that knowledge, the carrier can efficiently plan and schedule their offers in order to identify geographical and time-wise synergies and to find the financially most attractive opportunities. As tendering is a time-critical and competitive process, real-time access to new opportunities is key so as to allow the carrier to react immediately at any place or time.
The present disclosure describes a mobile application in the area of tendering that can foster fast and efficient management of transport opportunities and communication between a carrier and its shippers. The mobile application can provide at least the following functionality:
During a tendering process, transport opportunities (e.g., freight requests for quotation) associated with a particular shipper's requirements can be sent out to multiple carriers, where the carriers receiving the opportunities can determine whether to submit a quotation for a particular job. The information included in the transport opportunity can include the parameters of a particular job or operation, including the job or operation's geographic location(s), time requirements, parties, financial considerations, closing bidding time, and/or other factors relevant to the carriers. In the illustrated environment of
Carriers can also benefit through use of the TM application 115. For example, a carrier can be in contact with multiple shippers. In doing so, the carrier can be provided with an overview regarding all current opportunities and the carrier's own availability to determine whether various jobs can be accepted and/or bid upon. The mobile transport tendering application 157 can provide the carrier with relevant information associated with new and available opportunities and the carrier's current availability. With that information, the carrier can efficiently plan and schedule its bidding and current projects in order to identify geographical and time-based synergies. The carrier's real-time access via the mobile device 145 and the transport tendering application 157 provides carriers with an immediate tool for analyzing shipment opportunities. The present disclosure, for example, may be especially beneficial to self-employed truck drivers or other small carrier businesses, allowing them to manage their opportunities and schedules themselves while they are en-route without requiring access to a backend system to perform the scheduling.
In general, the TM server 103 is any server that stores and executes one or more TM applications 115. For example, the TM server 103 may be a Java™ 2 Platform, Enterprise Edition (J2EE)®-compliant application server that includes Java™ technologies such as Enterprise JavaBeans® (EJB), J2EE® Connector Architecture (JCA), Java™ Messaging Service (JMS), Java™ Naming and Directory Interface (JNDI), and Java™ Database Connectivity (JDBC). In some instances, the TM server 103 may store a plurality of various other applications, while in other instances, the TM server 103 may be a dedicated server meant to store and execute a particular TM application 115 and its related functionality. In some instances, the TM server 103 may comprise a web server or be communicably coupled with a web server, where one or more of the TM applications 115 associated with the TM server 103 represent web-based (or web-accessible) applications accessed and executed through requests and interactions received on the mobile device 145, executing the transport tendering application 157 (or other suitable application) operable to interact with the programmed tasks or operations of the corresponding TM application 115.
At a high level, the TM server 103 comprises an electronic computing device operable to receive, transmit, process, store, or manage data and information associated with the environment 100. The TM server 103 illustrated in
As used in the present disclosure, the term “computer” is intended to encompass any suitable processing device. For example, although
In the illustrated implementation of
The interface 106 is used by the TM server 103 to communicate with other systems in a client-server or other distributed environment (including within environment 100) connected to the network 118 (e.g., one of the mobile devices 145, as well as other systems communicably coupled to the network 118). The interface 106 generally comprises logic encoded in software and/or hardware in a suitable combination and operable to communicate with the network 118. More specifically, the interface 106 may comprise software supporting one or more communication protocols associated with communications such that the network 118 or the interface's hardware is operable to communicate physical signals within and outside of the illustrated environment 100.
Generally, the TM server 103 may be communicably coupled with a network 118 that facilitates wireless or wireline communications between the components of the environment 100 (i.e., between the TM server 103, one or more mobile devices 145, and/or the ERP server 125), as well as with any other local or remote computer, such as additional clients, servers, or other devices communicably coupled to network 118, including those not illustrated in
The network 118 may be all or a portion of an enterprise or secured network, while in another instance, at least a portion of the network 118 may represent a connection to the Internet. In some instances, a portion of the network 118 may include a portion of a cellular or mobile data network or other network capable of relaying short message service (SMS) or multimedia messaging service (MMS) messages, as well as other suitable mobile data messaging. In some instances, a portion of the network 118 may be a virtual private network (VPN). Further, all or a portion of the network 118 can comprise either a wireline or wireless link. Example wireless links may include 802.11a/b/g/n, 802.20, WiMax, 3G, 4G (i.e., LTE), and/or any other appropriate wireless link. In other words, the network 118 encompasses any internal or external network, networks, sub-network, or combination thereof operable to facilitate communications between various computing components inside and outside the illustrated environment 100. The network 118 may communicate, for example, Internet Protocol (IP) packets, Frame Relay frames, Asynchronous Transfer Mode (ATM) cells, voice, video, data, and other suitable information between network addresses. The network 118 may also include one or more local area networks (LANs), radio access networks (RANs), metropolitan area networks (MANs), wide area networks (WANs), all or a portion of the Internet, and/or any other communication system or systems at one or more locations.
As illustrated in
Regardless of the particular implementation, “software” may include computer-readable instructions, firmware, wired or programmed hardware, or any combination thereof on a non-transitory medium operable when executed to perform at least the processes and operations described herein. Indeed, each software component may be fully or partially written or described in any appropriate computer language including C, C++, ObjectiveC, Java™, Visual Basic, ABAP, assembler, Perl®, any suitable version of 4GL, as well as others. It will be understood that while portions of the software illustrated in
At a high level, the TM application 115 is any application, program, module, process, or other software that may execute, change, delete, generate, or otherwise manage information associated with a particular TM server 103, and in some cases, one or more business process processes performing and executing business process-related steps and events associated with transportation management. In general, the TM server 103 and the TM application 115 are the central components for planning transportation requirements and performing freight building and the scheduling of transports. Using the TM system 103 and TM application 115, a shipper can manage transportation of goods to a particular buyer, recipient, or customer.
The TM server 103, as illustrated, further includes memory 112 storing information associated with the TM server 103 and TM application 115. Memory 112 can store data and program instructions. Memory 112 may include any memory or database module and may take the form of volatile or non-volatile memory including, without limitation, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media, or any other suitable local or remote memory component. Memory 112 may store various objects or data, including classes, frameworks, applications, backup data, business objects, jobs, web pages, web page templates, database tables, processes, process contexts, repositories storing services local to the TM server 103, and any other appropriate information including any parameters, variables, algorithms, instructions, rules, constraints, or references thereto associated with the purposes of the TM server 103 and the TM application(s) 115. In some implementations, including a cloud-based system, some or all of memory 112 may be stored remotely from the TM server 103, and communicably coupled to the TM server 103 (i.e., via network 118).
In the illustrated example, the TM system 103 and the TM application 115 can access at least a portion of the ERP server 125 and ERP application 137, where additional information associated with sales orders that form the basis of one or more shipments, transports, or other deliveries are stored. The ERP server 125 and ERP application 137 can integrate internal and external management information across an entire organization, including finance/accounting, manufacturing, sales and service, customer relationship management, and other functions. ERP systems can automate activities with the integrated ERP application 137. Generally, the purpose of ERP systems is to facilitate the flow of information between business functions inside the boundaries of the organization and manage the connections to outside stakeholders and entities. In the present example, the ERP applications 137 can provide information associated with particular shipments to the TM server 103, including information on the buyers, sellers, senders and receivers of a particular shipment. The TM server 103 and the TM application 115 can use the information derived from the ERP system to determine and calculate shipping routes, locations, potential shipping contracts and offers, and related metrics and instructions. That information can then be used to produce various requests for quotations (or offers) associated with different shipments, including those that are sent to the one or more mobile devices 145 for review and analysis.
The interface 128, processor 131, and memory 134 of the ERP server 125 may be similar to or different than the interface 106, processor 109, and memory 112 of the TM server 103. The interface 128 generally allows the ERP server 125 to communicate with network 118, the TM server 103, and/or other external systems. The processor 131 generally executes the ERP application 137 and other functionality and/or components associated with or included within the ERP server 125. In some instances, the ERP server 125 may connect directly to the TM server 103, such as when the ERP server 125 and the TM server 103 are combined on a single server or system. In some instances, the functionality of the TM server 103 may be included within the ERP server 125.
The interface 148 of the mobile device 145 may be similar to the interface 106 of the TM server 103, in that it may comprise logic encoded in software and/or hardware in a suitable combination and operable to communicate with the network 118. More specifically, interface 148 may comprise software supporting one or more communication protocols such that the network 118 or hardware is operable to communicate physical signals to and from the mobile device 145. The interface 148 may be specially designed for mobile devices, and may allow for communications with data and cellular networks, as well as Wi-Fi connections.
Similarly, memory 154 of the mobile device 145 may include any memory or database module and may take the form of volatile or non-volatile memory including, without limitation, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media, or any other suitable local or remote memory component. For example, memory 154 may store the transport tendering application 157, backup data, parameters, cookies, variables, algorithms, instructions, rules, mobile device-specific information and instructions, or references thereto. As illustrated, memory 154 may include a set of transport tendering application settings 155. Those settings can include information on one or more TM servers 103 from which opportunities will be received and bids exchanged. In some instances, the mobile device 145 and the transport tendering application 157 may connect with a single TM server 103 and corresponding TM application 115 associated with a single shipping entity, while in other instances, the transport tendering application 157 may connect with a plurality of different TM servers 103 associated with one or more shipping entities. The application settings 155 can be set by a user of the mobile device 145, while in other instances, the application settings 155 may be pushed onto the mobile device 145 by an administrator associated with the mobile device 145 and the transport tendering application 157. In other words, the application settings 155 can define the shippers from which information regarding shipping and bidding opportunities is obtained. In some instances, the settings 155 can direct the mobile device 145 and the transport tendering application 157 to a single system (not illustrated) associated with a carrier for whom the user of the mobile device 145 works or is associated with. That single system can collect the plurality of shipping opportunities and provide them to the transport tendering applications 157 and mobile devices 145 of drivers and other employees associated with the carrier themselves, allowing the transport tendering application 157 to interact with a single system in obtaining the shipping opportunities. In those instances, the single system can relay any bids or responses received from the mobile transport tendering applications 157 to the corresponding TM servers 103 of the various shippers requesting bids. In some implementations, the bids and responses can also be sent directly to the corresponding TM servers 103 from the mobile device 145, even where the shipping opportunities are received from the single system. In general, the application settings 155 may be a table or other suitable file storing information defining one or more connections for the transport tendering application 157, via interface 148, to enable that can provide links to the corresponding systems to retrieve and interact with shipping opportunities provided by one or more shippers.
In some instances, processor 151 may be similar to processor 109. In other instances, the processor 151 may be a processor designed specifically for use in mobile devices such as smartphones or PDAs. Further, although illustrated as a single processor 151, the processor 151 may be implemented as multiple processors in the mobile device 145. Regardless of the type and number, the processor 151 executes instructions and manipulates data to perform the operations of the mobile device 145, including operations to receive and process information from the TM server 103, access data within memory 154, and execute the mobile transport tendering application 157, as well as perform other operations associated with the mobile device 145.
The transport tendering application 157 may be an application provided to one or more different mobile platforms that allows the mobile device 145 to communicate with the TM server 103 and the TM application 115. The transport tendering application 157 can be communicably connected to the TM server 103, and can be used to manage a carrier's or truck driver's (or other entity associated with the mobile device 145) interactions with the TM application 115, and specifically, its requests for quotations and quotations associated with particular transport jobs and operations. The transport tendering application 157 can, in some instances, interpret and decode received messages from the TM application 115 to present information associated with potential and available shipping job offers and possibilities. The functionality of the transport tendering application 157 can provide an essential tool for providing carriers and potential carriers with an overview of one or more requests for quotations available for shipping jobs, an overview of accepted and/or rejected shipping jobs, including the terms associated therewith, as well as interfaces capable of accepting, counter-offering, or rejecting one or more of those offers.
The relay server 215 is used to translate the call from the public internet (i.e., the mobile device 205) into an internal protocol associated with the TM server 230 and ERP server 260 systems. In general, the relay server 215 manages communications to and from a plurality of mobile devices 205, identifying the appropriate location for messages and events while returning responsive messages and events to the TM server 230. In this manner, the user of the mobile device 205 is able to access the internal systems associated with the TM server 230 through the public internet. The relay server 215 further communicates with a mobile enterprise application platform 220 (e.g., Sybase® Unwired Platform). The mobile enterprise application platform 220 can interpret incoming requests and communications from mobile devices 205 to a standard format, as well as package and structure outgoing responses or communications from the TM server 230 into an appropriate mobile device format or structure. The mobile enterprise application platform 220 can further offer services provided by a gateway system 225. Further interpretation and conversion of data can be performed through the gateway system 225, as needed, to provide an appropriate understanding of the data in the backend systems, such as the TM server 230.
The TM server 230 may be similar to the TM server 103 described in
Each transport opportunity may be associated with various parameters, such as start date, end date, location, and other shipment-relevant information. Each carrier 302 or truck driver can review the opportunities on the mobile device 303 using the transport tendering application. At least four types of responses may be available to the carrier 302, including (1) an acceptance of the opportunity based on the terms as provided by the particular shipper; (2) an acceptance contingent on at least one modified parameter as defined by the carrier 302 on the mobile device 303; (3) an explicit rejection of the opportunity, and (4) an implicit rejection of the opportunity, such as the failure to respond to a particular shipment opportunity that has been delivered to and presented on the mobile device 303. The implicit rejection may be based on a bidding or acceptance timeout related to the opportunity and defined by the associated shipper or defined as a default value within the system (e.g., 48 hours prior to the shipment's start date). In some instances, the mobile transport tendering application on the mobile device 303 may perform an analysis and ranking of the potential transport opportunities or offers. The analysis and ranking may at least in part, consider previous accepted opportunities and shipments for the carrier 302, the carrier's current location, the expected location of the carrier on the start date, the availability of the carrier 302, and other relevant information associated with the carrier 302 and available to the mobile device 303. The results can be presented in an optimized manner on the mobile device 303, providing the carrier 302 an efficient review and analysis of the available opportunities. One or more user-defined criteria may also be defined by the carrier 302 to assist the analysis, such as preferred routes, times, and other shipment opportunity parameters.
At 405, at least one TM server associated with at least one shipper or shipping entity is identified. In some instances, two or more TM servers may be identified, such as when the mobile device and the transport tendering application are set to interact with, and receive shipping opportunities from, multiple shipping entities. In other instances, a single, centralized system may be identified, such as where the centralized system collects shipping opportunities for retrieval and interaction through a single location or address. Large carriers may find such an arrangement helpful, as the various TM servers and shippers can be collected at a single system, removing the need for the mobile device and transport tendering application to communicate with a plurality of TM servers individually. In some instances, 405 may be initiated when the transport tendering application is opened.
At 410, at least one shipping opportunity associated with the at least one of the identified TM servers is identified. The shipping opportunities may be identified in response to a request sent from the mobile device and the transport tendering application to at least a subset of the at least one of the identified TM servers. The requests can be sent via one or more network connections associated with the mobile device, and can include a set of information identifying the mobile device and its associated users and/or entities. In some instances, certain shopping opportunities may be available to certain entities or individuals and not to others. The identifying information can be used by the at least one of the identified TM servers to determine which shipping opportunities are to be returned to the mobile device and transport tendering application. In some cases, the information may further include real-time information associated with the user and/or the mobile device, including location information, availability information (e.g., calendar information stored on the mobile device, reference information identifying a remotely stored user account where availability information is stored, etc.). Identifying the at least one shipping opportunity may include receiving a set of information associated with one or more TM servers, where the sets of information including parameters defining each shipping opportunity, including but not limited to, start and end dates, the amount to be paid for the opportunity, start and end points of the transport, as well as other relevant data.
At 415, the at least one identified shipping opportunity identified at 410 is presented at the mobile device. Generally, the shipping opportunities are presented within a GUI associated with the transport tendering application. If more than one shipping opportunity is available and identified at 410, the two or more shipping opportunities can be sorted and prioritized at 415.
At 420, a user action associated with the presented shipping opportunities and the transport tendering application is identified. The user action may be received through a keyboard, buttons, touchscreen, voice control, or other suitable method, including an external component, such as a Bluetooth keyboard. In some instances, the user action associated with the transport tendering application may be inaction, such as the failure to enter or submit a response to a particular offer. In general, tour separate types of user actions may be associated with a particular shipping opportunity. Those user actions include (1) an action indicating the acceptance of a particular shipping opportunity based on the terms as provided by the shipper; (2) an action indicating acceptance of a particular shipping opportunity contingent on at least one modified parameter; (3) a user action indicating an explicit rejection of the shipping opportunity, such as selection of an “Ignore” or “No Response” button (in some instances, explicit rejections may mean a selection of a rejection reason in addition to a particular selection); and (4) user inaction indicating an implicit rejection of a particular shipping opportunity, such as the failure to respond to a particular shipment opportunity within a particular time period. In (2), the contingency may represent a counter-offer to the shipper, such as a modification to the dates of the shipping opportunity or to the amount to be paid to the carrier. When modifications are provided, an additional step may be included in method 400 (not illustrated), where the shipper or the shipper's TM server can respond to the counter-offer. Once the user action is identified, a response is generated and sent to the TM server associated with the at least one shipping opportunity at 425. In some instances, responses may not be sent until a user finalizes his actions and/or selections, or until a predetermined event occurs.
At 430, the shipping opportunity data can be refreshed upon the occurrence of a triggering event associated with a refresh. In some instances, the triggering event may be a manually submitted request to refresh the shipping opportunities from the user associated with the mobile device. In other instances, the triggering event may be the expiration of a predetermined period of time since the previous refresh. In still other instances, the refresh may be based on an indication from one or more TM servers that additional shipping opportunities are available for review. In those instances, messages or notifications in channels outside of the transport tendering application may be provided, such as through SMS messages, emails, or other suitable channels. In other instances, a push notification sent from a particular TM server may indicate that additional opportunities are available. In some instances, one or more shipping opportunities may be pushed to the mobile device. When the refresh occurs, method 400 can return to 410, where the additional shipping opportunities are identified.
At 450, two or more shipping opportunities, each including at least one associated parameter defining the shipping opportunity, are received. The parameters can include a start time and location, an end time and location, a proposed route, a size and type of shipment, an amount to be paid, and other suitable shipping opportunity parameters. These parameters can be used to later evaluate the two or more shipping opportunities. At 455, settings associated with the user of the mobile device are identified. Those settings may include user- and/or carrier-specific settings and preferences that can be used to compare the two or more shipping opportunities. For instance, the user may be located in a particular region of the United States, and may prefer opportunities that can be performed and completed in that particular area. Additionally, information on the user's current location may be identified, such as through the mobile device's GPS data, such that shipping opportunities close in geographical proximity may be preferred. Similarly, information related to the user may include information retrieved from a calendar included on the mobile device, indicating one or more future locations (if location is specified) and/or specific availability of the device's user, allowing that information to be used to evaluate and compare potential shipping opportunities. Various other suitable sets of data may be identified at 455, including carrier-specific preferences defined throughout a company or entity. Those preferences (as well as user-specific preferences) may further include a particular profit margin threshold required for the user and/or carrier to accept the opportunity. In combination with the profit margin, some intelligence may be available at the mobile device to further calculate the costs of the shipping opportunity in order to determine the profit margin to be earned upon performance of the shipping opportunity. In some instances, information on current and/or previously accepted shipping opportunities may also be identified and used to determine if one or more of the shipping opportunities can be fulfilled and/or accepted,
At 460, each of the shipping opportunities is evaluated based on the parameters associated with the particular shipping opportunities in light of the identified settings. In some instances, a correlation score identifying the level of a match of a particular opportunity may be calculated for each opportunity. In some instances, one or more of the shipping opportunities may be removed from the set based on parameters outside the settings or preferences of the user or carrier associated with the user. For instance, if the profit margin for a particular shipping opportunity does not exceed a predetermined amount, that shipping opportunity may be removed from the current set. If the user is unavailable for a particular opportunity based on pre-existing commitments, including a previously accepted opportunity, then overlapping opportunities may be removed. Regardless of the particular method used to evaluate the shipping opportunities, each shipping opportunity can be effectively compared against the other opportunities after the evaluation. Using those comparable scores and/or evaluations, at 465 the set of shipping opportunities can be sorted, or prioritized, based on the previous evaluation. Those sorted opportunities can then be presented as described in
The preceding figures and accompanying description illustrate example processes and computer implementable techniques. But environment 100 (or its software or other components) contemplates using, implementing, or executing any suitable technique for performing these and other tasks. It will be understood that these processes are for illustration purposes only and that the described or similar techniques may be performed at any appropriate time, including concurrently, individually, or in combination. In addition, many of the steps in these processes may take place simultaneously, concurrently, and/or in different orders than as shown. Moreover, environment 100 may use processes with additional steps, fewer steps, and/or different steps, so long as the methods remain appropriate.
In other words, although this disclosure has been described in terms of certain embodiments and generally associated methods, alterations and permutations of these embodiments and methods will be apparent to those skilled in the art. For instance, while the present disclosure has been described in terms of a carrier or user associated with a carrier interacting with the transport tendering application, the mobile device and transport tendering application may be used by a user associated with a logistics service provider, and not a carrier. Accordingly, the above description of example embodiments does not define or constrain this disclosure. Other changes, substitutions, and alterations are also possible without departing from the spirit and scope of this disclosure
This application claims priority under 35 U.S.C, §119 to U.S. Provisional Application No. 61/547,618, filed Oct. 14, 2011, the entire disclosure of which is incorporated herein by reference.
Number | Date | Country | |
---|---|---|---|
61547618 | Oct 2011 | US |