BoB and ERP: Working together, IT Works

Fernando Moura de Lucena, Manager Business Solutions IT at VRG Airlines (Gol Group) tells how the effective implementation of a best of breed MRO system with ERP and Flight Ops system can drive cost savings and increased productivity

It’s long been a matter of discussion in our industry as to which package to implement: a best of breed MRO (maintenance, repair & operations) or ERP (enterprise resource planning) system. In 2006 we were discussing what options were available for us to introduce to equip the business with the technological resources needed to drive our planned growth. Because we were an airline and not a classic MRO (repair station), we were concerned to ensure that the project to implement a new control system for maintenance should meet all the functional requirements of our current line maintenance operation and the future needs of our heavy maintenance operation (in our own hangars).

At the time we operated a fleet of 112 Boeing 737 NG aircraft in a typical line maintenance operation, sending any of our aircraft that needed heavy maintenance to an external repair station. But, projecting future needs for heavy maintenance in the fleet, we had initiated the construction of our own hangar for that work. At the same time, we also started a project to replace the current maintenance system with one that would be better configured for maintenance and materials planning, and task scheduling. Also, from a corporate standpoint, we needed to adapt this new system so that it could be integrated with the company’s financial controls. Since 2004 we had been running an ERP package as our financial system. This project for a new maintenance system would have to be able to interface with the ERP for accounting and tax purposes when booking purchases, transfers and materials consumption.

The main justification for a new maintenance package was the clear need for a system with better planning capabilities. Up until that time we had had a good control system that operated well in terms of forecasting based on the frequency and intervals of maintenance tasks with some level of materials forecasting. Given the new reality of planning to undertake more heavy maintenance within our own facilities, we would need to go beyond the capabilities of the current system, to be able to not only take care of forecasting in the same way that the current system could but also to work with greater resources and within more extensive constraints. We also had to bear in mind that, in addition to materials, we had to take account of manpower (quantity, location and skills) and time (availability of aircraft) resources necessary to accomplish maintenance tasks; so a ‘resources planning capability’ was an absolute necessity. The variable ‘time’ component within required resources for planning purposes was the most critical one because Gol’s maintenance program was based on single running task cards (approximately 6000 single task cards effective for all aircraft in the fleet), following the MSG3 philosophy. Using this system, any ‘aircraft out of service’ event is always analyzed to check whether the ground crew is qualified and equipped to perform the required maintenance tasks.

Remembering that our old maintenance control system was also responsible for aircraft movements, we had to take into account the necessity of a further replacement for that purpose when a dedicated MRO system was implemented. So, a parallel project was launched to implement a new system for aircraft movement control (aircraft rotation), replacing the existing functionality on the old maintenance system. On the maintenance side of this project there was still a requirement to interface both systems in order to ensure online updating of aircraft hours flown and maintenance cycles, and thus the components that would have to be available.

Therefore the scope of our project had had to be broadened to take into account all the requirements of maintenance control, either line or heavy maintenance, and of interfacing the new system with the ERP (financial) and the Flight Operations system (also new), without in any way compromising or degrading the company’s technical or financial controls.

In summary, we had to address the following scenario:

• An existing system for controlling maintenance tasks and materials but without many resources for planning those maintenance tasks and materials: this system was also responsible for the fleet’s records of flying hours and maintenance cycles (aircraft rotations);
• An ERP responsible for all financial control including inventory accounting, and interfaced with the maintenance controlling system (tracking events in the maintenance system and the accountability counterpart in the ERP system);
• The necessity of changing the current maintenance control system for another with better planning features (including finite capacity planning) but without the inclusion of aircraft rotation information.

Furthermore we were faced with the question of choosing between a specialized system (BoB – best of breed – MRO system) or a generic one (ERP).

As we already used an ERP system specifically for the company’s financial controls, the task of evaluating its capability for maintenance control against our project requirements was relatively simple. We already knew the ERP system’s capacity for managing maintenance processes in various industries. But, in the event, when it came to addressing specific requirements of aircraft maintenance processes, including scheduling different kinds of tasks, planning resources or materials tracking – even a simple requirement to register a part number or materials transfers – our ERP system was not able to deliver a satisfactory result.

Most people would expect systems categorized as ‘BoB’ to be small, for local usage, and suitable only for small operations. Many companies make use of Excel spreadsheets, also considered as BoB, for a series of controls and it works for them; it depends on the type of business and the size of the company.

