Did you know that eight years into the American Airlines-US Airways merger, not all work groups were on a single system, and the merger wasn’t ‘complete’?
American was one airline to passengers long before it was a single airline to employees. They adopted a single reservation system in 2015, but flight attendants were still scheduled as separate US Airways and legacy American Airlines crew until 2018.
The airline’s systems for tracking aircraft maintenance were still separate – until last week.
Credit: American Airlines
As of Friday, May 7, American Airlines has completed moving its aircraft into the SCEPTRE system for tracking maintenance. No, not that SPECTRE.
American is using SCEPTRE, System Computerized for Economical Performance, Tracking, Recording and Evaluation. And they had to do the data migration by hand.
If my understanding is right, SCEPTRE was first the maintenance system used at North Central Airlines which became Republic in 1979 and was merged into Northwest. That’s how it became the maintenance system for Northwest, and then Delta after those two carriers merged. Newer carriers seem to use newer systems (like TRAX or EmpowerMX) but SCEPTRE remains popular especially with large airlines merging operations.
As American explains in an internal document,
After American and US Airways merged in 2013, Tech Ops had part, tooling and aircraft data in three different core systems. This involved having multiple application windows open on the screen — a timeconsuming process. To solve this problem, we needed to consolidate the number of systems being used and create an easy and consistent team member experience. This has been the TESS Team’s mission for the past six years.
First American undertook ‘Materials Migration’ to move parts and tools into SCEPTRE over the course of three years (there are “more than 600,000 manufacturer part numbers” the airline needs). This was completed in February 2020. The second phase, Fleet Migration, started in May 2020 and took a year.
AA has done their migration nearly flawlessly with virtually no unexpected customer impacts. This is a back office system that does not impact this blog’s audience. Just another non-news, AA beat-up post.
@Rick, I am a part of this blog’s audience. I enjoyed this post. Please don’t speak for me.
@Rick – As an AA flyer, I was not offended. The same migration would probably take as long at United or Delta, and Gary never implied otherwise.
Rick: For many of us this was interesting information. It’s helpful to understand how carriers approach their internal operations because it can have direct effects on us customers. It took years for UAL and Continental to get their Flight/Cabin crews under one roof. I got caught in that mess because a UAL crew ran out of hours and that airport was Continental-staffed so the flight had to be cancelled. If you don’t like what you see, maybe you need to find another blog to read.
The real lesson is that AA has been willing to accept inefficiencies from not unifying its operation; you can’t argue that there wasn’t a cost to maintaining dual systems.
And Delta and Southwest both succeeded much more quickly in unifying their operations including resolving the labor issues that required separate systems at AA and UA.
This is an interested story, at least to me. I wonder why this process took so long.
So I do a lot of work in this space. Here are a couple of additional notes for those interested:
– All three legacy US airlines (AA, UA, and DL) use SCEPTRE as their primary maintenance and engineering system. It’s old, as Gary described, and is mainframe driven. It also has no central owner but is essentially maintained by armies of consultants from firms like IBM or DXC. Each airline’s implementation of SCEPTRE is quite different.
– These systems, whether they are old or modern, are always trouble to work with and especially difficult to migrate or integrate. Airliner maintenance is an incredibly complex and massively unoptimized field. It’s not just about keeping data on the planes, it’s about each plane’s millions of parts. Its about the technicians and their certifications and currency on their training. It’s about maintenance scheduling, maintenance planning, warranty management, record keeping, spares management, parts tracking, exchanges, pools, prognostic, etc… There are a plethora of applications to be managed across a plethora of end users and stakeholders.
– It may seem obvious that maintaining a plane is unlike maintaining a car, but few outside the industry know the differences. Here are two that add to the complexity:
1) When you buy a car, you deal with the company (or dealer) who sold you the car. If your seat breaks, you don’t need to worry about who built the seat so that you can get support from them. Not so for an airplane. An airline needs to have a direct aftermarket relationship not just with the airframer (Boeing or Airbus) but with everyone in the supply chain.
2) Cars have VINS and centrally recorded maintenance history. Planes do not, and keeping track of a plane and its parts can be nightmarish. Consider this: a part can have zero to three serial numbers (one from the manufacturer, one from the supplier, and one from the airframer.) Different systems put in place at different times can refer to the same part on a single plane with different IDs. Working through this mess, manually associating and disassociating data from disparate systems, is one common factor as to why maintenance system integration work is so complex.
Congrats to the team at AA and all who helped them on this journey. It was a long project to be sure, but one that was ultimately executed well!
And yet they still haven’t installed power outlets on all of the old shit-box USAir A320s and A321s…
Every company is different. I’ve observed that the main reason people tend to nitpick about this kind of minutiae – without knowing all of the facts and challenges involved – is when the commentator wants bad things to happen to the company or if they feel it somehow benefits a company the commentator likes. That’s also how politicians tend to think. Politicians and lawyers tend to be the only people who want bad things to happen to good people, especially if they feel it benefits them politically or financially.
SCEPTRE utilizes a hierarchical database system to track aircraft parts and assemblies from the largest – the aircraft itself, to individual parts. Basically trees of parts. The database system lends itself to this type of structure, much more than a tabular / relational DBMS.
It wasn’t that the use of a relational DBMS wasn’t looked at over the years, but they didn’t match the performance. A HDBMS record can be accessed in a single I/O. All its data segments within the read block.
An indexed HDBMS parent record in a minimum of two I/O. Any related child data records are also a minimum of two I/O away, unless the parent record contains duplicated data for the related child data to exist in same table. This speeds reading, but has heavy update consequences.
While there are many Relational DBMSs out there, I’d be hard pressed to name a second Hierarchical DBMS. Part of the reason SCEPTRE has been platforms where it is for so long with RDBMSs being loaded with its data to support much of the reporting and what/if questions that they are very good for.
During the TESS project the number of aircraft in AA SCEPTRE went from around 300 to over 1000. Because the underlying databases were not HALDB, and I didn’t want to convert them to HALDB, I installed Hardware Assisted Compression with Ziv-Lempel dictionaries custom built from unload files of core databases (18 at the time). Hardware Assisted Compression is standard equipment on the z series and the compression exit stub module is supplied with IMS database software. In other words, this was a freebee and today the same databases are less full than they were with only 300 aircraft. Hardware Assisted Compression is a valuable tool to extend the usable design life of legacy IMS applications. It also can replace expensive vendor compression software with annual maintenance fees higher than my salary.
Congrats on getting all aircraft into SCEPTRE. Quite a feat.Can imagine the thrill to have that behind you.
There were other options. One of those was putting child segments into new dataset groups. But this would require a lot of testing and validation of existing programs.
Compression was seamless. I had done this during Y2K upgrades at a previous employer. Adding the compression was done with an unload/reload (reload using the new DBDs with compression exits). This was followed by a reorg of the 23 logically related core databases in SCEPTRE. Some other databases outside the core group were also compressed with unload/reload using the modified DBDs.
I was shaking out new utilities at the same time so it was a great learning experience.