New IT for MRO, the build or buy dilemma

Selecting and implementing a new MRO IT package is, as Juswil Adriani, MRO liaison engineer at AirAsia explains, a complex process with a number of factors in play

Earlier this year (2011) AirAsia was awarded ‘Sky Trax Low Cost Airline’ of the year, the 3rd consecutive occasion (2009 thru 2011) on which the accolade had been awarded to the carrier. This achievement, and the wider success of AirAsia, can be attributed to a number of factors: how the business was founded; one individual’s vision to build the airline into the world’s leading low cost carrier (LCC); its formative years and, the subject of this case study, how an MRO system was selected.

Technology has been a mainstay of the company. The drive to apply and optimize the use of IT has been one of AirAsia’s key successes with one department, Innovation Communication and Technology, responsible for the continuing growth of this area in the business; and this department has won many awards for creativity. AirAsia was the first airline in the world to introduce on-line and SMS booking. The carrier was also ranked among the top 50 most innovative companies in 2009, alongside Google, Sony, GE and many other multinational organizations. This reflects a determination to keep abreast of the pace of IT development.

So, when it came to selecting an MRO system for the airline, the choice was straightforward. It had to be easy to use, adaptable for low cost airline operations and be able to be implemented in the shortest time possible. The reason for the haste was to minimize the resources occupied in the project in order to concentrate on early years’ growth for the company.

As has already been mentioned, from the outset AirAsia has set its sights on becoming the largest company of its sort in the world, testimony to which is the ordering of 300 Airbus A320 NEOs (New Engine Option) at the recent Paris Air show. This expansion in terms of fleet size is deemed necessary to beat off fierce LCC competition in the South East Asia region. There are also plans to open new routes and hubs, including AirAsiaX (long haul), as well as extending services to new destinations in places such as North America, Africa and Continental Europe.

How it started
No airline company in Malaysia had ever had a fully integrated MRO IT system until AirAsia introduced software from Denmark in 2005. Before then, airlines in Malaysia were not too concerned about how they kept their data. The usual pattern was for each department to have their own methods for gathering data and generating reports but without any coordination or connection with other areas. As a result, a great deal of effort and resources were needed just to capture and put together the information needed for even a simple management report.

The departmental software choices were often MS Excel and Access; both were popular and easy to use programs but had drawbacks when used in the MRO environment. They created islands of information across the Engineering departments, resulting in confusion. For example a part number with duplications (dashes, spaces) would be misleading and this had, on many occasions, contributed to delays or aircraft on ground (AOG) events when an incorrect part was requested using these spreadsheet references. The situation was getting out of control and aircraft operations were experiencing problems as a result of inaccurate data being provided.

It was realized in AirAsia that this process could not continue as it was for very much longer. Major cracks were beginning to appear in the system (or lack thereof). Work processes now involved a complex series of linked spreadsheets that lacked data integrity. The process had outgrown its current database; the legacy system was no longer able to provide the meaningful analysis that the organization required. There was no formal system in place for the internal processes so it was decision time on how to proceed; either to purchase commercial off-the-shelf software or build a customized system. If the decision was to build, would it be outsourced to a third party vendor or would the system that was specified be created within the company?

During its early years, AirAsia always made engineering software a high priority. CEO Tony Fernandes has a keen interest in the system and sat in on some of the discussions during the implementation to lend his support to the project. The company regards the system as a means to cement cooperation between the three AirAsia entities in three different countries. As the company grows and expands to other countries such as Japan, The Philippines and Vietnam, a solid integrated system will be an essential component for the engineering department.

AirAsia’s initial strategic growth was dynamic. There were discussions about possible cooperation and joint ventures in several countries within South East Asia. But high on the list before any such tie up could materialize was how to streamline processes between the different hubs in order to achieve maximum efficiency. It seemed clear that, by investing in a single software tool, it would be possible to standardize the flow of information between countries. The software required also had to be flexible in order to handle the complexities of running engineering operations in these countries which raised various issues resulting from the different regulations applied by the authorities in each place.

What was needed was software with a good track record and wide international exposure to be able to deal with cultural and cross border issues: the system now in place in AirAsia boasts over 100 customers around the world.

Low cost operations may be essentially the same everywhere but there can also be idiosyncrasies specific to particular airline operators. AirAsia’s decision, in the early days, to change their fleet from B737 to all Airbus, was a significant milestone for the company. This event has had some impact on the choice of software required to handle the new state-of-the-art Airbus planes. It was necessary to consider the system’s ability to support Airbus aircraft operations and to deal with the number of aircraft in the company fleet, which will be 175 planes by the year 2015.