For us, this was not the case: we had a fleet of 112 aircraft (now 115), a hangar under construction and a line maintenance operation in more than 40 stations (now more than 60 throughout Brazil, South America and the Caribbean). A BoB system would have to support and manage the work of thousands of people. We currently have over 2,000 employees in the aircraft maintenance area using the new system.

In an evaluation of required functionalities and features for the proper implementation of controls and maintenance routines, the following considerations were established ​​in order to compare the features of ERP and an expert system (BoB) as follows:

• A BoB MRO system provides all the terms (language, dictionary) used in aviation. In terms of better adaptation and acceptance of a new system, the application of known expressions from the daily usage of the normal users is an extremely important factor during the phase of getting used to the new system. This feature can be easily understood by the users as a characteristic of readiness.
• A BoB MRO system has specific controls for aircraft maintenance needs found only in such systems. To implement the same features in an ERP system inevitably would generate excessive costs of customization.
• A specific solution for MRO is built according to the typical processes carried out in an airline, repair station or M & E (maintenance and engineering) area, which are often already compliant with the requirements of aeronautical authorities and international organizations (FAA, EASA, IATA). An ERP solution provides for the best practices of a number of industries.
• MRO systems are often natively integrated with flight operation systems. In terms of control and traceability this is a big difference, something that if were to be created in an ERP would necessitate a major degree of customization (as we know, you need a reference date, time and airport information; this would make the installation and removal of components, a hard task for an ERP system to run).

That said, having a good to excellent interface with the ERP was essential to ensure the quality and accuracy of financial and accounting controls. Due to the fact that our company is listed on the New York and São Paulo Stock Exchanges, all financial reports and compliance status must be generated by the company’s official financial system, which has its internal processes approved and properly audited. Also, although a BoB MRO system has full capability for tracking technical materials transactions, the ERP system is the one responsible for managing the materials inventory in terms of cost (it represents a large percentage of the company’s equity) and other accounting controls. The challenge then was to live with two systems, because an airline has to record non-aeronautical materials, services and transactions in as large quantities as are used in the aircraft maintenance process. So, the particular operational needs of each system and process must be understood to avoid, among other things, too much effort spent on software customization from both sides. Nowadays there are a great many MRO systems with APIs (application programming interfaces) already developed to work with major ERP systems in the market.

Therefore we defined the scope of our project as the need to replace the old maintenance control system by another with better planning capabilities, and able to adapt to the need to interface it with the company’s ERP system. At the same time, we would also need to replace the present aircraft movements system (running inside the old maintenance control system).

Even before starting the project we faced some critical issues, as follows:

• Project organization: we had great difficulty in mobilizing the necessary people from areas outside the maintenance area. In the maintenance area, a designated project manager coming from the business increased the mobilization and participation of people from that area. For other parts of the business, the support of senior management levels was essential to guarantee the same degree of commitment.
• Process mapping: critical and important processes in the aircraft maintenance area were reviewed based on the best practices made possible by the new system, plus we took advantage of the opportunity to correct old systemic problems.
• Critical data migration from the old system: this was a decisive factor to ensure a successful implementation. We had a database built up over nearly nine years of operation. FROM-TO scripts between tables were constructed very carefully to avoid data integrity problems. Multiple data consistency checks were carried out with the help of the vendor to ensure maximum data integrity.
• Training: Approximately 2,400 people had to be trained in the various modules of the new system, across diverse areas of the business: line maintenance, hangar, engineering, maintenance technical control, inventory and materials receiving; all at different locations. The challenge was to accomplish all the training needs, taking into consideration the availability of people, and within a period of four months. In order to manage that we arranged a total of 16 full time training rooms in five different locations (including our new hangar), material for training (books and written tests) and training environments (databases) preloaded with a specific database prepared for the purpose of the training. A team of trainers, formed of employees from different areas of the business, was prepared by the supplier in order to replicate the training locally. In addition, a CBT (computer based training) program was created to be available for refresher courses after the regular period of training.
• Interface: the objective was to avoid compromising the effectiveness of the maintenance process, materials traceability control and, to make best use of the resources planning functions and capabilities of the new MRO system; it had been decided to run all procurement processes, material receiving and movement, in the MRO system. This proposal in the beginning caused some discontent mainly because we would have two systems in the company responsible for procurement (ERP would still process the demand for non-aeronautical items), but in the end it was decided to comply with the requirements of the maintenance area, defined on the project.
• Two companies, two fleets, two systems: at the time when we were selecting the new MRO system, our company had recently acquired Varig, a legacy airline company in Brazil. For some time after the acquisition, Gol and Varig had continued to operate as separate companies with the fleets of both companies kept in different places using their own controls and systems. One option had been for the Varig maintenance control system to be discontinued in favor of the system used by Gol. The Brazilian Civil Aviation Authority then determined that the new company resulting from the merger of Gol and Varig should run one single maintenance control system and have a single maintenance control process. That ruling supplied one more justification for the project. It also resulted in new challenges, when the target given by the Brazilian CAA was considered as the deadline for implementation of the new system, which was also seen as the solution to the dual controlling system problem.

