The complexity of maintenance repair and overhaul systems is a common theme in aviation maintenance trade publications and conferences; it’s sometimes described as “overwhelming.” (While this discussion focuses on aircraft maintenance, it really applies to any complex piece of equipment.) I’ve seen the question posed in online forums; “why are MRO IT systems so complex?”

The simple answer is, because the documentation to fix complex machines is, by its very nature, complex.  It requires vast amounts of data, it comes from multiple OEMs and vendors, it’s stored in multiple databases in multiple formats, and it has to be acted upon by multiple departments and organizations.  People that perform line maintenance and base maintenance (field and depot), planning and engineering, tech pubs, IT and parts logistics all need to communicate about service and parts information, and practically every department has its own set of business systems that must share data, whether a tech pubs authoring tool or an ERP system. 

In brief, airlines and MRO shops need IT tools to do the following:

• Manage various content types (manuals, catalogs, best practices, etc.) from multiple sources (OEMs, field engineers, suppliers, etc.) across different business processes (maintenance, procurement, planning, etc.)
• Manage ongoing content publishing and updating cycles and distribute approved content to multiple channels and devices with a click of a button
• Control system and user processes, content flow in the organization, access rights and personalization
• Integrate technical content with ERP, maintenance planning and enterprise IT systems.

Given these multi-faceted needs, whenever an airline or large MRO shop decides to upgrade its IT systems, it can be a long, painful process to decide which tools are necessary, which ones will work with legacy systems and data, and which ones will work with future applications. Can it work well with new and emerging data specs (like S1000D)? Does it integrate with current and future ERP platforms? How much of the process should be automated (e.g. digital task cards and sign-offs)? What features are needed in an illustrated parts catalog (IPC)? Can it process technical updates from the OEMs (revisions and service bulletins)? Will it improve maintenance planning and scheduling?

These questions, and many more like them, are what drive MRO IT decisions. To help companies ask the right questions, and hopefully get complete answers, Enigma has created a sample RFP for the MRO industry. It is based on almost 20 years of experience in turning complex documentation into usable information, and includes the most requested and important functionality and requirements, as defined by airlines and 3^rd party MRO shops. While it is written in the language of aviation, we hope this document will also prove useful to customers and prospects in all industries as they seek to improve their aftermarket service and support processes.

Click here to download the RFP Sample.

Roni Pollack, Program Manager at Enigma, staffs the Enigma table at SUGAIR 57

I just returned from SUGAIR 57 in Kuala Lumpur, Malaysia. The SAP User Group for Airlines (SUGAIR) is a semi-annual conference for experts, executives and managers of maintenance, repair and overhaul (MRO) operations in the aviation, aerospace and defense industries. Enigma was invited by SUGAIR members to present Enigma’s capabilities with SAP and discuss the business impact of current and future integrations. SUGAIR 57 offered an impressive array of airline expertise and the feedback received by Enigma was overwhelmingly positive.

SUGAIR 57 was hosted by Malaysia Airlines in cooperation with SAP and HCL-AXON. Each of the attending airlines, MODs and MRO shops, delivered presentations detailing their SAP implementations, current challenges and strategies moving forward. SAP and HCL-AXON provided updates on their joint solution, as well as presentations on best practices, tactics and strategies for using SAP to maximize business success.

There was a long and intense discussion, led by several airlines, regarding the strategy of Boeing and Airbus to withhold service and parts information as a way to lock-in spare parts sales and control who can provide maintenance and repair services. The way it was reported by these airlines, Boeing and Airbus plan to limit airlines’ access to the aircraft maintenance manual (AMM), illustrated parts catalog (IPC) and other critical technical information unless the airlines agree to use the tech pubs solutions sold by Boeing and Airbus. The airlines on-hand, who had investigated these products, had the following comments about the OEM-based solutions:

• immature/incomplete functionality
• inflexible/difficult to integrate with existing M&E solutions
• limit airline’s ability to customize and control technical content
• risk exposing an airline’s confidential information and intellectual property to competitors (in the case of MRO services, competitors include Boeing and Airbus themselves).

This was a very animated discussion and I was surprised by the nearly universal anger and suspicion expressed by the airlines toward Boeing and Airbus.

For the Enigma presentation, SUGAIR members expressed particular interest in the ability to extract information from the IPC, AMM and maintenance planning documents (MPD) and then update the master parts list (MPL), maintenance requirements (MR) and job cards (task cards) in SAP. Beyond the ability to accelerate maintenance and improve compliance, the airlines, MROs and MODs on-hand quickly recognized another key implication of this functionality—helping identify inventory problems like “dead” parts that no longer apply to an airline’s fleet and can be safely purged/re-sold from stock. All the attendees commented on the huge opportunity this represents for cost reduction.

If the goal of SUGAIR is to generate meaningful discussions between companies with common objectives and to highlight topics that have implications on operations and compliance, then SUGAIR 57 was a success. Although the audience was varied—airlines, MODs, MROs, SAP and ISV partners—all the conversations I heard focused on increasing maintenance efficiency, consistency and compliance.

For Enigma, it was a pleasure to participate in SUGAIR 57 and to help facilitate the knowledge-sharing that’s required to solve tomorrow’s aftermarket and MRO challenges. This was a valuable opportunity for aviation and aerospace operators from around the world to learn how to maximize their business success using SAP, HCL-AXON and Enigma.