AirAsia’s first attempt at MRO software engaged a local vendor who tried to build the system from the ground up. That approach failed, due to a lack of knowledge about airline engineering processes. There was no development team which could create applications on the scale expected, and there was a worry that if a local team attempted to develop the software, they would underestimate the time required. The consequence might be a lengthy delay in deployment of the application. The project did not last long and was deemed a complete failure after three months. Subsequently, in 2004, AirAsia engaged Scandinavian MRO software company AMICOS.

At the time AirAsia had an ageing B737-300 fleet; aircraft leased from all over the world. Their original data were dubious and questionable; also, these planes had an average age of about 20 years. After leasing them from various leasers the data of these aircraft were maintained manually by the company.

Changing to a new system
Also at the time, AirAsia was in expansion mode with all available resources and manpower geared to this purpose. Multitasking was common and it had also impacted the implementation project of the second engineering software package introduced to the airline. The resulting problems cascaded to all engineering departments causing the project to overrun and not meet the deadline.

How the build or buy decision was made
The build or buy decision is important and complex. AirAsia wanted the most cost-effective, functional and feature rich solution, but it was not always clear which decision was right for its process.

AirAsia does not have a development team and the skill set required; hence it could not develop an application in-house. The IT department does not have core competency for building complex software applications and would not have been able to build it better than if it was bought. There is no development team which can create applications on the same scale that is expected, and there was a fear that if a local team attempted to develop the software, they would underestimate the time required to build the application. Because its IT resources were limited, the obvious decision was for the airline to acquire proven software from a reputable company.

The main rationale for using off-the-shelf software is lower initial costs and a reduced time to deployment. But there was a study, not empirically proven, that the on-going costs of per user licensing and maintenance until end of system life may make off-the-shelf a very expensive option over the long term. Also AirAsia was wary that the support package for bought software, if it stopped generating enough revenue to support the running costs for a software business, might cease completely. It’s unlikely that another company would pick it up.

In a crowded marketplace where MRO IT software is a radical industry, AirAsia had to do a careful due diligence to identify and evaluate the software solutions available. This can be a very time consuming process and was particularly so for AirAsia, a novice at this game that did not know the landscape very well.

Many MRO IT software companies came to AirAsia tendering their products: they provided free evaluations of their software and they all made sure that a cross section of future end users was able to test the functionality of the evaluation versions.

Most MRO IT software is rich with features, bells and whistles. They have to be, to try to meet the requirements of a very wide ranging group of users. However this meant that AirAsia wound up using only two thirds of the features in the software, but had to pay for all the modules even though some were redundant. Since the software is intended for a wide user group, it was not absolutely perfect for the operator’s engineering department. However, AirAsia found that the MRO IT modules, met enough of its requirements to make it still an attractive option.

The company was also cautious that it should not be negatively affected by having to drastically change its processes to fit the software. Some users had opined that it should work the other way around. The system should work for you.

As most low cost airlines in Europe were already using a topline off-the-shelf MRO IT software package, this presented the quickest and most cost-effective solution. Considerations about which the company took a very thorough approach were some very common off-the-shelf traps. It had to make sure of the real costs before proceeding. AirAsia evaluated several software modules before purchasing to determine whether they required extensive customization to fit the organization’s needs; it was important that the costs associated with any such work should be factored into the price. Some customers who had purchased a similar system found that they had to pay costs up to three times the purchase price in order for consultants to come in and customize the application. What looked like an attractive option because of lower initial costs had turned into a very expensive low, or negative return on investment (ROI) option.

Among possible risks in deciding to proceed with off-the-shelf software were that AirAsia would be at the mercy of the software vendor as far as future product features were concerned. Changes in aviation or the airline industry could have significant implications for software requirements. If a paradigm shift started to occur in the ever changing aviation environment, how much influence would AirAsia have on the software vendor to make extensive software modifications, and at what could be the cost?

In dealing with MRO IT vendors, for a major airline like Ryan Air which may have a multi- million dollar contract with the software vendor, the odds are pretty good that the vendor will listen to the user and move accordingly. At the time AirAsia was a very small portion of the software vendor’s revenue, so the odds were they would tell us that we must wait until enough of their customers have requested the feature(s) in order for development to make economic sense for them. There is not much that can be done at this point. Software vendors also have to run their businesses profitably: in fact, AirAsia would want the selected software vendor to be profitable. A failed software vendor would not be available to support their product. It is a frustrating feeling being locked into a product financially without any development influence so it was an important factor that AirAsia choose the software vendor carefully. It made a lot of sense to choose a vendor who was responsive and willing to work as a partner with AirAsia. Our guiding principle was to ask the right questions right from beginning; it’s all part of doing due diligence.