Still concerning the interface between the MRO and the ERP systems, a process change has been applied in the project to correct an existing error that existed in the previous interface between the old MRO system and the ERP. In the previous model, there was a process interface where transactions were done on one system and modified in the other. For example, a purchase order was generated in the MRO system and was supplemented or even changed in the ERP. Several times a change made in one was not done well in the other and this caused several problems for the records control. In the new interface we determined to change the concept: in future, all processes should take place in one system with only the final result (the data) transmitted to the other. In the same example of a purchase order, this should be fully accomplished in the MRO system with the final information (purchase order number) being reported to the ERP, which could only make changes through a new approval. The entire approval hierarchy was in the ERP.

From a technical standpoint, the interface between both systems was created using a middleware system, responsible for managing the dispatch of interface files in both directions. Some interface files, for example purchase orders and part number registrations, were broadcast online and in real time. Materials transfers between separate stations were passed at the end of day, in a batch interface.

An important point in the implementation strategy and one that has made all the difference in the project timeline was to focus on the defined project scope. Integrations and processes not directly affected by the change of MRO system as well as the correction of systemic problems that had been persisting over time were not included in the scope. In an operation that had been running for several years many problems had accumulated, and people formed the expectation that those problems would be solved once the new project had been implemented. But addressing such problems could have been a diversion from achievement of the main project objectives which boiled down to:

• New technology and processes for the maintenance area;
• Support for the growth of the maintenance area;
• Reduced operational costs;
• Increased fleet availability.

Another outcome from the project in the maintenance area was the creation of a competence center formed by employees who were actively involved throughout the project in process design, data validation, testing and acceptance; including working as trainers helping to replicate the training originally delivered by the vendor. These employees were divided into teams according to the main areas where users worked:

• Hangar team;
• Line Maintenance team;
• Engineering team;
• Supply Chain team.

As a main mission, this team provides functional support, serving as a level 1 user assistance help desk as well as a focal point in discussions for improvement and validation of new versions.

Flight Ops System Integration

Everybody knows the importance of good interface and integration between the maintenance control process and the OCC (operational control center), regarding the transmission of information about flying hours and cycles of the aircraft, and the components installed. When such integration can be managed through systems, real time information and quality can be achieved.

In our traditional process, the flight data (OUT – OFF – ON – IN) were supplied by ground staff at airports to our staff in the OCC by e-mail or by radio and were subsequently inserted into the control system, and for use by the maintenance area. With the arrival of a new flight ops system in December 2008, the ground staff at airports began to enter data directly into a web interface on the system, instantly updating the status of flights in both flight ops and maintenance systems.

Such integration is not only important in relation to keeping aircraft flying hours and cycles information up to date. If we could share the same view of the aircraft with both OCC and maintenance control area (the first observing the times of flights, landings and takeoffs, and the second paying attention to the times when aircraft are on the ground) would it be possible to better identify maintenance opportunities?

By ’maintenance opportunity’ I mean time when the aircraft is on the ground and when it is possible to perform maintenance tasks, given the character of our maintenance program (as explained earlier, we have adopted single tasks running within the MSG3 philosophy for our fleet 737s).

The introduction of new systems of flight ops (December 2008) and MRO (September 2009) has provided the following visual outputs:

• Below we can see part of the screen of the new flight ops system, showing the schedule of maintenance for the aircraft prefix GTB in line station FLN. The colors (brown) and codes (CRT) show the criticality of the task as assigned by maintenance staff. Certain maintenance tasks, given a certain degree of criticality, cannot be amended except by their own maintenance team, in the source system (MRO system).
• The same maintenance schedule seen above (gray), is illustrated below as seen on part of the maintenance planning screen in the MRO system. Note that the scheduling of flights is also displayed (blue) easily identifying opportunities for maintenance task programing.

