Case Study: Moving to a Cloud-based M&E System at Copa Airlines

Author: Pablo Rousselin Avendaño, Senior Projects Manager, Copa Airlines

Subscribe

Pablo Rousselin Avendaño, MRO Director at Copa Airlines describes a transition to a modern, mobile cloud-enabled Maintenance & Engineering platform

We have succeeded with a rather important MRO system transition at Copa Airlines and, in this article, I’d like to share that story with readers in the hope that some useful insights will come out of it. This particular journey started in 2014 and there are a few updates that we have managed since then. Previous to this transition there were two systems that we used: one for the Embraers and the other for the Boeings, which we piggybacked on Continental/United systems. A decision was made to select a system that would unify both requirements under one, which ultimately helped us to become independent. Additionally, this independence facilitated a better control on our maintenance programs. The decision was to embark on that endeavor, and we ended up selecting IFS’s Maintenix to meet our requirements.

WHAT HAPPENED

It was decided to go for a full implementation; engineering, planning, supply chain, maintenance, the entire thing. At the time, Copa’s fleet stood at one hundred aircraft and there were 1,300 users; more critically, there were only 15 months allowed to complete the project. That was already a challenging task and Copa knew that it would require a partner who would commit to the project. Right from the start, the new system was in the Cloud which, as far as we know, was the first time that a monolithic MRO software was put into the Cloud. For that we used Amazon Web Services.

THE CURRENT SITUATION

Since those first steps, IFS Maintenix has been upgraded twice at Copa Airlines in order to maintain access to the latest features introduced to the system. It was also recognized that a records management system that was in-line with the MRO system was needed. AirVault from GE Aviation was selected and implemented. Furthermore, a further six Boeing 737MAX aircraft had been added to the fleet that required a new maintenance program, a project in its own right. In addition to this, there are now another one hundred users taking the total to 1,400.

WHAT WAS WANTED AND NOT WANTED?

It all started with a review of where we stood: that was very important, and it has been a rule for project implementation in Copa Technical Operations to take that step first. We next sat down with our SMEs (subject matter experts) to consider what our functions and processes were: then we had discussions to make the necessary changes. I thought that everything would be good because Copa was already digital, and yet it turned out that there were some duplicated processes with some people doing the same things. As a result, some of the ‘as is’ processes had to be revised and summarized.

Of course, the other side of the coin was that we also needed to know what Copa Technical Operations wanted to be. So the ‘to be’ processes had to be defined. That was the point where Copa went to IFS to explain what was wanted and to ask whether IFS could commit to it. Only then the planning was actually started.

ESTABLISHING RULES

Secondly, we needed rules as part of our methodology. Together with the stakeholders we established the following guidelines:

1. Avoid customization;
2. Put the common benefit over the individual one;
3. Adopt industry practices (processes);
4. We are Copa Holdings (so we include all the areas and stations involved);
5. We make decisions in a timely manner;
6. Do not assume. When in doubt, ask;
7. Fulfill our commitments.

Basically, this established what needed to be done and that was then properly enforced. ‘Fulfill our commitments’ was especially important for Copa Technical Operations if you commit to something, you really need to complete it. But none of this was imposed on people, it was part of our Change Acceleration Process methodology which included taking a snapshot and the team was held accountable to that commitment to the end. And, of course, nothing was assumed, and everyone put their trust in the rest of the team and had the freedom to comment at every point.

That ‘team’ (above) is not just Copa but is the RAMS team, the project implementation team which included the IFS team.

Another key rule was that we didn’t want to get involved with costly customizations.  This goes hand-in-hand with putting the common benefit over the individual one. With the exception of one customization that was deemed critical, Copa eliminated more than a dozen other customization requests which were deemed non-essential.

MANAGING THE CHANGE

Rules were necessary as were the rule enforcers in the organization (figure 1)

Figure 1

One very important person in there is the Change Manager but while it seemed a bulky structure at the outset, by the end of the project, we were very pleased. My own role of Business Manager had one lead subject matter expert from each of the airline’s divisions as well as the current system administrator who had been in charge of the two legacy systems for Copa Holdings. This new system is also integrated with SAP, the Enterprise Resource Planning System at Copa Airlines, and with the Operation Control System, and it was decided that it was necessary to have a manager to manage those changes. Not giving that person the chance to also be in charge of the project would have been counter-productive.

But we had to admit that there were things along the way that we didn’t know. Most importantly, we often didn’t know that we didn’t know it! So, we were flexible when it really mattered.  For instance, at the very beginning it was necessary to compare whether to do the whole thing on premises or in the Cloud. Trying to do this in the Cloud had not previously been tried so there was an element of risk along with the usual time and financial constraints.  Because we were committed to it, we spent a lot of time in working with the vendors and senior management to ensure this was possible.  Admittedly, there were things that changed after we visited some other operators involved with Maintenix. We also realized that maybe we were not thinking the right way, which meant going back on our tracks to accept that something needed to be changed. All of this was done meticulously and was well thought through with change requests that went to management. We didn’t move at all, in terms of general strategy, without doing so.

As soon as we knew what was needed, we had to let all the stakeholders know. That was a change management program in its own right (figure 2) and, without it, the project would have failed because we didn’t know at the beginning how many people were for or against change.

Figure 2

We just thought that, not because everyone said that they disliked the previous systems, they would like the change for a new one. We had to determine who really wanted to be on-board, who didn’t and then see where we wanted that matrix of stakeholders to be. That was really important and we never run a project now without change management.