Build In-House
The decision to build a software application in-house might seem obvious when you have access to your organization’s development team. The arguments for doing so are often as follows:

• The IT department knows the company’s processes better than anyone else;
• The IT team can develop precisely what is needed;
• They have direct control over future development and can react quickly with modifications as the business changes;
• The airline has a complete understanding of how the system works;
• Since it is proprietary, there is no worry that the competition would get it as well;
• The company has already budgeted for and is already paying the fixed cost of the development team salaries;
• There are no off-the-shelf software applications that even come close to providing the specialized functionality required.

There may be some truth to the statements above, but be careful that you do not buy into your own propaganda. It could wind up being a very costly decision for your organization if your analysis is flawed. There is a tendency to skip the due diligence phase and many times the analysis phase when deciding to develop software in-house. Accepting the above statements as fact within your organization could be quite risky. Each organization is unique and your development department is also unique. But, not all development departments or developers are created equal, so you need to know the capabilities of your company’s development team.

Return on Investment
It is impossible to calculate an accurate return on investment (ROI) for in-house development projects for the following reasons:

• It is impossible to measure opportunity costs before the opportunities present themselves;
• It is difficult to allocate developer salaries to the project, particularly if the developers work on multiple projects or have other duties;
• Ongoing support costs are difficult to predict;
• Ongoing maintenance costs are often overlooked and, again, are difficult to predict;
• ‘Scope creep’ and the associated ‘cost creep’ are often ignored and difficult to predict;
• There is a tendency to underestimate the time and resources required to design, develop and test;
• It is difficult to estimate a ‘contingency amount’.

Lack of maintainability
The biggest nightmare of software built in-house or by a contractor is that the author will leave, and nobody else will know how the code works, how to recompile it, or sometimes even where the code is located. This situation means job security for the author, but insecurity for the organization. At AirAsia staff turnover, particularly in the System Administration, was quite high. This had to be dealt with by ensuring a succession plan before the administrator could leave the company.

Lack of standardization
There’s a training cost associated with software built in-house. New employees need to be brought up to speed on your system, even if they’ve used software elsewhere that performs similar functions. This is one of the most common reasons why people choose to buy software even if it doesn’t completely fit their needs.

Which is cheaper: buying or building?
As a low cost airline, cost is always going to be a main factor so answering this question ‘buying or building?’ poses some perennial challenges. The costs of buying an MRO IT package are pretty clear cut and relatively predictable: licenses, startup costs, implementation service costs, on-going maintenance or usage fees. Building projects require an accurate estimation of the project length and its costs, labor and benefits (programmers are relatively expensive), and general and administrative costs, as well as the costs – sometimes allocated – of the infrastructure needed to support the system. While the trick to evaluating the cost of ‘buy versus build’ comes down to figuring out the long term maintenance costs of a home grown solution, there’s no clear cut rule of thumb. One obvious benefit is that the costs of buying a solution should be more predictable than building one: use this to your advantage if pursuing the buy option by pressing for fixed prices or not-to-exceed prices for implementation service costs; or consider taking on much of the implementation yourselves (but be aware that the provider of the product will almost certainly have a better understanding of their own product and therefore should be more efficient at its implementation).

Implementing the MRO IT system
The gestation period of the system had to be extra fast according to the company’s management. If the project period were protracted beyond six months to a year, staff would become tired and lose interest: also, resources were minimal while the company was continuing to grow. It was decided not to hire anyone dedicated solely to this job. The plan that emerged was to take some Licensed Aircraft Engineers from line operations and put them in the project team on a rotation basis. This did not bode well for the implementation project timeline.

Taking into consideration the limited resources and costs available in this project, AirAsia chose the gradual approach instead of the preferred ‘big bang’ event.

Being AirAsia, and famous for its unconventional ways as well as for dumping conventional methods, the management decided not to have a formal presentation to its engineering staff about the newly acquired system. It was a sudden transition. The previous system was literally dropped overnight. A group of project consultants from Singapore were flown in to begin the requirement gathering stage. It was a ‘shock and awe’ approach spearheaded personally by the Company director.

End users were given an ultimatum by senior management to accept and quit the current MS Excel/ MS Access based processes that they had been using and start using AMOS 100% within six months.

Quite quickly, everyone was aware that the company was totally committed to this system, having spent quite a considerable amount of money on its purchase. And management did not hesitate to deal firmly with any users who were not working in compliance with the project. Today AirAsia is in the 4th year of using a pure play MRO IT system which is one of the leading software packages in the industry. At peak period the system usage has about 120 users logged in to either update or retrieve data from the system. For all of the challenges that it posed, the new system was carefully selected and successfully implemented; and AirAsia is now reaping the benefits of a well-managed transition.