Estar Day1!

[Cactus]

Very wrong. Star B must be an engineer whose job is at stake because of Estar's consistent failures in its current form. He shills Estar like it's gospel. It needs to be scrapped and overhauled for it to work as intended

They need to do away with it completely.

The key is simplifying not complicating like they’ve been doing for more than 15 years. All that DRA/Response/E-star stuff has failed. Time to go back to the basics.

 

[Fred's Myth]

They need to do away with it completely.

The key is simplifying not complicating like they’ve been doing for more than 15 years. All that DRA/Response/E-star stuff has failed. Time to go back to the basics.

And admit failure? And jeopardize their counterproductive positions?

Never.

 

[Star B]

WRONG!

Please tell me how I'm wrong? I've known of a few stations that have gone pure-static routes ala SRA because of their unique situations.

Very wrong. Star B must be an engineer whose job is at stake because of Estar's consistent failures in its current form. He shills Estar like it's gospel. It needs to be scrapped and overhauled for it to work as intended

No, I'm not an engineer. E* failing only effects me in I have to hear everyone bitch at the station about the routes that it spits out. I'm trying to wake everyone up to the fact that E* isn't just "a piss couriers off software package" -- it's a massive overhaul of the backend systems to bring FXE into the current decade.

To combat both your "WRONG" statements -- static routes ARE an option in E*, but they are used as a last-resort, nothing else worked, we've tried everything we could but this is the only way we can make it work. In other words, to get the approval to make them and use them, the station engineer has to present a very detailed presentation to MEMH for them to turn it on.

If you don't want to listen to me -- that's fine, I'm used to it. However, shill, I'm not. I still believe that E* is a tool created by management to create an amazon-style workforce, get some idiot thru the door, get them trained on the technology, do the bare minimum to try to prevent them from rolling into a school bus full of kids (via those ing cameras), and throw them on the road in a week while paying the bare minimum.

If any old-timer is bitching about this race to the bottom, they had the opportunity to unionize when FXE was smaller, but they believed the companies BS. Now, FXE is in total control because technology allows them to hire literal idiots and get delivered. Back in the day, the CRR was an indispensable tool because they had to learn the area, remember the ins & outs, be able to spatially order their deliveries, be able to think quickly on their feet while being efficient and being able to drive safely.

 

[handlemypackage]

No, I'm not an engineer. E* failing only effects me in I have to hear everyone bitch at the station about the routes that it spits out. I'm trying to wake everyone up to the fact that E* isn't just "a piss couriers off software package" -- it's a massive overhaul of the backend systems to bring FXE into the current decade.

To combat both your "WRONG" statements -- static routes ARE an option in E*, but they are used as a last-resort, nothing else worked, we've tried everything we could but this is the only way we can make it work. In other words, to get the approval to make them and use them, the station engineer has to present a very detailed presentation to MEMH for them to turn it on.

If you don't want to listen to me -- that's fine, I'm used to it. However, shill, I'm not. I still believe that E* is a tool created by management to create an amazon-style workforce, get some idiot thru the door, get them trained on the technology, do the bare minimum to try to prevent them from rolling into a school bus full of kids (via those ing cameras), and throw them on the road in a week while paying the bare minimum.

If any old-timer is bitching about this race to the bottom, they had the opportunity to unionize when FXE was smaller, but they believed the companies BS. Now, FXE is in total control because technology allows them to hire literal idiots and get delivered. Back in the day, the CRR was an indispensable tool because they had to learn the area, remember the ins & outs, be able to spatially order their deliveries, be able to think quickly on their feet while being efficient and being able to drive safely.

In its current form EStar still doesn't work for what it was intended. I'd hope you knew that already. Updated maps with no EStar crap to ruin routes would be the best solution. That would help more than trying to control the ebb and flow of every route in a station. Why can't that be implemented instead of having to use a failing program as a crutch?

 

[Nolimitz]

Our station has been 50/50 DRA/SRA since day 1 of DRA. It never worked on any SRA routes as the area is growing leaps and bounds. Mapping cant keep up. The first couple weeks of E* have been a morning sort disaster, littered with 0's that folks wont even look at the addy much less the city. It all goes to the end of the belt, some gets fixed, the rest sit till the next day including medical and perishable

 

[Cactus]

And admit failure? And jeopardize their counterproductive positions?

Never.

Then the current upper (mis)management needs to go along with their ignorance, stubborness and over inflated egos.

Wouldn’t be hard for the new blood to admit the old blood were clueless.

 

[fatboy33]

Very wrong. Star B must be an engineer whose job is at stake because of Estar's consistent failures in its current form. He shills Estar like it's gospel. It needs to be scrapped and overhauled for it to work as intended

Maybe E star doesn't make sense to us because it isn't meant to. What if It's meant for after express is merged into ground? I was told, in some parts of the country, express drivers have been given the option to join ground or leave on a count all operations are to be housed under one roof. If this isn't BS, expect to know by May 2023 at the latest.

 

[Star B]

Updated maps with no EStar crap to ruin routes would be the best solution.

So, I just want to be clear here before I spend a ton of time typing out a response that may not apply -- you wanted FXE to upgrade the maps in DRA and still run DRA?

Our station has been 50/50 DRA/SRA since day 1 of DRA. It never worked on any SRA routes as the area is growing leaps and bounds. Mapping cant keep up.

DRA was limited to only one set of time commits per station. Basically, if you had 1030, 1200, 1630 P1 zones, DRA wasn't programmed to solve all those routes. You could have a 1030 P1 DRA solution, but anything else had to be run SRA.

The first couple weeks of E* have been a morning sort disaster, littered with 0's that folks wont even look at the addy much less the city. It all goes to the end of the belt, some gets fixed, the rest sit till the next day including medical and perishable

That sounds like a nightmare... let me guess, those 0's are the areas that were old-SRA areas? For contrast, when we flipped the switch, the amount of 0s grew proportionally to the amount of routes it was solving. In simpler terms, if 1% of the DRA pkgs came down as a 0, 1% of the E* packages came down as zeros too. There were more 0s under E*, but it was trying to solve with 100% of the stations packages, versus DRA solving with only ~60%. That's getting better each day with more aliasing rules and ACO/PIO work.

 

[McFeely]

So, I just want to be clear here before I spend a ton of time typing out a response that may not apply -- you wanted FXE to upgrade the maps in DRA and still run DRA?

I'd vote for updated maps (great for newbies, swings, etc.) but keep SRA. Flex within loops as needed. Updated maps help everyone who's not familiar with a route and new subdivisions. The sequence number on packages in DRA and Estar are helpful for truck loading and finding a package in the truck, but otherwise I hate DRA/Estar.

But I understand that the company is going for the time window expectation that E-Star supposedly will give. I also understand that I don't get to vote. I still don't comprehend how Estar can function with Wave 2 deliveries. A third of my station leaves their area after P1 to do the Response sort and shuttle it back out for delivery. We just don't a have separate group of couriers to have unique route numbers to run Response.

 

[handlemypackage]

So, I just want to be clear here before I spend a ton of time typing out a response that may not apply -- you wanted FXE to upgrade the maps in DRA and still run DRA?


DRA was limited to only one set of time commits per station. Basically, if you had 1030, 1200, 1630 P1 zones, DRA wasn't programmed to solve all those routes. You could have a 1030 P1 DRA solution, but anything else had to be run SRA.

The best solution would be having newer maps with no Estar and no DRA to dictate how a route should be knocked out. Neither have shown any ability to adjust for any real world obstacles that drivers run into daily. Estar especially isn't able to keep drivers in a reasonably condensed area. Nobody should have to break off 10 miles to grab another workgroup's regular pickup and then go back another 10 miles to resume deliveries

 

[MAKAVELI]

The best solution would be having newer maps with no Estar and no DRA to dictate how a route should be knocked out. Neither have shown any ability to adjust for any real world obstacles that drivers run into daily. Estar especially isn't able to keep drivers in a reasonably condensed area. Nobody should have to break off 10 miles to grab another workgroup's regular pickup and then go back another 10 miles to resume deliveries

She really doesn't understand that concept. She's under the same impression as management that the solution is a computer program not human problem solving.

 

[Star B]

She really doesn't understand that concept. She's under the same impression as management that the solution is a computer program not human problem solving.

Management has firmly embraced technology and creating routes with sequences. To try and fight back to 100% SRA-style CRR routing isn't going to happen in the long game. Yes, there may be areas that don't see E* for decades, but those will be few and far between and a tiny blip when it comes to cost and revenue. Don't be like the horse buggy and whip manufacturers when the automobile came around. Change is happening whether you like it or not.

Do you know what wildly outdated software platform ROADS ran on? Did you know that the main developer of ROADS is no longer with the company and hasn't been for quite some time? Did you also know that the way ROADS/DRA handles special conditions (such as business closed/opens later) is a hackjob and every map update causes a massive headache with updating existing FedEx generated data, including moving GPS coordinates for manually coded addresses?

That's one of the many reasons to get away from ROADS and onto E*. To get rid of the code rot of an unsupported program (have any of you actually seen DRA assist???) and make it easier to injest and process all sorts of new data, GPS pings from the LEOS/trucks, live & historical traffic data, quarterly map updates (without the massive headache of moving all the grains in ROADs around).

Remember when I've said there's plenty of heads to the hydra that is E*? You're starting to get a deeper look into it.

I still don't comprehend how Estar can function with Wave 2 deliveries. A third of my station leaves their area after P1 to do the Response sort and shuttle it back out for delivery. We just don't a have separate group of couriers to have unique route numbers to run Response.

One of the reasons why they push E* is the ability to finely tune routes. You can define "5 Routes Starting from Downtown Chicago, Leave Station at 0800, 8 hours of delivery, 60 minute break RTB 1500" and then define "Wave 2 Routes starting from DT Chicago, Leave Station 1200, RTB 2000, 7 hours delivery, 60 minute break". There is even more granularity in the route definition (primary/secondary), where the routes will start solving from (the seed points, kinda sorta like loops in DRA), and other things that I can't remember right now.

To ask a question -- IF management had the bodies/trucks, wouldn't Response be a 2nd wave of dedicated CRRs?

I'd vote for updated maps (great for newbies, swings, etc.) but keep SRA. Flex within loops as needed. Updated maps help everyone who's not familiar with a route and new subdivisions. The sequence number on packages in DRA and Estar are helpful for truck loading and finding a package in the truck, but otherwise I hate DRA/Estar.

an experienced CRR will beat a computer generated solution most of the time. I will never contest that. However, Management wants cheap labor... and with cheap labor you have to spoon-feed the complex, difficult decisions to them. I've said time and time again, FXE wants to implement an amazon-style workforce, little to no benefits -- use & abuse and throw away after a few years. Legacy costs, such as 401k, retirement plans, health insurance, etc, gets expensive quick with a veteran workforce.

Now, why don't we just update the old DRA maps? The reason is that it's a royal, ROYAL pain in the ass with how DRA is setup. Remember earlier when I said that having to migrate all the FedEx generated data from the old maps to the new maps? From what I understand and how it's been explained to me -- how special items are setup in DRA is a geofence area around where the grain (address) would plot. If the address plots in that certain defined box/polygon, then those special parameters apply. A map update could change where the address plots by a few hundred feet, which causes the grain to not be in the area and the special parameters would not be applied to the stop... and then the avalanche of extra work starts. Finding out that stop no longer gets the special parameters applied, then it has to get fixed, and not every location gets a package each day, multiply that by the 2000 or so stations FXE has. Not to mention the chance that a map update mixes up special parameters because the two address plots changed and criss-crossed.

E* changes that. Addresses are treated as separate entities (called shares) and the map plot is only used for solving. That way, even if the map plot point changes because of an update, the special parameters is per address and will be retained.

and remember folks, just because I think that E* is a needed upgrade, doesn't mean that I like it. I think it's wildly inefficient to send three CRRs where we used to send just one. I think that it's BS that they can't let a CRR be focused on an area so they can know it like the back of their head, instead opting for swing-like behavior in even more towns and cities that they pass through. However, management wants to cut labor costs and one way is to make the route so brain-dead that anyone who can drive a Sprinter safely can be successful 95% of the time without a massive investment in training and time spent gaining area knowledge.

 

[59 Dano]

However, shill, I'm not.

You interrupted the circle jrek? Then you're a shill. Them's the rules.

 

[MAKAVELI]

Management has firmly embraced technology and creating routes with sequences. To try and fight back to 100% SRA-style CRR routing isn't going to happen in the long game. Yes, there may be areas that don't see E* for decades, but those will be few and far between and a tiny blip when it comes to cost and revenue. Don't be like the horse buggy and whip manufacturers when the automobile came around. Change is happening whether you like it or not.

Do you know what wildly outdated software platform ROADS ran on? Did you know that the main developer of ROADS is no longer with the company and hasn't been for quite some time? Did you also know that the way ROADS/DRA handles special conditions (such as business closed/opens later) is a hackjob and every map update causes a massive headache with updating existing FedEx generated data, including moving GPS coordinates for manually coded addresses?

That's one of the many reasons to get away from ROADS and onto E*. To get rid of the code rot of an unsupported program (have any of you actually seen DRA assist???) and make it easier to injest and process all sorts of new data, GPS pings from the LEOS/trucks, live & historical traffic data, quarterly map updates (without the massive headache of moving all the grains in ROADs around).

Remember when I've said there's plenty of heads to the hydra that is E*? You're starting to get a deeper look into it.


One of the reasons why they push E* is the ability to finely tune routes. You can define "5 Routes Starting from Downtown Chicago, Leave Station at 0800, 8 hours of delivery, 60 minute break RTB 1500" and then define "Wave 2 Routes starting from DT Chicago, Leave Station 1200, RTB 2000, 7 hours delivery, 60 minute break". There is even more granularity in the route definition (primary/secondary), where the routes will start solving from (the seed points, kinda sorta like loops in DRA), and other things that I can't remember right now.

To ask a question -- IF management had the bodies/trucks, wouldn't Response be a 2nd wave of dedicated CRRs?


an experienced CRR will beat a computer generated solution most of the time. I will never contest that. However, Management wants cheap labor... and with cheap labor you have to spoon-feed the complex, difficult decisions to them. I've said time and time again, FXE wants to implement an amazon-style workforce, little to no benefits -- use & abuse and throw away after a few years. Legacy costs, such as 401k, retirement plans, health insurance, etc, gets expensive quick with a veteran workforce.

Now, why don't we just update the old DRA maps? The reason is that it's a royal, ROYAL pain in the ass with how DRA is setup. Remember earlier when I said that having to migrate all the FedEx generated data from the old maps to the new maps? From what I understand and how it's been explained to me -- how special items are setup in DRA is a geofence area around where the grain (address) would plot. If the address plots in that certain defined box/polygon, then those special parameters apply. A map update could change where the address plots by a few hundred feet, which causes the grain to not be in the area and the special parameters would not be applied to the stop... and then the avalanche of extra work starts. Finding out that stop no longer gets the special parameters applied, then it has to get fixed, and not every location gets a package each day, multiply that by the 2000 or so stations FXE has. Not to mention the chance that a map update mixes up special parameters because the two address plots changed and criss-crossed.

E* changes that. Addresses are treated as separate entities (called shares) and the map plot is only used for solving. That way, even if the map plot point changes because of an update, the special parameters is per address and will be retained.

and remember folks, just because I think that E* is a needed upgrade, doesn't mean that I like it. I think it's wildly inefficient to send three CRRs where we used to send just one. I think that it's BS that they can't let a CRR be focused on an area so they can know it like the back of their head, instead opting for swing-like behavior in even more towns and cities that they pass through. However, management wants to cut labor costs and one way is to make the route so brain-dead that anyone who can drive a Sprinter safely can be successful 95% of the time without a massive investment in training and time spent gaining area knowledge.

When implementing Estar company wide causes massive service failures and increased costs they'll have no choice but to eliminate it or watch the stock get shorted to .

 

[McFeely]

To ask a question -- IF management had the bodies/trucks, wouldn't Response be a 2nd wave of dedicated CRRs?

That’s the problem. We’ve been running Response without the staff needed to support it. Estar delivery windows immediately turn to crap at 12:00 when a third of my station heads back to the station to get more deliveries.

 

[Star B]

That’s the problem. We’ve been running Response without the staff needed to support it. Estar delivery windows immediately turn to crap at 12:00 when a third of my station heads back to the station to get more deliveries.

And that's a problem technology can't fix. That's a staffing/senior leadership issue that Memphis needs to take care of. Of course in bad manager school they will blame local management for people quitting, when the people go up to the manager and explicitly tell them the reason why they're quitting is because the pay sucks and they can go across the street and make more money and kill their body less. These are also the new hires that can't breathe without a LTE signal on their phone.

E* isn't the magic fix, but is a step in the right direction technology wise. It's going to take a massive shake up in Memphis for them to realize that they got to get back to the "People" in PSP.

However it is unwise to keep old, outdated, and possibly insecure software running on your network. Does everybody forget what happened in 2019 when Memphis got shut down for that cyber attack? The faster we can get rid of ROADs, the faster we can get rid of outdated software on more computers internally.

And for those naysayers that haven't even looked at the E* development site on the intranet, you will see that it is in the near future roadmap for "excrement hits the rotary oscillator" scenarios.

In the end, it's like this. Progress is painful. Development and finding bugs takes time. You can sit for years in staging running tests and until you go live, a bug won't show up. Tweaking the algorithm takes real world data. FXE is working to get all that internal data working together to make something better, 10 years later than everyone else in typical FedEx fashion. E* rollout will be ending soon for the peak freeze (or I sure hope so) but I think once they get Peak under their belt this year, there will be a massive push for the rest of the major markets to convert come spring 2023.... Or a massive pause in rollouts while they get their heads out of their asses.

That remains to be seen, however.

E*, in some form or fashion, is here to stay permanently. It is NOT AN OPTION to stay on ROADs forever and the faster we can get rid of ROADs the better it will be for the company because we can get rid of the outdated and ty processes/data.

 

[floridays]

E* isn't the magic fix, but is a step in the right direction technology wise. It's going to take a massive shake up in Memphis for them to realize that they got to get back to the "People" in PSP.

You know you are blowing smoke with that.
Why did you even offer that?

When they changed to the portable pension they stated in company publications that they basically considered it a transitory job, hence, 'the pension you can take when you leave.'

 

[compscigrad]

You interrupted the circle jrek? Then you're a shill. Them's the rules.

Huge if true

 

[Nolimitz]

Management has firmly embraced technology and creating routes with sequences. To try and fight back to 100% SRA-style CRR routing isn't going to happen in the long game. Yes, there may be areas that don't see E* for decades, but those will be few and far between and a tiny blip when it comes to cost and revenue. Don't be like the horse buggy and whip manufacturers when the automobile came around. Change is happening whether you like it or not.

Do you know what wildly outdated software platform ROADS ran on? Did you know that the main developer of ROADS is no longer with the company and hasn't been for quite some time? Did you also know that the way ROADS/DRA handles special conditions (such as business closed/opens later) is a hackjob and every map update causes a massive headache with updating existing FedEx generated data, including moving GPS coordinates for manually coded addresses?

That's one of the many reasons to get away from ROADS and onto E*. To get rid of the code rot of an unsupported program (have any of you actually seen DRA assist???) and make it easier to injest and process all sorts of new data, GPS pings from the LEOS/trucks, live & historical traffic data, quarterly map updates (without the massive headache of moving all the grains in ROADs around).

Remember when I've said there's plenty of heads to the hydra that is E*? You're starting to get a deeper look into it.


One of the reasons why they push E* is the ability to finely tune routes. You can define "5 Routes Starting from Downtown Chicago, Leave Station at 0800, 8 hours of delivery, 60 minute break RTB 1500" and then define "Wave 2 Routes starting from DT Chicago, Leave Station 1200, RTB 2000, 7 hours delivery, 60 minute break". There is even more granularity in the route definition (primary/secondary), where the routes will start solving from (the seed points, kinda sorta like loops in DRA), and other things that I can't remember right now.

To ask a question -- IF management had the bodies/trucks, wouldn't Response be a 2nd wave of dedicated CRRs?


an experienced CRR will beat a computer generated solution most of the time. I will never contest that. However, Management wants cheap labor... and with cheap labor you have to spoon-feed the complex, difficult decisions to them. I've said time and time again, FXE wants to implement an amazon-style workforce, little to no benefits -- use & abuse and throw away after a few years. Legacy costs, such as 401k, retirement plans, health insurance, etc, gets expensive quick with a veteran workforce.

Now, why don't we just update the old DRA maps? The reason is that it's a royal, ROYAL pain in the ass with how DRA is setup. Remember earlier when I said that having to migrate all the FedEx generated data from the old maps to the new maps? From what I understand and how it's been explained to me -- how special items are setup in DRA is a geofence area around where the grain (address) would plot. If the address plots in that certain defined box/polygon, then those special parameters apply. A map update could change where the address plots by a few hundred feet, which causes the grain to not be in the area and the special parameters would not be applied to the stop... and then the avalanche of extra work starts. Finding out that stop no longer gets the special parameters applied, then it has to get fixed, and not every location gets a package each day, multiply that by the 2000 or so stations FXE has. Not to mention the chance that a map update mixes up special parameters because the two address plots changed and criss-crossed.

E* changes that. Addresses are treated as separate entities (called shares) and the map plot is only used for solving. That way, even if the map plot point changes because of an update, the special parameters is per address and will be retained.

and remember folks, just because I think that E* is a needed upgrade, doesn't mean that I like it. I think it's wildly inefficient to send three CRRs where we used to send just one. I think that it's BS that they can't let a CRR be focused on an area so they can know it like the back of their head, instead opting for swing-like behavior in even more towns and cities that they pass through. However, management wants to cut labor costs and one way is to make the route so brain-dead that anyone who can drive a Sprinter safely can be successful 95% of the time without a massive investment in training and time spent gaining area knowledge.

deleted

 

[MAKAVELI]

And that's a problem technology can't fix. That's a staffing/senior leadership issue that Memphis needs to take care of. Of course in bad manager school they will blame local management for people quitting, when the people go up to the manager and explicitly tell them the reason why they're quitting is because the pay sucks and they can go across the street and make more money and kill their body less. These are also the new hires that can't breathe without a LTE signal on their phone.

E* isn't the magic fix, but is a step in the right direction technology wise. It's going to take a massive shake up in Memphis for them to realize that they got to get back to the "People" in PSP.

However it is unwise to keep old, outdated, and possibly insecure software running on your network. Does everybody forget what happened in 2019 when Memphis got shut down for that cyber attack? The faster we can get rid of ROADs, the faster we can get rid of outdated software on more computers internally.

And for those naysayers that haven't even looked at the E* development site on the intranet, you will see that it is in the near future roadmap for "excrement hits the rotary oscillator" scenarios.

In the end, it's like this. Progress is painful. Development and finding bugs takes time. You can sit for years in staging running tests and until you go live, a bug won't show up. Tweaking the algorithm takes real world data. FXE is working to get all that internal data working together to make something better, 10 years later than everyone else in typical FedEx fashion. E* rollout will be ending soon for the peak freeze (or I sure hope so) but I think once they get Peak under their belt this year, there will be a massive push for the rest of the major markets to convert come spring 2023.... Or a massive pause in rollouts while they get their heads out of their asses.

That remains to be seen, however.

E*, in some form or fashion, is here to stay permanently. It is NOT AN OPTION to stay on ROADs forever and the faster we can get rid of ROADs the better it will be for the company because we can get rid of the outdated and ty processes/data.

It's a step in the wrong direction. FedEx can update the system and maps without trying to automate our jobs as couriers.