channa

While I see your point, I think the big concern is the pain in the near term, and then how long that near term may be, combined with the architecture choice and what it means on a day-to-day basis in the long term.

Keep in mind that they've already scrapped FastSHARES and are doing something different. This delay and sometimes get scrapped. But I agree with you, it will probably be a good thing to give the CO staff the tools they need, and to restore for the UA staff the tools they had taken away.

The next is the architecture choice. CO tends to think the back-end system is secondary and likes programming everything in ancillary systems. That's fine on paper, but in reality, what we've seen is that you lose the robustness and related functionality with some ancillary apps since they're not as tightly integrated (e.g., the inability to waitlist with EUA, or the inability to pull miles at the gate). There are also some reliability concerns (e.g., the dropped partner space issue), but I'm not sure why that happens to CO records as often as it does.

Sulley

Native SHARES is an old, outdated system just like Apollo (Apollo is actually older if you want to get technical).

It's not a horrible program to learn, however, but I will concede that the company should have kept Apollo (with FastAir only as Native Apollo is just as labor intensive as SHARES) OR waited to roll out a new integrated SHARES system with a GUI overlay.

But that's just one little cog's opinion.

1KPath

I agree with all you have said...and when FastSHARES is in place, it will probably be as rapid for CS as FastAir. The problem is that instead of waiting for the FastSHARES to be implemented, UA/CO management decided to introduce a less CS friendly process for over half of their flyers (PMUA)

Unfortunately, I...and many of my employees have to travel in "weather" more often than we would like, and need to alter flights on a regular basis...UA (AA and DL as well) has always been able to do this rapidly and without much stress...our experiences with CO have not been as positive. UA/CO "suits" have indicated to me that this is primarily a result of the different booking systems and that they hope to have a unified FASTShares in place by the end of 2012...which means we (PMUA fliers) have nearly a year with the "old" SHARES. For an airline to make it more difficult on their best travellers just does not make sense...but common sense is a casualty of the new corporate style

On another, but related, subject, my nephew who is completing his Ph.D. in Management at Warton told me that the UA/CO merger is all the rage in classrooms there...and that there is one professor that is using the post merger IT shakeup at UA as an example of the pathology of dissimilar cultures in mergers!...No kidding!!

HobokenFlyer

When I was in LHR a couple of week's ago the UA transfer desk in Term 1 agents comments was "it's like going back to the stone age".

- HF

halls120

Yes, but it's cheaper. That appears to be all that matters to the new COdbaUA.

colpuck

Maybe, but the program has a higher level of functionality than APOLLO, which allows CO to do more things with it. As of right now CO used they system as the backbone for what is the industry standard website.

Yes, CO.com is the industry standard, and you don't have to take my word for it ask ANY airline IT guy.

Define far longer, and are you sure this has to do with the system as opposed to learning they syetem.

Show me numbers.

I am not criticizing your posts.

Your positions is a based on a false premise, you assume as people have expressed that they do not like change, that all change is inherently bad. I harken back to previous discussion where two independent studies posited the idea that the then United Airlines was the worst major airline in the US next to DL or US depending on the study.

Also, assuming you are correct that it does take some time longer to complete a task in Shares as opposed APOLLO, speed is not the only thing. If the extra time allows the CSA to better address the customers issue, as opposed to sending them somewhere else then the extra time is a good thing. I do not know this to be true, but it is an assumption on the same level as yours.

What is not in dispute is the follow SHARES has a higher level of functionality and is less expensive than APOLLO. Taking those into consideration and evaluating the effect on the bottom line and the consumer SHARES was selected even though it is slower in some respects than APOLLO.

In your previous post you conceded that Shares has more functionality than APOLLO. That must have factored into the discussion.

UA-NYC

No, it's the system. Have talked to agents doing the training, and have heard from plenty of flyers w/extensive experience on both airlines - SHARES is antiquated. I wonder how well businesses would work if they went from Windows/Linux-based systems to DOS...

Feel free to give a shred of evidence yourself that SHARES in its current form is anywhere near as quick and intuitive as FASTair is, or even any FT post referencing SHARES being "fast", "user-friendly", etc.

channa

I'm sure we'll be camping out to get rebooked.

dan1431

It is my understanding from talking with CO agents that SHARES works, not well by any means but it does function.

Do I feel that problems could arise from SHARES being adopted by the Legacy UA side, possibly, maybe even probably.

From my understanding SHARES can and in some cases is really less than ideal, one case is apparently re-bookings on other airlines, SHARES is clunky and requires tons of "typing" to correctly re-book somebody on another airline.

Does that mean SHARES is horrible, I have no idea, but it at least seems to function enough for CO to operate on a daily basis. Function to a level of "great" CS, like many of my UA FT brethren are accustomed to on the legacy UA? That is probably open to debate. My guess is probably not, but only time will tell.

Dan

sbm12

No one is suggesting that in this thread that I've seen. Compare SHARES to Apollo for a proper comparison.

One of the major advantages SHARES offers is that it is readily extensible and freely so. As such, when the company wants to change how things work or integrate additional systems into the environment they can do so with relative ease. Apollo required contract work and much more time in general.

denCSA

The main reason this is going to be such a headache is because under normal circumstances an airline technology migration takes YEARS (absolute minimum of 1 year when no webservices or external systems are involved, but usually 2) to plan and execute. UACO are doing this in roughly 9-12 months, and with UA's size and number of external systems it is guaranteed to be a disaster.

Not all this is completely UA's fault. Travelport had UA by the [you know what] with the Apollo contract and UA's decision to shelve the Star Alliance common platform migration left them with few options.

channa

How is that a proper comparison? UA airport staff seldom touch native Apollo. They use FastAir. CO airport staff always are in SHARES.

From a customer experience standpoint, the functionality and usability of FastAir to SHARES is going to be the proper comparison.

halls120

No, that, wasn't my premise. My premise was why was COdbaUA adopting a system that was less efficient than the one currently used.

every report I've read says it takes longer to accomplish a given task under SHARES than under APOLLO.

So, spending more time with customer A because it takes longer to manipulate the system is a good thing? What about customers B-Z who are waiting in line behind customer A?

Good for you in asserting an issue I wasn't addressing or contesting.

In other words, COdbaUA is taking the cheaper alternative.

Luvs2snowbordbut1kSEA

I have no idea about the IT difference between SHARES and APOLLO. All I can comment on is from a pure customer perception... and it takes (what seems like) forever for a CO agent to do a simply re-book. A massive amount of typing and struggle... regardless of the reason.

If that is SHARES, then it is not customer focused.

SFOtoORD

That doesn't mean that a new UI won't fix it in the future. As for them scrapping FastSHARES, that may be just fine. Laying a UI built for one back-end onto a new back-end may not have worked well and starting from scratch could just be the better option.