Also, figure 2 highlights the important need of communication often and consistently.  It wasn’t a case of sending everybody an email every day nor making presentations to the upper management every other week but we had a RAMS team breakfast meeting every Friday to keep everyone up to date on status. I would present to my boss every two weeks. The result was excellent because, as a result of the Change Management program, people got on-board quickly, and remained on-board.

TRAINING

Training was another program deeply rooted in the Change Management team. One of the first things we did was set up a website for remote training. Our goal was to train at least ninety percent of the people twice over. We also realized that with the regular population, the mechanics, if they were trained three months before the go-live, they will have forgotten that training by the time of the go-live. That had to be changed. So, the Change Manager created a website called ‘RAMS U’ where a user could review everything that they had been taught, get exercises and communicate on a platform that looks a lot like Facebook. But, again, we undertook a change management exercise and realized that that population needed to be taught again. That’s why Change Management had to be in charge of training.

Another really good take-away from the project is that, while we wanted there to be a lot of communication we didn’t want to include any miscommunications. At some point, there was huge pressure from the very top of the business. At another point we were having commercial discussions with the provider. But we shielded off the SMEs from all of that and kept them focused with the task at hand. They needed to undertake their technical contribution, but they didn’t need to know how much the project was costing or who was doing the catering. The management team needed to be the shield for pressure, for all of them. That’s downstream.

But upstream, there was exactly the same thing. At some point a couple team members seemed to be discouraged but we resolved it within the team and ironed it out. It’s important to choose what to communicate on all levels.

GENERATING A TEAM SPIRIT

People normally don’t like uniforms. At Copa, not everyone needs to wear a uniform. However, as soon as this project started, we decided on a logo on which the whole team voted and people actually asked to have a shirt so that they could be identified with the project. And the interesting thing is once you put on the shirt, you could not tell who is from IFS, Copa, and or others. You can’t tell who is a senior manager or who is an SME.

Interestingly, when we analyzed this picture, taken at the end of one of the routine change management meetings, the leaders of the project are blended with the team. In the project, everybody was treated the same way. That made a great difference for team morale: they were treated well because we were asking them to deliver and that meant that the productivity was higher than it might have otherwise been.

Now, whatever project that we are undertaking at Copa Technical Operations, we have a logo competition after which, everyone wants a shirt, mouse mat, stickers, whatever… they want to be identified and that’s very important to them.

HARNESSING ENERGY TO EXPERIENCE

Our team was composed of people with a lot of experience but also some very young people. We were able to consult with two other operators on how they had done things. If it weren’t because of having people with a combination of skills the project would not have been successful. It was a good blend of experience and energy and the team did a fantastic job to fulfill any voids which brought to mind a quote from Isaac Newton ‘… and we could see further because we were standing on the shoulders of giants.’

From time to time team members would make unusual requests such as asking for a more flexible work schedule. It wasn’t how we worked but their response would be to commit to us that they’d finish the current task on time. So, in the spirit of flexibility, we agreed to try it and it worked out really well: in fact, productivity increased and we caught up with any shortfall there might have been.

PROBLEMS ARE THE BASIS FOR OPPORTUNITIES

So, combining different talent sets as well as benchmarking is highly critical and it reminded me of another quote that I really like: “Every problem is an opportunity in disguise”- John Adams. We started with a problem, that we didn’t have control over the maintenance program: at the end we had reduced costs, improved efficiency and we were proud of what we had achieved. And interestingly enough, at the end of this project, we were able to consolidate a team that is eager to other projects together. That was very important because, normally, after such an exhausting project the SMEs do not want to come back for more. Six months after this project, we told the team that we needed to upgrade in order to incorporate a couple of features. So we needed to do it all over again. The good thing was that they all smiled, recognized that it would be tough but as long as it was going to be run in the same way as the original project, they were all on board. In that way we have undertaken two upgrades. One thing that we feel we have really adopted at Copa Airlines is to try to find opportunities in problems: how can we do this, how can we solve this but, at the same time, reduce costs. That mentality was a really important component in our success.

Contributor’s Details

Pablo Rousselin Avendaño

After starting his airline industry career in Engineering, Pablo also held multiple managerial positions at major airlines in Line & Heavy Maintenance, Maintenance Planning, and Fleet Management before moving to Technical Operations Projects. It was only natural, due to the nature of the current industry trend, to be given the responsibility over the MRO Systems department as well. Pablo holds a Masters in Aerospace Engineering and a Masters in Applied Economics & Business Administration

Copa Airlines

Compañía Panameña de Aviación, S.A. (Copa), is the flag carrier of Panama. Headquartered in Panama City with its main hub at Tocumen International Airport, Copa is a subsidiary of Copa Holdings, S.A. as well as a member of Star Alliance. Copa Airlines has one of the youngest and most modern fleets in the region with 84 aircraft consisting of 6 Boeing 737 MAX 9, 14 Boeing 737-700, 68 Boeing 737-800 and 19 Embraer 190 planes. 

IFS

IFS develops and delivers enterprise software for customers around the world. The industry expertise of its people and solutions, together with a commitment to delivering value to every one of our customers, has made IFS a recognized leader in the sector. The team of 3,700 employees and growing ecosystem of partners support more than 10,000 customers around the world challenge the status quo and realize their competitive advantage.