Patent Application
20180018620
This invention relates generally to the field of implementing supply chain visibility updates.
Today's yard management systems either are based on a four fences, e.g. inside the yard, view of the world or consist of electronic data interchange (EDI) techniques with which interested parties or players can send messages to each other and with which everyone has their own copy of the information. In a four fences view of the world a trailer/shipment is entered into the system when it arrives at the facility and such trailer/shipment leaves the system when the trailer/shipment leaves the facility. In a more integrated world where trading partners share planned arrival and departure information interested parties may include parties at the source of a shipment, at the destination of the shipment, or with the carrier of the shipment, etc. One problem with that is each party may have a slightly different language from another party. For example, shippers may use different terminology than carriers. Thus, systems may need to translate data from one language to another. As well, EDI is not real-time; EDI requires an individual to type in the relevant data. Sometimes the data are processed in batch mode. The net effect is that informational data may arrive six to 24 hours after an important event actually transpires.
One container monitoring disclosure that tracks location and load status of shipping containers within a defined premises and generates container status reports for customers receiving containers, suppliers or shippers of goods, and container carriers is disclosed in U.S. Pat. No. 5,712,789, CONTAINER MONITORING SYSTEM AND METHOD, (Jan. 27, 1998) to Joseph E. Radican. Specifically, carrier and container identifiers are used to track and monitor movements and status of each container from a point of departure to a final destination and return. A combined computer and telecommunications system is also disclosed for executing the tasks of the container monitoring system.
As well, container and inventory monitoring methods and systems that provide detailed logistical control of containers, shipping racks and resident and in-transit inventory are disclosed in U.S. Pat. No. 6,148,291, CONTAINER AND INVENTORY MONITORING METHODS AND SYSTEMS (Nov. 14, 2000) to Joseph E. Radican. In particular, the methods and systems create and maintain accurate real-time records and actionable updates of the location, movement, and load status of containers, racks, and inventory within the facility boundaries and between facilities such as factories, assembly plants, warehouses, shipping yards, and freight switching facilities. Detailed data on container switching, unloading and loading activity is recorded and archived. A virtual inventory accounting is provided by tracking from customer release orders to supplier shipments and rack returns.
Existing Yard Management Systems (YMS) are limited to tracking trailer and shipment status within the four fences of a facility; at best they receive tardy planning data through EDI or similar interfaces. However, shipments are loaded onto a trailer in one facility and are transported to another, where they are ultimately unloaded. That is, clearly there are shipments that are loaded or unloaded at multiple facilities. When tracking shipments within the four fences only, the full status of a particular shipment progress is not available for planning or for monitoring progress across all the players. Because different players may use or need different semantics to depict the shipment and shipment progress, keeping such different players on the same page remains a challenge.
Techniques for implementing visibility updates within a supply chain include storing event data on a non-transitory computer-readable storage medium accessible over a network to a plurality of partners, the event data corresponding to at least one event associated with an item while the item was in possession of a first partner, the item having traveled through the supply chain. While the item is in possession of the first partner, the innovation blocks access to modifying the stored event data by a second partner, however permits the second partner to have visual access to the stored event data, until the second partner is in possession of the item. Then, the first partner is denied access to modifying the stored event data, however is permitted visual access to the stored data.
Embodiments are provided which enable a variety of end-users to manage trailers, trailer visits, drivers, driver visits, as well as shipments across supply chains. It is recognized that according to today's status quo, there are multiple conflicting definitions of what precisely these terms, such as for example a trailer visit or a shipment, mean. Herein is described a generalized approach that accommodates and works with existing definitions.
The embodiments are founded upon a unique data model, referred to as the least common denominator model. The model reflects the recognized and leveraged data regarding trailers and shipments which are common to all end users. Importantly, the least common denominator model facilitates the mapping of trailer states to shipping states. An exemplary spreadsheet is provided that illustrates such mapping. The data in the model may be shared among varied types of end users, such as for example shippers, carriers, drivers, persons at headquarters, etc. Thus, the least common denominator model allows for the provision of universal dashboards for shipment and trailer management, because the different type of end users are able to share common types of data and terminology. As well, the novel and inventive least common denominator model allows for and facilitates a vast amount of data regarding trailers and shipments being stored and mined at the corporate level as well as at the local, e.g. yard, level. Thus, the least common denominator data model combined with the vast and varied data stored at the corporate level and even the local level allow for the computing of meaningful, optimized statistics regarding trailers and shipments.
Further, it is recognized that while the least common denominator model is at an appropriate level of detail as a common language among various end-users, each end-user, based on his or her job and role, requires one or more additional levels of information to perform his or her tasks. Embodiments allow such detail at a local level. In an embodiment, each local facility has the ability to extend its trailer model and the embodiment then provides for mapping the local trailer state to the least common denominator model.
Three novel and inventive concepts are described herein. The first may be referred to as “Managing Trailers and Shipments across the Supply Chain.” This novel and inventive concept encompasses the least common denominator model and its numerous applications including but not limited to shipment execution, performance metrics, modeled exceptions, unmodeled exceptions, capturing trailer states, and the like. A second novel and inventive concept described herein may be referred to as, “Generalized Dashboards for Shipment/Trailer Management; Ability to monitor meaningful statistics.” This novel and inventive concept, employing the least common denominator model, provides a universal view of and access to the shipment data, which facilitates planning and real-time remediation regarding planned operation as well as exceptions, both modeled and unmodeled. A third novel and inventive concept described herein may be referred to as, “Generalized Analysis and Optimization for Shipment/Trailer Visit Management; Ability to analyze/optimize meaningful statistics.” This novel and inventive concept, employing the least common denominator model, facilitates monitoring and planning operation based on analysis and statistics as well as facilitating the use of or creating of meaningful metrics and statistics, such as for example, performance metrics.
A novel and inventive corporate platform is provided which is configured to provision the universal dashboard and to perform the analysis and generate the statistics.
Two different type of work flow scenarios are described in detail to illustrate the novel and inventive concepts using screen shots of actual implementation.
Lastly, an example machine overview in the form of a computer system is described in detail.
An overview in summary, bulleted form of embodiments discussed herein is provided herein below. Under each concept, relevant issues, e.g. regarding the status quo of existing operations and yard management systems and environments, are listed. Following the list of items that are considered to be currently status quo are a list of exemplary features and embodiments described herein that address and otherwise improve upon the status quo.
It should be appreciated that such list is illustrative and is not exhaustive and that persons of ordinary skill in the art will understand that embodiments in accordance with this invention may be practiced without such specific details.
Execution corresponds to day-to-day activities for Managing Trailers and Shipments across the Supply Chain
Monitoring is collective set of activates the progress of Trailer and Shipments in real time with Dashboards, Alerts, and Notifications, observing metrics and KPIs and taking action as appropriate. Access to meaningful statistics is essential for success. Essentially monitoring forms a layer of abstraction on the details of execution details to allow appropriate users to control proper operation.
Analysis looks at past performance with reports and dashboards, looks at metrics and KPls, planes process changes and resets KPI targets for optimization for Shipment/Trailer Visit Management. Access to meaningful statistics is essential for success.
For purposes of understanding embodiments herein, the following terminology may be defined as follows.
Typically, there are different data models for shipments across corporations. For purposes of understanding herein, a trailer visit is a journey from gate to gate and a shipment is a journey from one yard to another yard. Thus, people who manage the trailers are considered to be inside the yard, sometimes referred to as the “four fences,” whereas people who manage the shipments may be at headquarters.
Typically, there are degrees of redundant trailer and shipment data entry and management both in a given location and across a network. It should be appreciated that one cause of such different data entry and management are a result from having different types of customers. Typically, a user enters the data, ships the shipment to destination at which such data is entered in a destination system.
Thus, to address this issue, the system provides a least common denominator data model for shipments such that the shipping entities, the destination entities, the carrier, and headquarters can all know what is progress on a particular shipment. Importantly, in an embodiment, shipping data or shipping states map to the trailer states. For example, a person managing the trailer may be looking at the data and ask, “Is this trailer empty or loaded?” He is not thinking about shipments. He is asking, “Is there something in the trailer?” Thus, such person needs to be able to know, for example, “No, this is empty now,” without understanding the shipment. Meanwhile, if the trailer just got unloaded, the corresponding shipment gets closed because it just got accepted. As well, if the trailer starts getting loaded with the next shipment, that shipment needs to start in the system. Thus, with the system, users can just look at their work and, at the same time, the big picture viewpoint gets updated.
As discussed hereinabove, a novel and inventive least common denominator model is provided. To understand the model and, in particular, the schema of the data depicted in the model, a description of basic concepts is provided. Regarding basic concepts, for example, shipment, a typical work flow may include: start with a shipment, select an appropriate trailer, assign the shipment to the trailer, move the trailer to a dock door, load the trailer, have the trailer be picked up, drive the trailer to its destination, unload the trailer at a dock door, and then close the shipment. The trailer visit version of this flow includes but is not limited to the trailer arriving at the source yard, the trailer is emptied, and then such trailer is loaded with the shipment and sent out. The trailer may arrive empty to be loaded and leave loaded. Or, the trailer may arrive loaded and leave empty. As well, there are exception cases. For example, the wrong load arrives or the yard never needed a particular extra empty trailer to send out anything. In general, things are loaded, things are unloaded, and things go wrong.
Such operations may be a matter of perspective in terms of the from-site, the two-site, and the headquarters view of the world. For example, given a trailer, as far as the from-site is concerned, there is a load that is outbound, i.e. it is going out. The from-site recognizes it has a trailer that is empty and assigns a shipment to it. This to-site has the viewpoint that, “a shipment is going to come into me. It's empty in the source facility.” As far as the individual at headquarters is concerned, the shipment is in an empty, unassigned state and knows what trailer the shipment is being placed. Nothing else has started.
Another approach to viewing the above-mentioned activity is the following progression, in accordance with an embodiment. The trailer is outbound loading, outbound loaded, pending departure, and at the checkout. Then, it's en route. it's checking in, recent departure. It should be appreciated that once it's en route, the individual at the from-site knows the trailer or shipment has left; it's going. As far as the individual at the to-site is concerned, the trailer or shipment is coming in. Once it checks in at the to-site, individual at headquarters may say, “Hey, the thing I shipped is actually at the destination.” Such information may be important to headquarters or the individual at the from-site because such person may be getting that trailer back eventually.
In an embodiment, a carrier perspective is addressed. For example, by using one or more embodiments herein, a dispatcher at the carrier headquarters may see the trailer begin loading and ensures that the driver arrives at the site on time or, alternatively, accelerates or delays the driver arrival time at the site as appropriate. The driver may be able to make these adjustments on the ground in real time. The site and the driver coordinate to ensure a most expeditious processing of the driver inside the facility. Once the trailer is picked up, as the driver is driving to the destination, the driver may provide arrival time updates. The destination site itself may participate in the collaboration, may instruct the driver to arrive earlier or later. At the same time they make the preparations to process the driver most expeditiously.
Thus, embodiments herein enable two or more sets of operators inside the facility and at headquarters to communicate in the same language. A least common denominator model (“system”) is provided that enables such operators to perform their roles, their jobs, via one system and one record of the data that are updated in a way that is consistent with each role. That is, embodiments herein determine, model, and use the least common denominator informational data on which everyone agrees. As well, embodiments build in flexibility such that other role players or even the same role players may extend the system by customizing particular aspects to their benefit while maintaining the shared model.
Embodiments of the invention to enable shipment visibility across a shipping network and the different perspectives of different roles thereof may be understood with reference to
These are the state trajectories from the driver or tractor perspective during the driver or tractor visit.
Embodiments herein provide common visibility across the supply chain using the least common denominator model, which enables accurate and real time assessment of a shipment from one facility to another as viewed by each facility and headquarters, as follows. As an example, consider a shipment that needs to go from the source facility to the destination. Somebody who is in charge of shipments has to assign that shipment to a trailer. Somebody at the destination views, via the system, that there is progress; shipment is assigned to a trailer. The trailer then is ready to be moved to the dock so that it can be loaded.
In an embodiment, a user may create a move. The user may view a pending move. That is, the user may be the person at the dock door who's going to load the trailer. As well, a person inside the yard truck may view the move. A yard truck is a small truck inside the yard that moves trailers back and forth, very much like a regular truck, but smaller. There may be a person inside the yard truck who needs to execute the move. Thus, via the system, he accepts the move. Subsequently, he completes the move. At that point, in the example, the system shows a trailer that's outbound empty and that needs to leave.
In an embodiment, it is possible to continue operating on such trailer via the system. The system may show that the trailer has started loading and then that it is outbound loaded. It finished loading. A next move may be created. Such move may reflect that the trailer is parked back in the yard and that it is ready to leave. In the embodiment, users of the system at the other end, e.g. destination, are able to view the progress. As well, via the system, users may view that the load is ready to be picked up, the driver arrives with another empty trailer, and the driver is going to drop the empty trailer and pick up this loaded trailer.
Continuing with the example of the embodiment, the carrier picks up the trailer at the gate and leaves. At the destination facility, the users of the system are enables to view such progress. Then there is a check-in when the trailer arrives. Enabled by the system, the source facility now knows that the shipment is at destination. The operators at the destination empty the trailer. And, the shipment is closed.
It should be appreciated that in accordance with embodiments herein the trailer and trailer status inside the facility and the shipment and shipment status have been effectively modeled in such a way that all players understand the model. Thus, even though, for the trailer, people may employ a particular local lingo, the system enables a universal way of approaching communication of a shipment.
Further, in an embodiment, an individual site may employ a much more complex and extended model for the state of the shipment or the trailer. Such local details may be extracted by mapping appropriately the local states to the least common denominator model.
There are multiple prevailing definitions of the word shipment in the industry today. Sometimes it refers to the goods in the trailer as it is driven from one site to another, sometimes it is a load tendered to a carrier that consists of multiple stops, and sometimes there may be multiple shipments in the trailer.
In practice shipments may often consist of multiple legs. For example, a particular shipment may consist of multiple legs where shipment starts with an empty trailer at a first facility, where items may or may not be loaded onto the trailer, e.g. the facility may be only supplying an empty trailer. Then, over a sequence of facilities, each facility may or may not unload or load items onto the trailer until the trailer arrives at a last facility, where the shipment ends. The last facility may be where the trailer is completely emptied or may be to where the empty trailer is ultimately delivered.
For purposes of understanding herein, a shipment (more precisely a shipment leg) may be limited to a trip between two sites, the source site and the destination site with a given load. As such it is independent of the initial origin and the ultimate destination of the load or shipment route. In a given leg, the source may have added to the load, and the destination may have subtracted from the load.
It should be appreciated that for purposes of understanding herein, a single shipment may consist of multiple bills of lading that correspond to multiple purchase orders.
For brevity, the remainder of the discussion herein may be on shipment legs (referred to as shipments for brevity) and correspond to a trailer load (in the industry referred to as TL) with the understanding that shipment routes may be constructed from shipment legs and that, at each leg, multiple bills of lading or purchase orders (in the industry referred to as LTL) may be processed.
An embodiment provides customization of the system per each location or site. That is, in an embodiment, the least common denominator model may not capture data about every aspect that may be important to a user. For example, a particular site that manages refrigerated trailers needs to be able to say, “Look, there are refrigerated trailers, and there are dry trailers. And my refrigerated trailer has three compartments, and I load my refrigerated trailer across three different dock doors in my facility, because there is the extremely cold, there is the cold, and there is the zero degree Celsius stuff. I will pick them up from different parts of my warehouse.” Another user at another site with refrigerated trailers may not have that; for example he may ship out everything at minus-4 degrees Celsius. Such person may just park such trailer at the dock door and load it.
It may well be that the source facility consists of a very large warehouse, where goods that must be shipped at different temperatures are loaded across different dock doors. In this case, the loading sequence and related process flows through operations may be modeled to track progress across multiple loads. The loading sequence across doors may be strict or one may load the trailer at an arbitrary sequence. In an embodiment, at the destination facility, tracking such detail may be unnecessary, when using the least common denominator model, the destination facility knows that the loading has started and that there is an estimated time of departure, and hence an estimated time of arrival, for the trailer. Conversely once such trailer arrives at the destination facility, the facility may have a smaller warehouse, which may unload the trailer at one single dock door and distribute the goods appropriately in the warehouse. Again, to the source the relevant piece of information is the acceptance of the delivery of the shipment, not the detailed sequence of the unloading of the trailer, which is addressed by embodiments herein. Across the network, the receiver of such shipments may not care about such level of detail, while that level of detail, i.e. in the way the trailer is handled, may be important at the yard. The person at the yard may need to move such trailer from dock door to dock door. Thus, an embodiment extends the trailer data model. That is, from the system point of view, the trailer entity has a more detailed state space than the shipment entity.
In an embodiment, the following guidelines are incorporated into the data model:
An embodiment can be understood with reference to
One model in accordance with an embodiment differentiates between the actual Trailer and its Visit to a facility. A trailer has a lifespan of years whereas a trailer visit has a much shorter life span, e.g. hours for a live load, days for a drop load, longer if the trailer is used for storage in the facility.
While the static characteristics of a trailer play a role in its use during a Trailer Visit, typically they do not change during the Trailer Visit. As such the model uses different elements to describe the state and state trajectory of a Trailer Visit.
In an embodiment, the trailer visit data model may include but is not limited to the following characteristics or attributes:
It should be appreciated that in an embodiment some of the above-cited characteristics or attributes may be required by all sites, e.g. some system, static, or core attributes, or that others may not be utilized by all sites.
It should be appreciated that in an embodiment the system is configurable to add trailer state attributes at and for any particular site. The system enables a user to manage an entire evolution of the trailer and count the amount of time spent in each state.
In an embodiment, trailer visit state core attributes may include but are not limited to the following:
In an embodiment, trailer visit state system managed elements may include but are not limited to the following:
As with the Trailer, Drivers and Tractors also have static, system, core, predefined, and custom attributes. As with Trailers, the static characteristics of a Driver or Tractor are unlikely to change during a Driver Visit or Tractor Visit. Similarly the state of a Driver Visit and Tractor Visit and their relationship to Trailer and Shipment are modelled with different elements.
In one embodiment the Driver static attributes are given by:
In one embodiment the Driver system managed state attributes are:
In one embodiment the Driver relationship attributes are:
Also, as depicted above in
In one embodiment the Tractor static attributes are given by:
In one embodiment the Driver system managed state attributes are:
In one embodiment the Driver relationship attributes are:
In an embodiment, shipment data model identifier information may include but are not limited to the following data:
In an embodiment, shipment data model relations may include but are not limited to the following data:
In an embodiment, shipment data model system functions may include but are not limited to the following:
In an embodiment, shipment data model planning attributes may include but are not limited to the following:
In an embodiment, characteristics or attributes for shipment statuses for full trailer loads may include but are not limited to the following:
For example, via the system, a user can perform the following operations, i.e. typically physical actions on the trailer and shipment, which result in the trailer and shipment state trajectory to evolve in synch, as depicted in
Thus, the system is configured to enable such user to manage the time, e.g. measuring and shortening the time for greater efficiency. For example, the person at the dock may be waiting. The trailer is in movement and so forth. Thus, the user may want to know all of this timing.
In an embodiment, some characteristics of a shipment may be primarily related to a particular stop of the shipment, or the en-route portion. That is, such characteristics may apply as the shipment is being driven from source to destination. As well, other characteristics may apply to an end or a stop of a particular leg.
In an embodiment, shipment leg characteristics may include but are not limited to the following characteristics:
In an embodiment, shipment stop characteristics may include but are not limited to the following. It should be appreciated that each type below has an inbound and outbound value.
At the source stop
At the destination stop:
One skilled in the art may readily recognize that some of the planning and system attributes are shipment stop attributes, e.g. planned or estimated arrival time, inbound appointment time, etc.
As discussed above the least common denominator model can easily be extended to track additional information necessary in local operations. In an embodiment, the below conditions are incorporated into the system:
It should also be noted that, in an embodiment, additional Trailer Attributes can actually be copied into the Shipment at the from-site during check-out for it to make it available to the to-site at check-in. While from a least common denominator data model perspective this data may not be shared globally, however, this allows sites to share data selectively.
An embodiment of mapping trailer state to shipment state can be understood with reference to
It should be appreciated that while the discussion of the mapping of trailer states to shipment states concerns an implementation of such mapping in a spreadsheet, the spreadsheet paradigm is by way of example and is not meant to be limiting. One skilled in the art would readily recognize that embodiments may include and indeed implement the mapping using technologies other than a spreadsheet. For example, such mappings can be stored in volatile or non-volatile memories in the form of tables, etc. Thus, discussions herein using “spreadsheets” are meant for purposes of understanding only and are not meant to be limiting.
The first column is Movement Type, the entries of which include but are not limited to: inbound, outbound, pickup, storage, maintenance, and relay. The second column is Load Status, the entries of which include but are not limited to: loaded, loading, empty, and unloading. The third column is Handling Method, the entries of which include but are not limited to: live and drop. The fourth column is InboundUse, the entries of which include but are not limited to: Trailer Loads (TL,) NoShipment, and Relay. The fifth column is OutboundUse, the entries of which include but are not limited to: available, TL, DoNotReuse, and Relay. The sixth column is Valid, the entries of which include but are not limited to: Yes, No, and blank. The seventh column is Inbound Shipment State (ISS), the entries of which include but are not limited to: I-loaded, NA, I-Exception, empty, I-unloading, closed, and blank. The eighth column is Outbound Shipment State (OSS), the entries of which include but are not limited to: NA, Assigned, O-loaded, O-loading, O-exception, and O-pickup. The ninth column states whether this is a valid Checkin State (Valid CIS), which describes whether a trailer can be checked in in this state, the entries of which include but are not limited to: Yes and No; acceptable errors may be modeled over time. The tenth column indicate whether a trailer in the given state can be checked out Checkout State (Valid COS), the entries of which include but are not limited to: Yes and No; various error scenarios may be introduced over time.
In an embodiment, to configure the system, a user may go through each of or some of the rows and columns combinations in a given spreadsheet such as the spreadsheet described above and decide whether each row and column combination is valid. For example, regarding an inbound shipment and the inbound shipment states mapped thereto, a user may determine that he is not even allowed to have an inbound state without an inbound shipment. Because if the state is inbound loaded without a shipment, it may not make any sense. Thus, such may not be a valid state. That is, if it is an inbound loaded state, then the user needs such state to have a trailer and it probably would be loaded. Thus, in an embodiment, the spreadsheet is completed with consideration for the needs of a particular business.
This mapping also lays the foundation of normal (positive path) operations vs. modeled and unmodelled exceptions.
An embodiment provides a way for a map, e.g. spreadsheet, to have meaning from one location to another. In an embodiment, each player at each facility has access to the spreadsheet. Examples of players may be the shipper, the truck driver, and the person at the destination. None of the players share the trailer visit data directly. The trailer visit data are not visible, more importantly they not modifiable across the network. However, the shipment data is visible across the network. There is one shipment and there is knowledge of where is the shipment. For example, if the shipment is in a particular yard (source stop or destination stop), then that facility is operating on the shipment and the corresponding shipment stop attributes. The others players cannot act on such data. If the shipment is en route, the driver may act on the data. And, if the shipment is at the destination, the destination can act on the data. That is, there is a clear ownership of who can change what data on the shipment and when based on Shipment state and location. Because as a player operates on the trailer visit data, if the shipment state is a function of the trailer state, wherever is the trailer, is the only place where the trailer visit data can change. Thus, whoever has access to the trailer, physical trailer, is the one enabled to make trailer state changes from one place to another and who then as a result is changing the shipment data.
In an embodiment, not every interested party, e.g. driver, user at source, user at destination, user at headquarters, etc., is required to get the same spreadsheet. For example, interested parties may use totally different trailer attributes and trailer attribute values. However, it has been found to be beneficial in an embodiment for interested parties to have the same set of values for inbound and outbound shipment states. For example, in an embodiment, interested parties use the same movement type; use the same load status, handling method. Such users use a set of core trailer attributes, i.e. the same spreadsheet. However, in an embodiment, users may customize by basing their customization on such spreadsheet. Such users may add other trailer attributes and therein have their own mapping of trailers states to shipment state.
In an embodiment, headquarters does not have a spreadsheet. Because headquarters typically requires to view the shipment, which may be the least common denominator, plus other information that may be relevant.
In an embodiment, the spreadsheet is local. The facility owns it. Thus, at a particular facility, the users own their particular spreadsheet that does the mapping in accordance with the least common denominator and with the particular trailer states.
In an embodiment, there are four players: the source facility, the destination facility, the headquarters, and the trucker. And each of those has a dataset that is personal to them by which they keep track of the shipment. Each of them has a different set of data, because different data is pertinent to them. They do not need the information the other players need necessarily, and vice versa. Thus, they each have their own subset of the total dataset, however they all have something in common, which is the data from the least common denominator model.
In an embodiment, local trailer attributes are not available outside the local environment. In another embodiment local trailer attributes can be shared with other parties without meaningful, guaranteed semantics such as name value pairs.
In yet another embodiment, the trailer may stay at such dock door and be loaded with an outbound shipment. Once the new move is created, it is up to the yard truck driver to move the trailer back to the yard. Until such move is completed, the unloading of a subsequent shipment cannot be started.
It should be appreciated that given a mapping from trailer states to shipment states, in an embodiment, not every state, combination of states, or mapping of states may be valid, for example, from an operational point of view.
While one may have standard operating processes for a positive path operation, there are some exceptions that occur frequently that one has to include them in “typical system behavior.” For example, a person at the yard may have unloaded a shipment to realize that such shipment wasn't supposed to be for that person. For instance, it may have been meant to go across the street. However, the person had opened the shipment and started unloading it and then realized the error. Thus, in this example, the person closes the shipment, puts everything back in, and then sends the shipment back.
In an embodiment, the system is configured to model exceptions, for example, that occur with a predetermined acceptance of frequency. In an embodiment, the system is configured to provide rules for handling the modeled exceptions.
As mentioned above, it should be appreciated that given a mapping from trailer states to shipment states, in an embodiment, not every state, combination of states, or mapping of states, or state transitions may be valid, for example, from an operational point of view. An embodiment can be understood by the same example described in the section above, Modeled Exceptions.
It should be appreciated that sometimes there are exceptions that occur, however they are not modeled. Given the limited frequency and limited impact of some exceptions, for sake of simplicity, it is more beneficial to lump some exceptions that occur into one “unknown exception” and then delegate its resolution to entities outside the model. For example, a particular exception may not occur frequently enough to warrant modeling. For example, modeling such exception may incur costs that are not justified given a cost benefit analysis, such as incurring an expensive programming cost plus roll-out to production costs, or even training cost at all employee levels. In an embodiment, the system is configured to handle exceptions that are not modeled exceptions. For example, the system is configured to provide a notification, which may cause a person to obtain assistance, such as calling a supervisor who calls IT tech support, who then corrects the problem. In an embodiment, the system is configured to provide rules and guidance for handling the unmodeled exceptions but delegate to the “qualified” users to resolve the exception.
In an embodiment, a user may, as unmodeled exceptions happen, go back to the system and modify the system such as to prevent such unmodeled exceptions from happening. Or, the user may determine that if the unmodeled exception is going to keep happening, to make it into a modeled exception. In essence, embodiments herein provide users with the ability also to evolve and improve their business over time.
As the context of discussion is monitoring an analysis, it should be appreciated that an ultimate goal is to prevent exceptions from happening. As a user is able to reduce the frequency of some main “modelled” exceptions the user can over time focus on less frequent exceptions, model them, and then focus on preventing them.
In an embodiment, the system is configured to provide, but is not limited to provide the following functional categories:
It should be appreciated that in an embodiment, planning is part of each functional category. One skilled in the art may readily recognize that the categories may be viewed, respectively, as operational (execution), tactical (monitoring), and strategic (analysis) planning.
In an embodiment, users of the system may include but are not limited to gate personnel, yard truck drivers, traffic managers, dock operators, transportation managers including those at headquarters, shift supervisors, general managers (GM) and so forth.
Table A illustrates site users of the system, their execution functions, what they monitor, and relevant analysis informational data, according to an embodiment.
Table B illustrates particular headquarters site users of the system, their execution functions, what they monitor, and relevant analysis informational data, according to an embodiment.
Table C illustrates other users of the system, who are from the site's perspective guest users, their execution functions, what they monitor, and what relevant analysis informational data they look at, according to an embodiment. A guest user may be a user that works for another corporation or is a private fleet driver.
Table D provides a perspective of operational execution functions, according to an embodiment and illustrates local and central focus area.
Table E illustrates operational monitoring functions, according to an embodiment.
A preferred embodiment can be understood by the following example of operational site users and their tasks for unloading a trailer with minimum intervention due to the network aspect of the system. Such example is for illustrative purposes and is not meant to be limiting.
The sequence of Figures
Before we get into implementation details of a possible embodiment we discuss some additional constructs that increase the value of the invention.
An embodiment can be understood with reference to
These are customizable Operations that can be used to build workflows based on data model elements. They shield individual users from the details of the data model and bring the assembly line approach to the workflow execution.
Users may be interested in implementing a sequence of planned moves also referred to herein as a journey. In one embodiment, a journey is a sequence of moves each created only when certain conditions are satisfied, such as for example but not limited to:
An example of such journey is: DockDoor12 Round-Trip Unload, wherein such journey:
In an embodiment, a journey may be authorized only on trailers that match a filter.
Both for Monitoring and Analysis one needs to leverage metrics and Key Performance Indicators (KPI)s to oversee execution. In monitoring, one focuses on current performance to intervene, while in analysis one looks at past performance, to make process changes and to change metric and KPI targets.
Metrics may be expressed a single numbers or as a sequence (vector) of numbers. Examples of number metrics are:
Examples of vector metrics are
A metric or KPI can be used to express a performance value, or one can also work with a “target” and show performance against a target.
One can also look at the time history of a metric and KPI.
Reports may be used to generate multidimensional data. They can be used to look at current information or to look at past performance.
As mentioned hereinabove, two different types of work flow scenarios are described in detail using screen shots of an actual implementation. Embodiments may be understood with reference to the following sets of figures, depicting particular work flows.
In the work flow scenarios screen shots, Source tabs and Destination tabs are provided. Source tabs include but are not limited to “Gate View,” “Yard Truck,” “Dock View,” and “Ship View.” The middle tab is “HQ View” for Headquarters View. The Destination tabs include but are not limited to the same tabs as the Source tabs, but the displays represent data from the Destination point of view, whereas the Source tabs represent data from the Source point of view.
It should be appreciated that in an embodiment, arrival event updates are sent to Transportation Management System (TMS). In this case for illustrative purposes, the TMS from Oracle Corp, referred to as OTM, is used. Any delays trigger one or more alerts. As well, because carriers also have access to the real time shipment status, they can better arrange just-in-time arrival, reducing loaded trailer idle time in the yard.
Embodiments herein enable faster Check-in/Check-out of the carrier driver, which saves significant driver idle time.
It further should be appreciated that in accordance with embodiments herein, the carrier driver may pick up a different trailer at the Destination site and depart. At this point the carrier may have completed its responsibilities for the shipment. Significantly, getting the carrier driver in and out faster saves transportation cost. Planning for the arrival of the trailer, reduces the idle time of the loaded trailer in the yard.
It should be appreciated that in an embodiment, carrier arrival/departure times are reported to the OTM. An embodiment provides delay alerting. In both Drop/Live scenarios the order fulfillment cycle is short.
As mentioned hereinabove, the least common denominator model may be used in the provisioning of universal dashboards for shipment and trailer management based on such data. In this way, the universal dashboard enables different types of end users to share and communicate regarding common types of data and terminology.
In an embodiment, alerts and notifications are provided. For example, if there are situations that occur in the yard, then the system provides a set of site alerts. Regarding particular assets, notifications are provided. As well, configurable business rules are provided that may be referred to as watches. An embodiment includes but is not limited to the following:
An embodiment of the dashboard can be understood with reference to
It should be appreciated that sequence 11B-11D is an example of a very structured kpi/metric that has been defined and that has acceptable value thresholds and an attached process of handling the situation when the site is outside the acceptable thresholds.
Management, according to an embodiment. Specifically, data displayed are By Site and By SCAC contractual pool sizes that are not in compliance. Any carrier that is below contractual threshold is highlighted for immediate action.
Sequence 11E-11H is an example of a situation where a user may not have a very well defined metric/KPI for a condition. However, an experienced user may be looking at the situation more broadly to identify a condition that is problematic, even when there may be no particular rule that identifies it as such. The intent of such sequence example is that over time such type of exercise using embodiments herein may result in additional structured KPIs.
See
As mentioned above, the least common denominator data model combined with the vast and varied data stored at the corporate level and at the local level allow for the computing of meaningful, optimized statistics regarding trailers and shipments. An embodiment is provided that uses such vast amount of collected or stored data to provide the basis for a plethora of reports. One embodiment enables number metrics to be planned, projected, determined, etc., based on analyses of such data. As well, KPIs may be determined from analyses of the data or may be used to drive the business, such as for example in setting target metrics.
An embodiment enables analyzing elements and events for the purposes of understanding performance. For example, events may be placed into categories or buckets to help organize and determine solutions to particular areas. For example, placing events in particular categories may be used to answer the following questions: “If everything goes well, what happens? What are the exceptions that I'm having? What can I do to reduce them? What are the unmodeled exceptions? Are these happening frequently enough so that I need to model it, because they are a cost of doing business? Or, if something that I modeled never occurs, then maybe I should get rid of it and treat this as an unmodeled exception.”
The system may be configured to enable a user to detect inefficiencies, such as for example, determine how long a trailer, on average, sits in the yard waiting to be picked up. The user may not want to keep a trailer which broke down, had a flat tire, could not move, and had a missing part such that it sat in the yard for four days. Thus, the system provides a utility to such user by enabling him to determine by performing analytics and viewing related data that he does not want to keep such trailer.
In an embodiment, performance metrics are derived based on positive paths, as well as handled exceptions. For example, using statistical analysis, exceptions may be determined based on the number of standard deviations away from the norm the exception may occur. An exception may be deemed an outlier or may illuminate an area which needs improvement. Thus, the provided data model in accordance with embodiments herein enable, result in, and cause improved performance analysis.
In an embodiment, the system is configured not to mix data among the three categories: positive path, modeled exceptions and unmodeled exception. Such mixing may result in meaningless average numbers. For example, when a user is monitoring the data, the user may want to know if an operation is an unmodeled exception; for example, if the user needs to get involved. If an operation is a modeled exception, then the user may want to continue to monitor such type of operation. For an example implementation, the modeled exception may cause a yellow alert, as opposed to a red alert, and the workers may be able to handle the exception.
One embodiment is configured to provide the reports, number metrics, and KPls, as described hereinbelow. It should be appreciated that the particular details are illustrative and are not meant to be limiting.
It should be appreciated that
Similar to Monitoring, Analysis can be performed at site level or at Corporate Level. It should be appreciated that some of the previous examples under Monitoring were to manage exceptions in Real Time. Here we provide an example of using past data to identify trouble spots.
It should be appreciated that
As discussed hereinabove, the least common denominator model enables the provision of a platform, which, in turn, enables the provision of a universal dashboard as well as the generation of meaningful analysis and statistics. One embodiment can be understood with reference to
An embodiment contemplates or provides global back end capabilities including but not limited to:
In an embodiment, a corporate portal may provide but is not limited to provide the following capabilities:
In an embodiment, the system is configured to:
The computer system 1500 includes a processor 1502, a main memory 1504 and a static memory 1506, which communicate with each other via a bus 1508. The computer system 1500 may further include a display unit 1510, for example, a liquid crystal display (LCD) or a cathode ray tube (CRT). The computer system 1500 also includes an alphanumeric input device 1512, for example, a keyboard; a cursor control device 1514, for example, a mouse; a disk drive unit 1516, a signal generation device 1518, for example, a speaker, and a network interface device 1528.
The disk drive unit 1516 includes a machine-readable medium 1524 on which is stored a set of executable instructions, i.e. software, 1526 embodying any one, or all, of the methodologies described herein below. The software 1526 is also shown to reside, completely or at least partially, within the main memory 1504 and/or within the processor 1502. The software 1526 may further be transmitted or received over a network 1530 by means of a network interface device 1528.
In contrast to the system 1500 discussed above, a different embodiment uses logic circuitry instead of computer-executed instructions to implement processing entities. Depending upon the particular requirements of the application in the areas of speed, expense, tooling costs, and the like, this logic may be implemented by constructing an application-specific integrated circuit (ASIC) having thousands of tiny integrated transistors. Such an ASIC may be implemented with CMOS (complementary metal oxide semiconductor), TTL (transistor-transistor logic), VLSI (very large systems integration), or another suitable construction. Other alternatives include a digital signal processing chip (DSP), discrete circuitry (such as resistors, capacitors, diodes, inductors, and transistors), field programmable gate array (FPGA), programmable logic array (PLA), programmable logic device (PLD), and the like.
It is to be understood that embodiments may be used as or to support software programs or software modules executed upon some form of processing core (such as the CPU of a computer) or otherwise implemented or realized upon or within a system or computer readable medium. A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine, e.g. a computer. For example, a machine readable medium includes read-only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals, for example, carrier waves, infrared signals, digital signals, etc.; or any other type of media suitable for storing or transmitting information.
Further, it is to be understood that embodiments may include performing operations and using storage with cloud computing. For the purposes of discussion herein, cloud computing may mean executing algorithms on any network that is accessible by internet-enabled or network-enabled devices, servers, or clients and that do not require complex hardware configurations, e.g. requiring cables and complex software configurations, e.g. requiring a consultant to install. For example, embodiments may provide one or more cloud computing solutions that enable users, e.g. users on the go, to manage shipment on such internet-enabled or other network-enabled devices, servers, or clients. It further should be appreciated that one or more cloud computing embodiments include managing shipment using mobile devices, tablets, and the like, as such devices become standard consumer devices.
Although the invention is described herein with reference to the preferred embodiment, one skilled in the art will readily appreciate that other applications may be substituted for those set forth herein without departing from the spirit and scope of the present invention. Accordingly, the invention should only be limited by the Claims included below.
This application is a divisional of U.S. patent application Ser. No. 14/452,274, filed Aug. 5, 2014, which claims the benefit of U.S. Patent Application Ser. No. 61/862,902, filed Aug. 6, 2013, which applications are incorporated by reference herein in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| 61862902 | Aug 2013 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 14452274 | Aug 2014 | US |
| Child | 15672563 | US |
