A question R1a. Recently (or soon), Ground changed their barcode. Could Ground's or HD's system be coopted for a period of time in an emergency situation (courier work stopage) to give Express time to fully implement DRA? Or is DRA basically the same thing and both take months to bring online?
I understand that Express is moving to a 13 digit tracking number sometime in the future. In discussions with an Express "engineer type", this has to do DIRECTLY to enable "interoperability" between the computer systems handling Ground and Express volume. If Express tried to directly "co-opt" the Ground software in the event of a potential Express strike, they'd be shooting themselves in the foot - not on an operational reason, but RLA reason.
If FedEx were to ever be so brazen as to shift ALL volume over and use Ground contractors and equipment, then the "justification" for keeping Express under RLA would be out the window - then FedEx would REALLY be in trouble. They will get away with using Ground as a cartage agent for the delivery of non-overnight Express volume, but trying to assign Ground tracking numbers, then using Ground contractors to move overnight volume would end the RLA charade once and for all. FedEx won't do that.
I've heard talk of what would happen in this case (Express Courier strike), is that Express would look to hire "temps" as delivery drivers (NOT for pickup - reasons given previously), and look to a pool of individuals that are already trained in FedEx procedures and could drive an Express truck with hardly any training.... current Ground helpers...
DRA is VERY similar to Ground's system, but there are key differences - mainly in the need to account for differing commit times of freight which are loaded onto a route.
And yes, you get into an excellent question...
From what I understand, the Ground routing software is strictly what Express would call "paper routing" (start at one point on the route, and move in the most efficient path possible to gain maximum productivity in terms of "driver" on road time in getting volume off that route). Express routes AREN'T run like that currently.
Express routes have a "P1" cycle (generally to 10:30 AM in metro areas), backtracking to perform a non-P1 cycle (generally till 3:00PM), then if the route is heavy, the Courier is responsible for getting off all SOS by 3PM, then backtracking yet again to get non-overnight volume off by 4:30PM. A Courier can potentially drive past the same points THREE times in a day - to get volume off within commit time requirements (vast majority of cases, the Courier only does one "backtrack" to get off non-PO volume).
Currently DRA gets screwed up BAD trying to account for all of this need to backtrack. In most tests, the route is "assigned" without regard to commit time (at this time), and Couriers are responsible to break track with DRA stop order and get priority volume off by the commit time - it is screwing up the reports to engineering something fierce.
I've read some of the accounts on BC of stations wanting to break out P1 volume into separate routes, and have full timers run P2 and pick ups only (let part-timers do P1).... Three guesses as to why this operational plan is being kicked about - primarily by engineering and is leaking down to station level....
The issue is, even with the pulling off the delivery of non-overnight volume from Express in the coming years, there will still need to be a capability to have DRA perform a double route trace (P1 cycle then SOS cycle - all while correctly assigning SOS as potential tagalongs to P1 stops). This is what is "vexing" engineering right now. They need to have the dynamic capability of DRA assign enough P1 to each route to get it "efficient", build a stop ordering of that volume, THEN, allocate non-P1 to the route (presumably covering the same area), and do both an efficent stop ordering of that volume - using the ending point of the last P1 delivery as the START point of the P2 cycle, AND correctly assigning potential tagalongs to the P1 cycle.
Couriers do that everyday as part of their job... the goal is to have the software do all of that "thinking". They will succeed, they just need to get the correct algorithms introduced into the software, run it 30-50 times and correct any errors.
