Rich O’Mara, ETL & Big Leap Project Leader at Thomas Cook Group Airline shares a Multi-AOC implementation

Just to set the scene before we look at the main topic, the ETL/ELB implementation, I’ll share a brief profile of Thomas Cook Group Airline, Europe’s tenth largest airline if you count the aircraft in all group fleets (Figure 1).

There are 100 aircraft across the group and 8,500 employees transporting 18.5 million customers each year to generate GBP3.2billion revenue. Thomas Cook Group Airline operates under five AOCs (Air Operator’s Certificates) and keeping all of those AOCs aligned is a major management task with the ETL/ELB being just a small part of that.

When talking about ETL, we often categorize the introduction processes available as the ‘Big Three’. It’s possible to introduce an ETL from a paper techlog, some move from a legacy electronic techlog to a new generation, integrated solution or it’s possible to start from scratch – set-up an AOC and run an airline with an eTechlog from day one. Thomas Cook Group Airline has done all three in the last year.

In Scandinavia we went from a paper techlog to the Panasonic Toughpad with the Danish authority. In the UK, the airline went from a legacy electronic techlog which wasn’t integrated with AMOS (Thomas Cook Group Airline’s MRO system) to the Toughpad being integrated into AMOS. Finally, in Spain, it was a new airline, Thomas Cook Airlines Balearics, launched from scratch with the new ETL. The first Spanish Airline to have an ETL approved with the Spanish authority. Each of those projects had their challenges, on top of which, we had to try to keep them all aligned. That accounts for three of the five group airlines: the remaining two, both German airlines, are next in line as we implement the ETL across the business.

In this article, I want to share our journey to the ETL (Figure 2) at the time of writing. I’ll include the good and the bad things that we experienced plus the lessons that we learned from the exercise, probably the most useful bit that readers can incorporate into their own plans.

 

ETL History

The earliest ETL in Thomas Cook goes back as far as 2006 (Figure 3) when MyTravel Airways had the first UK ETL approved.  That system was on a standard Windows laptop with an integrated EFB and ETL. MyTravel merged with Thomas Cook in 2008 and after the merger, the ETL was spread to the rest of the airline. The original intention had been to integrate the ETL with RAL, the MRO in place at the time but after the merger the decision to move all airlines onto AMOS meant that ETL integration slipped down the priority list until after the MRO system merger.

In 2012 Conduce took over the provider of the ETL/EFB which was, by then, a Panasonic Toughbook with both EFB and ETL function on it. Minimising the number of computers in the flight deck seems sensible but everybody wanted to use it at the same time during the hour before take-off. Pilots wanted to complete performance calculations, engineers wanted to close down defects and, even with two devices in the cockpit, it couldn’t be managed easily because there were parallel independent calculation requirements for the pilots for safety reasons. So the decision was taken to split the two functions with the pilots adopting an EFB-only solution and with the Panasonic Toughbook continuing to be used for the ETL. However, the device in use at the time was getting quite old and had to be renewed. Thomas Cook Airlines looked into the market for an ETL to replace the old solution. In light of existing good relationships with Conduce and with CrossConsense, it made for a hard decision. Both companies were really good but one had to be picked and that was Conduce.

A new ETL was needed quickly because the old ETL software was running on old hardware and on an old operating system which was becoming increasingly unreliable. Also, there were lots of areas where there was duplicate work: for example, the cabin log. In the UK airline, there was a paper cabin log but an electronic techlog. One of the cabin crew would make an entry to the cabin log; if it was an airworthiness matter, the captain would then type it into the electronic techlog which, because it wasn’t integrated, would send an electronic message to a tech clerk who would type the entry into the maintenance system. There was a lot of duplication of effort and each of those manual inputs was an opportunity to introduce error.

The airline also wanted a single way of working, a prerequisite to being a large and successful airline. Introducing a group electronic techlog was a way of making sure that everybody changed to the same single way of working. As well as being efficient, this delivers better compliance oversight and improves safety, a key factor in Thomas Cook Airlines’ decisions, not only regarding the eTechlog but also in other areas of the business.

Business Benefits

