The announcement that the merged United Airlines would be keeping the legacy Continental CRS system – SHARES – was made a few months back. Not particularly surprising given the lower licensing costs and the lower customization costs for the product going forward. When this decision was announced it was also suggested that the migration would include integration with a new front-end interface, similar to the FastAir interface that United has been using for many years now. Apparently that plan isn’t working out so well.
I’ve now received reports from two different sources indicating that the development on the replacement GUI software is significantly behind schedule and the migration date for the server-side systems is not slipping to match it. The net result is that United front-line employees will be switching back to a command-line interface to manage most transactions, switching away from the current Windows-based system.
|Buh-bye, pretty GUI (This is a generic shot, not the FastAir system)|
Reservations agents are expected to migrate to the EZR system which does provide GUI access to the GDS. It is only the airport agents that will be stuck with the old terminal interface.
Such a change in operational software, regardless of the amount of training provided, will result in a pretty messy consumer experience. The change is expected to happen either late this year or early next, with "native SHARES in use for several months." It will ultimately be replaced with a home-grown GUI that will interface with SHARES but it will apparently be several months before this is available for the agents to use. That is not good for customers.
This news certainly makes me wonder if maybe former CIO Keith Halbert was right to jump ship earlier this year. He tried an end-run to keep Apollo, even after SHARES was announced as the new platform, and it cost him his job. If he saw things like this on the horizon that might not have been such a horrible move, though I still think the way he did it was pretty stupid.
Never miss another post: Sign up for email alerts and get only the content you want direct to your inbox.
I actually don’t think this will be quite the disaster everybody expects, since many of the agents have experience with a mainframe terminal. The greater disaster may be when they implement a GUI to it, since everybody has to learn a new GUI.
@mowogo: I’d like to have that optimism but it is hard for me to do so. It all comes down to training. Always has and always will. The problem is that there is simply never enough training and the agents do not retain it well, especially if they do not start using it immediately after being trained. If they get trained in January and don’t start using it until March they’re going to forget half of it anyways.
The smart ones will figure out how to do the new stuff just like they figured out how to do the old stuff. And it will be fine eventually. And even if they went the other direction it would be a mess as the other half had to learn the “new” system. But I have no confidence that this will be a smooth transition, either the first time or the second when they convert to the new home-grown GUI that is in the works and a few months behind this switch.
@Scott: Waiting would be nice but the license with Apollo is expiring and they also need to get to the single platform sooner than not to be able to get the back-end operations fully integrated. Even with only the CLI it will be better for the customers to have everything in a single system.
I think the issues will be with new agentsblike myselfbthat have only known fastair and never learned Apollo. Those that know Apollo will be able tonunderstand the process even though it isn’t exactly the same. In my opinon UA would solve a lot of headaches if they waited to migrate to the new system on a station by station basis. That way if a UA agent had problems in shares they could AK a CO worker the question much easier.
Comments are closed.