Finally, below, the same screen now showing more aircraft, scheduled maintenance tasks and assigned flights.

This is a type of integration in two ways: first, we get information about aircraft availability coming from the flight ops system to the MRO system. Then, maintenance schedules created by the maintenance team are migrated to the flight ops system. This interface happens at regular five minute intervals. With this integration the maintenance team is able to schedule the maintenance tasks more precisely in accordance with the intervals of the maintenance program and, once done, this is informed in real time to the OCC. To avoid problems – because the OCC has the ‘power’ to delete assignments on the flight ops system, maintenance tasks can have different categories – expressed in codes and colors – from routine tasks to other mandatory or critical (AOG, for example) thus avoiding problems and mistakes and wrong interpretations. The critical maintenance tasks, once assigned, can only be modified by the maintenance team on the MRO system.

Opportunities for gains

What can we expect in terms of gain for the maintenance area with the implementation of a BoB MRO system integrated with an ERP system and a Flight Ops? In an airline, the maintenance area is typically seen as a ‘cost center’ or an area that does not generate income, only expenses. Therefore, thinking about profit possibilities in this area leads us to think about how to promote improvements in current processes aimed at getting a better use of resources and best practices made possible by the systems. Consider the following gains in different areas made possible by the design, integration and continued use of systems in the scenario shown so far. By area, we are going to have:Maintenance

• The incorporation of best business practices with the implementation of the new system. Being a system designed specifically for control maintenance activities, its internal processes adhered perfectly to the business requirements, reducing levels of risk in the operation.
• Better quality controls and reports, once the new system is fully compliant to EASA and FAA requirements.
• In contrast with an ERP system, a BoB MRO system can easily accommodate changes. One thing that supports this capability is the level of the software vendor’s knowledge about the needs of users on specific processes. With an ERP, there possibly wouldn’t be immediate gains considering that the learning curve would be greater.
• Better capacity for programming and planning maintenance tasks due to the quality of features and great usability found in the new system. With a few keystrokes, several tasks can be rescheduled. With a faster reaction to operational changes, gains in time and quality are enormous. Gains are also achieved through good integration (native) with the flight operations system.

Back office

• Better quality financial control through the new interface design and process (a data interface instead of a process interface).

Flight Ops (OCC)

• Negotiations over aircraft downtime, between the maintenance area and OCC, happen more dynamically due to the integration between the systems used by both areas. The codes created to identify the criticality of maintenance tasks makes it possible for the tasks to be completed successfully in less time.

IT

• Less customization is required, due to the strong understanding of maintenance business requirements within the MRO system.
• Less effort is required to support and sustain the new operating system because it is more technologically advanced. And during the project, a whole internal process of service management was designed to facilitate and expedite the solution of incidents.
• As an ASP (application service provider) solution, there is reduced TCO (total cost of ownership), with negotiation of SLA (service level agreement) consistent with the real needs of the business.
• Active monitoring of the interface layer.
• Even with the cost of interface development, in general, a reduction of IT costs.

Conclusion

Currently, serving three hangars and an operation serving more than 60 airports, the new MRO system is used to control and schedule all line or heavy maintenance tasks for a team of more than 2,000 maintenance technicians.

In line with the proposed objectives of the project, the maintenance area is constantly seeking to reduce the costs of existing processes primarily by the constant and efficient use of capabilities introduced with the new system.

Because it is a system aimed at controlling aircraft maintenance activities, in a typically MRO operation or in an airline, the new system was readily accepted by the user group who recognized its advantages and facilities. Specific controls and use of terms already familiar in the business were recognized as enhancing usage readiness.

A good interface with the company’s ERP and flight ops systems not only ensured greater flexibility and integrity in day-to-day transactions but also supported quality in the company’s technical and financial controls.

This is how the question about which would be the best tool to be implemented, an ERP system or a BoB MRO, was answered and handled in our company. Each scenario should be thoroughly evaluated to understand the advantages and disadvantages of deploying one system or another. The fact is that for a successful implementation; good planning, and full participation of people at all levels in the business is essential for the success of the project.

Remember: at the end we are talking about people too. Good luck and a good project!