I just returned from the 2nd Annual SAP Airline Solution Summit in Dallas, which brought together professionals from around the world from airlines, OEMs, MRO shops, software vendors, IT consultants and even rail professionals. It was an impressive group with a lot of give-and-take between the presenters, the exhibitors and the audience.

During the afternoon breakout sessions, Enigma presented on the topic “Maintenance Scheduling and Integration to Technical Information.” It was a topic that drew a large audience, since we described the impact of OEM revisions on airlines, specifically on the efficiency, consistency and cost of MRO operations. Within this context, Enigma introduced a strategy for improving revision management and adoption through better technology and integration with ERP, tech pubs and maintenance planning systems.

The fact is, how OEM revisions and engineering orders/modifications are managed and integrated into scheduled and unscheduled maintenance activities affects the speed and compliance of aircraft maintenance, repair and overhaul (MRO). Since we are talking about revenue-generating assets, MRO efficiency and quality affects the very core of business operations. As a result, for many airlines keeping tech pubs and ERP/MRO systems up-to-date and synchronized has become a full-time job. (This is not unique to airlines but affects every transportation company and transit authority.)

Of particular interest to this audience was that Enigma automatically extracts information from the OEM’s illustrated parts catalogs (IPC), maintenance planning documents (MPD) and maintenance manuals (AMM/EM) and then updates the master parts list (MPL), maintenance requirements (MR) and job cards (task cards) in SAP. This ensures that service and parts data is always in-sync across the airline, whether it is used in a hangar/depot or in the field/flight-line. Since OEMs revise and update their technical documents frequently, airlines consider data accuracy and synchronization to be a huge benefit in terms of maintenance productivity, quality and compliance.

Another consideration is that because technical content directly impacts an airline’s second largest workforce (mechanics and engineers), the quality of that content, more than almost any other factor, determines if an MRO/ERP system succeeds or fails. When Enigma shared some industry metrics regarding the number of OEM changes, and the impact on maintenance operations, it proved the point and highlighted the need for an integrated solution of SAP, HCL-Axon and Enigma to improve aircraft MRO.

The audience in Dallas was very receptive to the insights Enigma was able to provide. Following our presentation, we had a number of conversations regarding the application of this solution beyond airlines including: rail, maritime and freight. We appreciate SAP inviting Enigma to participate in this annual event and hope to have similar opportunities in the future.

Airlines often have the challenge of adapting OEM data to meet their own maintenance requirements. One type of adaptation is called a Customer Originated Change (COC). Although it requires significant effort to manage COCs, it is usually worth the effort. COCs are derived from airline-specific business processes and experience, and are helpful in capturing and sharing best-practices and knowledge that is acquired over time. But some airlines have been tempted to change the actual data model of the documentation that was received from the OEM. This can increase costs, in unexpected ways.

Airlines receive a parts catalog and a maintenance manual in SGML/XML format from aircraft manufacturers, structured according to aviation industry standards (the ATA DTDs). Many airlines decide to transform this data structure to simplify their own publishing process, usually with only minor changes.

For example, an aircraft’s printed parts catalog contains a PNR table at the end, listing each part number numerically—similar to an index. This concept exists in the XML data as well and allows for attributes of each part to be listed in one location, instead of repeated throughout the body of the document each time the part is referenced.

When publishing the XML data (whether to paper, or electronically), this structure requires a more complex stylesheet, because the attribute data is often not sitting exactly at the location that it needs to appear. To reduce stylesheet complexity, some airlines may perform a transformation, copying and inserting this attribute content throughout the textual area of the main body (PCDATA inside the tag).

The immediate result seems wonderful: A faster transformation during the publishing process, with a stylesheet that is easier to create. However, the long term consequences far outweigh these benefits.
As I mentioned at the beginning of this post, the airline is also making COCs – changing content in the document according to their own specific needs. An example of a common COC would be if the airline’s engineering team decided to use an alternate part from an approved spare parts manufacturer (but there are many other reasons as well).

Using the PNR example and a modified data model, if an engineer wanted to update a part number s/he must now do so in multiple locations throughout the parts catalog, instead of just once within the PNR index. This is only a minor problem—search and replace can do the trick—but the real headache, and the real cost to the airline, comes as a result of the ongoing cost for managing these COCs.

Every three months, the OEM sends an updated version of the parts catalog. It is the airline’s responsibility to reconcile all the COCs with the new OEM revision, so that all the best-practices knowledge is re-incorporated. The COC comparison can be a massive resource drain on airline engineering teams, sometimes resulting in a six month delay in adopting new data. (Enigma 3C Revision Manager can dramatically reduce the pain of reconciling OEM revisions and COCs, but that doesn’t alleviate the underlying issue.) During this delay, new efficiencies are not being adopted, and in the worst case, regulatory mandates must be tracked and implemented manually.

Sometimes it’s easier for an airline to just generate a new COC. The innocent data transformation that made the publishing process ‘more efficient’ has resulted in many more COCs being required, with the associated review and approval process as well. I’ve seen cases where an airline had eight times as many COCs as a result of this type of modification.

The lesson learned is that data models are very sensitive to change. Often, the original DTDs do not seem to make sense so the temptation to make a simple change can be overwhelming. Airlines need to resist the temptation, as the long-term costs will usually far outweigh the short-term benefits. A second lesson is that airlines should seek publishing platforms that can handle complex DTDs—with strong stylesheet engines—and that include intelligent COC and revision management capabilities.