These are not exclusive to this project or to the solution that Thomas Cook Airlines selected. With any such project, there will be a reduction in the amount of errors in the system; but the biggest unexpected discovery from this project was the number of data errors that were being fixed by the tech clerks at the point of data transfer from the ETL to the MRO system. We’ve already seen that the ETL was being completed by the pilots or by an engineer or both; the data was then going to the tech clerks and, as they typed it in to the MRO system, they would make corrections. Good from one point of view but, from another viewpoint, there was no oversight of that process; there was no management of the errors or any feedback to Operations or Line Engineering about the errors they were making so that they could reduce them. Also, no-one was making sure that the corrections were correct. When the first trial of a single aircraft was run, before the data was going into the live system, we could not understand the differences between what was going into the test system and the live system which, at that point, still had the tech clerks typing in the data they saw whereas the test system was getting the raw data straight from the machine. There were huge differences with incorrect flight numbers, incorrect city pairs and errors in flight times. So the project team gradually had to build in additional checks and balances to make sure that data going automatically into the system is as accurate as it can be.

Over and above that, Thomas Cook Airlines gained the benefit of real-time analysis with instant access to the entire fleet technical status as soon as the flight log data has been entered. We’ve already covered the benefit of a fully integrated system but the other thing that no business can ignore is that the efficiency this delivers means reduced turn round times, improved on-time performance and reduced costs.

The Conduce system that Thomas Cook Airlines uses does integrate with the airline’s MRO system, AMOS. It’s also important to remember that the technical implementation of this project is the easy bit; fixing technical problems as they arise is straightforward… identify the problem, determine the available solutions, select one, implement it. The difficult thing is change management outside of that: getting people to adapt to processes, getting individuals trained to the right standard and to retain the training that they’ve been given. That’s where all of the challenges encountered by this project have come from.

The eTechlog workflow

This is quite a complex picture, in Figure 4, to illustrate the workflow for the eTechlog.

The important thing is what Thomas Cook Group Airline added to the system. The original planned workflow did not have the ACARS planned integration (top left of Figure 4), it was not part of the original scope. Compared to the start of the project the scope expanded considerably, but each expansion was for a very good reason with safety and data accuracy being key parts of that. The ACARS data now audits the time that the pilot enters onto the device. Pilot entered times are subject to a series of checks that have been incorporated into the ETL software which look at the schedule, the ACARS messages, the city pairs, if they all match then the data can go straight into the MRO system. If there are any issues, if anything doesn’t match, that flags up to Maintrol who get an email. They can then go to a webpage and look at a queue of flights awaiting manual audit. This process uses the four-eyes principle so that, if something doesn’t look right to the system a human is tasked to go in and check and reproduce, in a controlled manner, that original tech clerk data correction facility but on a smaller scale with traceability.

The next stage of software, released recently, will auto-populate the ETL OOOI times with ACARS data thus taking away another chance for someone to mistype: so, at the moment about half of the flights going to the audit process are there because of a mistyped time by a pilot. Now, the pilot will just review the ACARS data and, if it ties in with what they are expecting, it will automatically go through into the system.

I’ve already mentioned scope creep and one of things that we found was that people really like the ETL, they like the website, they like all the data that’s there; but not all the data that is collected on the ETL goes into AMOS. So people can’t always get reports on things that they want to know about, which means that reports have had to be built from eCentral 8, the middleware, on things like anti-ice reports, fuel and EU ETS (it was much easier to get the data out of the Conduce middleware than out of AMOS) as well as the autoland reports. These were not part of the original project scope but because of the benefits of doing each one of those individual elements they’ve been added on and delivered to the business.

Prior to the techlog rolling out, the average time it would take for a paper techlog page to be input into the MRO system was between an hour and an hour and a half but could be up to 10 or 11 hours if it was the wrong end of a shift and/or somebody was off sick. Now, that data is going into the AMOS MRO system in a minute to 90 seconds. We’re really pleased with that increase in speed and almost real-time visibility of the aircraft status in AMOS. Maintrol can see whether data has gone into AMOS or not: they can see the status of all the devices on the website and that includes whether the data is in AMOS yet or not.

The project timeline (Figure 5.1) illustrates the journey that Thomas Cook Airlines has taken.

 

The UK project timeline was an area where we gained a lot of information about what could be done better in the future. The software was rolled-out, we were all happy with the software with which we were going live; the pilots and engineers were trained and then we found a couple of bugs which were to do with the data quality issue referred to above and which had to be addressed. It was necessary to go back, produce another version, test it and roll it out. By the time we had rolled out the live version to the pilots and engineers four or five months had passed since their training. Although from a user perspective, the software hadn’t changed that much – the interface was the same, the process was the same – there had been quite a gap between the training and the device going live and that wasn’t ideal.

