Example of Fedex Intl shipping

From: blstuart_at_bellsouth.net <(blstuart_at_bellsouth.net)>
Date: Fri Jul 27 21:42:25 2001

Normally I don't chime in with regard to my employer but I may be able
to add a little perspective and wouldn't be a good list member if
I withheld my knowledge. Of course, I have to make the standard
disclaimers. I don't speak for the company. Being on this list
you probably correctly guess that I'm in development and not in
operations, so my perspective won't be as good as Fred Smith's
(the founder).

In message <20010727211839.62263.qmail_at_web9501.mail.yahoo.com>, Ethan Dicks wri
tes:
>
>--- Russ Blakeman <rhblake_at_bigfoot.com> wrote:
>> So if a package is shipped from NYC to Boston it has to go to Memphic first?

In the beginning of the company, that's exactly what would happen. The
most important thing here is that it only go through one hub so that
we only have to spend time handling it once (at the hub level). Now
if a single facility can handle all your volume, then you get some
real economies of scale routing it all through there.

>But you get savings at not trying to put two-way routing intellegence at
>each major nexus. At Cleveland, let's say, all stuff that comes in, goes out
>on the planes to Memphis early every evening, and stuff to get routed within
>the Cleveland area arrives later in the evening. No sorting is required at
>Cleveland to figure out if it goes to Memphis or not. If you multiply this
>by hundreds of metro areas, the savings is clear. Now... it's possible to
>insert a minimal level of sorting so you don't ship a package from one
>Cleveland address to another via Memphis, but if it goes from one metro area
>to another, routing to a hub is more efficient, even if you pass your
>destination on the way to the hub. There is a plane from NYC to Memphis
>and back every night; there is a plane from, Boston to Memphis and back
>every night; why add a plane from NYC to Boston? You already have four
>legs that have to be there anyway that will get the package there. It
>only would become an issue if you could fill a plane, night after night
>from one place to another that you'd even want to think about bypassing
>the hub.

This is a very good description. I'd add that the saving of
the time of sorting is more of a motivating factor than saving on
putting in the intelligence. In fact, we're always looking for
ways of applying the information we have about the packages in order
to make more intelligent routing decisions. Some of the projects
I work on feed into such decision making.

>I think these days, the original concept has been extended to allow for
>multiple hubs, permitting a much smaller route optimization than solving
>for m x n, but the concept is still valid.

We have indeed added a number of additional hubs. It turns out that
the necessity that bred this invention was the pragmatism of growth.
We simply outgrew the original Memphis hub and ran out of space to
expand it. So now say you send a package from Boston. The package
will most likely go to a station in the Boston area and be sorted
during a window from 6:30 to 9:00 (eastern). Depending on the
destination, it is placed into one of several airplane containers
which are then trucked to the airport. Those containers are then
loaded onto planes headed for the various hubs. The strict sort
time is required because (for example) planes must arrive at the
Memphis hub by midnight. Now imagine the dance of hundreds of
planes all landing during a 2 hour period, several hundred thousand
packages removed from the planes, sorted, loaded back onto the
planes and then the planes all going out again about 2 hours later.
When the packages arrive at the destination airport, they are trucked
from the planes to the destination stations where they are unloaded
and sorted onto courier trucks for delivery commitments of 8, 10:30
and 4:30. Then we wait until the next batch of packages comes along.
To a first approximation, we go out of business every day at 10:30
at are back in business about when most businesses are closing for
the day. This is pretty much the same regardless of where the
destination city lies. Sure these days something going from Boston
to New York is more likely to go through our Newark hub than our
Memphis one. And yes, we do save some money that way, but milage
isn't as big a factor in cost as you might think and that savings
gets balanced against the cost of operating another hub facility.

> Economically, people will pay
>more for "absolutely, positively has to be there overnight". The optimization
>here is for time first, cost second. If the customer could wait, they
>could choose a lower-priority delivery technique. The Post Office and UPS
>optimize for cost first, delivery-time second. Different models.

That was a lot of the motivation for our purchase of RPS which is
now FedEx Ground (the one with the green logo). They have an
excellent cost model and provide as much service as they can within
that.

>Given that FedEx also offers lower priority delivery, they probably aren't
>filling each and every plane, each and every night with stuff. If they
>were, there wouldn't be room to stuff the lower priority items in the corners.

We certainly wish we could fill all the planes every night. You can
all help with that by shipping everything by FedEx :-)

One message also mentioned the company's compensation structure.
I certainly can't speak to that of the pilots and couriers that were
mentioned. It's true that FedEx doesn't pay developers as much as
you would likely get in Silicon Valley or probably even the Research
Triangle in North Carolina. But the company recognizes this and
has been working to improve the situation. The company also has
a strong history of treating its people well. I was quite ill
about a year and a half ago. They told me to take whatever time
was necessary and were very supportive during the whole thing.
My director even told me of an employee that they had flown
overseas for experimental treatments a few years earlier.

Brian L. Stuart
Chief Engineer, FedEx Services
Received on Fri Jul 27 2001 - 21:42:25 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:33:54 BST