The other aspect was that, for the UK, because they went from an old ETL to a new ETL, we took the view that this was a small change which could be managed using computer based training (CBT) only. In hindsight, that was not the case. When the Scandinavian roll-out came, we had learnt from the UK experience so we used both CBT and ‘hands-on’ training and rolled-out within a month of the training to the whole fleet. It went really well with issues in Scandinavia amounting to only a very small fraction of the issues that we had encountered in the UK.

The Balearics went live with the ETL from day one and so it was part of the pilots’ induction training which includes ETL training; then, as soon as they’re online, they’re working with the system. There have been no issues reported from internal elements.

Third-party training is an area of challenge with Thomas Cook Airlines having much less control over third parties; so we deliver both CBT and face-to-faced training. However, when somebody new joins another organization, they don’t necessarily get the same degree of training. That means there have been issues with line engineers at third-party bases not quite following the process as Thomas Cook would like.

But the good thing is that Maintrol have devices so that if an engineer calls up and doesn’t understand what is going on, Maintrol can follow through on a device in front of them. Also, there is 24/7 support from Conduce who can connect with any device that’s online and see exactly what is happening. Also the website shows the current device status to assist with trouble shooting.

The UK roll-out started towards the end of 2017 with full CAA approval signed-off. We have then been rolling-out to the rest of the fleet. Looking at the Danish roll-out (figure 5.2), the first thing we did was to get the DTA, the Danish Authority, in and took them through a desk-top exercise to show them the device and how it works, using a dummy website and test version of AMOS. We let them see the dataflow and, because of the UK experience with the evidence that had generated, they agreed to a much shorter testing phase for Scandinavia which was another reason we were able to get that roll-out completed so quickly. In fact, in January 2018, the Danish authority came in for what was supposed to be an audit but, at the end of the audit, they were so comfortable with what they saw that they gave their approval right away without any further application being necessary.

 

As Figure 5.2 shows, there have been more AMOS database mergers and more AMOS upgrades which have forced the project team to take further pauses.

The next step, in April 2018, was a post-implementation review with the UK, Scandinavia and the Balearics to ask them what had or had not gone well. A list was compiled using lean methodology to rank all the insights contributed and it was pleasing to note that there were no significant on-going issues. There were a couple of wrinkles to be ironed out which has been done with some software and process changes to try and make the system easier for the crews to use.

All of those lessons will be used for the Condor roll-out which is planned for late 2018. Thomas Cook Group Airline has already met with the LBA, a meeting that effectively replicated what was done with the Danish authority. There is an element of herding cats in all of this. Although everyone is working to EASA regulation, each national authority has to approve which means that interpretations of what a regulation means slightly differ. So, we have to gently try to persuade them that Thomas Cook Group Airline aims to have a single solution for all of the airlines in the group without divergence which is a challenge in this regard.

After the Condor roll-out, we’ll consider Thomas Cook Aviation, the group’s new AOC in Germany, and then will be looking at Phase 2, feature testing and roll-out. That will mean two-way communication between the ETL and AMOS. At the moment: defects are raised in the ETL; they get sent into AMOS and then the work order reference comes back. In the future, we want to be able to set defects raised in AMOS into the ETL.

All Thomas Cook Airlines UK, Thomas Cook Airlines Scandinavia and Thomas Cook Airlines Balearics’ aircraft are now live with the ETL.

This is, perhaps, the most useful information we can share with readers.

 

Get your NAA on board. It is always smart to have the authorities involved into the process early to address particular regulation for the respective market.

If you’re going for a multi-AOC roll-out, try to get the relevant CAMOs aligned to smooth the integration with all relevant stakeholders involved in the development.

Data quality; as mentioned above, we had not appreciated how much data was being incorrectly input to the system. Data must be as accurate as possible.

Training is key; it really is important to get people on board and understanding why the change is being made as well as how to do it.

Processes will need to change. Thomas Cook Group Airline found that the ETL drives process harmonization backwards through the organization and that process alignment is very important so that you’re not constantly managing differences.

As with any project, keep people informed. It’s a constant challenge in an age of communication overload: it’s not possible to just transmit all the time. Make sure that the messages delivered are short and sweet and to the point, otherwise they’ll just get swallowed up in the mass of communications that we all see.

An experienced international programme manager within the airline industry Rich has gained experience and success in delivering multi-national business change initiatives. He is also a current Captain on the A330 and A320 with extensive Flight Operations and Maintenance Management experience.

The five airlines in Thomas Cook Group Airline have 100 aircraft and 8,500 staff. Fleets include Airbus A320, A321 and A330 types as well as Boeing 757 and 767 aircraft. Fleet management is a joint enterprise across the group with further integration planned.