CMS has been an afterthought to MRO system selection, until now:  Thanos Kaponeridis, President and CEO at AeroSoft Systems outlines a vendor’s perspective on an increasingly important issue.

In short, the simple reason behind the title claim could be ‘Because MRO/IT Systems are complex’. But, as is often the case, there is much more to it than that.

Historical perspective

Looking back, in 1997 I was among the true believers in the value of Digital Documents and Standards and the benefits they would bring to airlines. For me, this belief was based on a major involvement with an original equipment manufacturer (OEM) and the launch of their new aircraft programs. However, the stark reality was very different. Through involvement in the ATA/EMMC/TICC (the Air Transport Association and its executive levels) standards process I observed the following trends during the period 1994-2000:

• Some Tier-1 carriers (including airframe and engine OEMs) who, as early adopters of Standard Generalized Markup Language (SGML) technology and early versions of SPEC2100 (what the ATA standard was then called) had spent tens of  millions of dollars, yet achieved less benefits and poorer results than they had expected;
• The elimination of paper alone was not enough;
• Tier-2 and 3 carriers considered as digital data, anything that they could see through the proprietary viewers made available by the OEM. (Maxwell Data Systems, Interleaf/Worldview and other names long departed from the market).

When we made our first round of marketing/sales visits in 1997 and presented demonstrations of prototype systems that automatically generated Job Cards by linking the maintenance planning document (MPD) with the aircraft maintenance manual (AMM) aircraft maintenance and task oriented support system (AMTOSS) coded tasks and delivered them over the Internet, the airlines said that they were highly impressed but believed they needed one integrated system that does ‘everything’.  At that time, the airline industry, especially at the Tier-2 and 3 levels (both in North America and Europe), had a limited understanding of digital documents and their capabilities. They always equated them with the CD ROM and proprietary viewer based systems with very limited features and availability, and confined only to some of their aircraft models or engine OEMs, which they received from their suppliers.

MRO IT; managing Job Cards in 1980-2000 era

Most of these airlines had home-grown and highly convoluted and inefficient means of authoring and linking job cards with their 1^st or 2^nd generation MRO systems and printing them on paper tomes for production control and sign-off on their execution and completion. They dreaded the fact that MPD changes and AMM and illustrated parts catalog (IPC) changes produced huge additional workloads, and generated time delays for revisions and updates – a situation that led, in some cases, to issues of non-compliance and stiff fines. Ironically, while content was authored as ‘reusable’ at the OEMs, according to SPEC2100 and later iSPEC2200, its distribution and delivery to the airlines was done on paper and on CD-ROM with limited or proprietary capabilities. Temporary Revisions (TR) were managed relative to a CD-ROM that contained the previous revision. Those were the days of continued stuffing of the TR yellow pages into the tomes of white pages, in the airlines’ technical libraries.

As a business, we suspended digital document development in favor of getting into the MRO solution space. We acquired other systems and their intellectual property (IP), with a wealth of proven business logic, and embarked on migrating them technologically to contemporary tools and platforms while enhancing them to match the best and latest industry practices. We added electronic document libraries and links to CD’s/directories of OEM content etc. and local job card editing, like other Best of Breed MRO IT systems.

Where did MRO Best of Breed come from?

If you were to examine the history of the development of MRO systems, you would find that often they were built not by software scientists but by individuals who learned on the job (mechanics who learned programming on a PC or self-taught programmers who started writing small business applications on an IBM System 34/36). They did not have in-depth information technology and systems credentials or methodology knowhow, but especially, they lacked comprehensive knowledge across the full domain of aviation. They had some limited finance, accounting and  inventory management background and, yes, some were ex-mechanics focusing on individual features and the ease of use for their customers. Their approach was inadequate and, as a result, many applications were developed around a financial or inventory management core.

These self-styled developers would model and create an additional function, as per the customer’s request, and then, when another similar request was received, they would copy, rename and make another table similar but wider, without any further considerations. In the process they sidestepped all the basic requirements of 3^rd level Normal Form Data Models creating data redundancy and violating referential integrity. Subsequently, some of them started using application generators to re-write their next generation systems but the overall fractured approach was unable to accommodate an integrated parts-oriented MRO and a full digital document content management system (CMS). As readers will know, application generators can be used to build good and bad systems. If the data and process models are poorly designed, not normalized or simply incomplete, things won’t get any better by switching to Oracle, Unix, WebServices, etc. In all fairness, a true ATA iSPEC2000 Data Model had not been completed or validated seriously at this time.

This conclusion is not anecdotal but based on a direct knowledge not only of applications but also relative to all their associated derivatives in the market which were built by developers who left companies then subsequently, and very rapidly, managed to create their own new MRO software solutions.

Data Model discipline was truly lacking in all of those Generation 2 Best of Breed (BoB) applications. In fact, some Generation 1 mainframe systems had better structures than the emerging minicomputer-based BoB systems. To restate, the derivatives’ data models were as good (or poor) as the previous system the developers were copying. Technical Documentation  (ATA100 Tech Doc) meant 100 tons of paper, huge libraries and distribution systems, and attempting to synchronize the yellow TR’s with incoming revisions whilst ensuring that the AMM, illustrated parts catalog (IPC), Task Cards, wiring diagram manual (WDM), and the rest (the MPD in particular) were for the same configuration or version of the aircraft! (in other words, synchronizing the OEM’s as-delivered aircraft effectiveness with what the airline had implemented in the current as-maintained aircraft status).

ERP enters MRO IT

True enterprise resource planning systems (ERP) first emerged around an enterprise’s horizontal business application areas (finance, human resources, inventory, discreet process control, continuous process control) but they were not engineered or architecturally designed around the aircraft and maintenance process data models in a commercial aviation environment. The most prominent ERP tools and applications allow(ed) users to build the application on the basis of the documents that were currently being circulated within the enterprise; purchase order (PO), repair order (RO), Invoice, Bill of Lading etc. If users wished to customize the application, that could be achieved but at great expense and by being forced to change the fundamental data model and data types. This, in turn, led to the enormous projects and more so to the even bigger migration costs when the ERP engine was upgraded by its vendor from one generation (of database and technology) to the next. All in all, it made name brand-ERP a four letter word in some circles while contributing to the wealth (and occasional demise through legal suits) of the big seven global consulting and accounting firms.

Highest risk in MRO: Data Conversion / Initial Data Load

One more critical factor emerging from MRO implementations is the process of initial data load. All Best of Breed MRO system vendors will attest to this. The initial data load/clean up and verification is the costliest and riskiest part of any project. After that point, data gets introduced in small increments through the keyboard or through direct interfaces with Flight Ops or Finance Systems as new parts, aircraft or individual service bulletins (SB) and airworthiness directives (AD) continue to arrive.

The reason why MRO systems are challenged in initial data load is that there is no standard input format or structure against which they can be compared. They all provide their own, preferred, Excel spread sheets with the required data elements that can be populated using tailored programs or through direct manual entry, after which the spread sheets are imported into the MRO system. In cases where aircraft move for long periods in or out of the system – for example when being leased for six months to another operator with a dissimilar system, and then returned to the owner airline on an annual basis – the challenge of updating the complete and accurate history in central records and times – time since new (TSN), time since repaired (TSR), time since overhaul (TSO) is something the Best of Breed have not yet conquered. As a means to avoid this challenge, the recommendation that ‘the lessee should use the same system as the lessor’ is not always feasible or practical.

In contrast with MRO system landscape, true aviation CMS Systems must be designed and built so that repeated and frequent imports of large volumes of data (OEM revisions) can be made and automatically validated, before they are put in the workflow for any post processing. They must accommodate a wide range of data types – from very well structured and granular to unstructured, as well as scanned content with mixed typed and handwritten information. This is one critical design difference between classical MRO IT and CMS.

Many software vendors would like to draw your attention to Technology Standards which were and are of the least concern while they will continue to evolve. Their references to Mainframe, Mini/terminals, Client Servers, Three-tier Application Servers/ DB Servers, WebServers and WebBrowsers are all essential and sound complex. For example, when they talk about WebBrowser, do they mean remote desk top (RDT), native http screen on Internet Explorer or deployment on ‘any Java device’?

Yet MRO system vendors continue to strive for the next generation of technology standards without addressing the inherent functional deficiencies and data model flaws in their existing systems. They’d prefer to move from Mini-computer implementations to Client Servers then perpetuating Citrix accelerator delivery until they could create their native WebServer/WebBrowser Java versions, presumably hoping that this would mask all of their problems.

History of standards guiding MRO

The standards available today were incomplete and, in some case, were even undefined 15 years ago, when the roots of the current MRO systems were being developed. Three of these are worth mentioning:

1. SPEC2000: it’s been around a while from its ATA 200 roots but the XML dimension was not added until XML became prominent in the late 1990’s.
2. iSPEC2200 with the Common Source Data Dictionary (CSDD) and DataModel, SPEC2300, S1000D Rev 4 (Released 13 September 2008). In its evolution SPEC2100 took its reference from continuous acquisition and life-cycle support (CALS) and their adoption of SGML in their MIL-SPECS and their interactive electronic technical manual (IETM).
3. The Initial XML Draft was first published in November 1996 (but its value was largely confined to a relatively small group of people who did understand SGML). The World Wide Web Consortium (W3C) recommendation for digital content came out in October 1998 and XSTL, XQUERY and XPATH standards did not mature until 2001. In reality, true XML database engines were not available until 2002-2003. The following links provide important background information as to how the current standards evolved over time.

http://www.w3.org/XML/hist2002

http://www.totalxml.net/sources-versions.php

Then there are application and inter-process standards like Common Object Request Broker Architecture (CORBA 3.0), Simple Object Access Protocol (SOAP), Open Document Architecture (ODA), Service Oriented Architecture (SOA) and others which matured between 2001 and 2005.

The Paradox of ‘Traditional Best of Breed MRO Systems can do CMS’

The question is, how was it possible for the MRO  applications, initially built in the 1985-1990 period and then repurposed and rebuilt ten years later, to be capable of utilizing these standards (which are basic essential building blocks within a true CMS), in their core process and data models? And what did the enterprising owners and developers of these MRO/IT systems do when digital documents became the buzz? Quite simply, they unabashedly issued statements saying that, ‘We have it’, ‘We are adding it to our system’, ‘A dedicated CMS is not needed’, ‘We will release it in three months’, etc.

The only credible position adopted is that of major brand ERP based MRO Systems which have made project specific or other longer term and formal agreements with CMS systems providers and are undertaking major integrated implementations.

Yes, most BoB did add functionality for editing job cards (aka allowing the editing of database records in the MRO application and attaching PDF content from well-known locations/directories where OEM content CD/DVD’s were installed or copied). And this was better than nothing but it was not Digital Content Management. In part this is because the relational databases (RDBMS) which lie beneath all MRO systems can only manage text and graphics as binary large objects (BLOBs) within their record structure.

The roots of CMS Standards in Commercial Aviation

The pioneers of Digital Document System implementations (content management systems) were the aircraft and engine OEMs. Actually, before even that the CALS-US Defense OEM initiatives drove earlier implementations on standardizing on SGML. These early iterations of OEM systems were based on technical authoring tools like Interleaf, Framemaker and relational data base management system (RDBMS). Object oriented databases were not available or mature in the late 1980’s. However, since these systems had large investments in design, data modeling and architecture they implicitly incorporated the constructs of ATA-100/AMTOSS and were able to establish the concepts of minimum revisable units.

Subsequently these OEMs spent hundreds of millions of dollars migrating their 1^st generation document management systems and implementing in SGML, CGM, repository-based authoring, publishing, revision and configuration management systems; from which they initially were sending to their customers printed paper (and still do in some cases) whilst the iSPEC2200 took a very long and circuitous path in maturing to its final ‘as good as it gets’ version, considering the deficiencies of the Document Type Definitions (DTDs). Boeing specifically demanded the inclusion of ‘.PDF’ as part of the iSPEC2200 Standard and, consequently, masses of .PDF started being given out free (it was cheaper for an OEM to burn DVD with PDFs than print and ship).

When ATA SPEC2100 (the predecessor of iSPEC2200) started taking shape, OEM systems were migrated to SGML authoring, CGM graphics and, in many cases, were still managed within RDBMS. With the introduction of XML in 1997, and the subsequent maturity of object oriented databases, the industry embarked on a migration to XML DB, XML editing and XML schema, rather than document type definition (DTD). However, their published digital data services remained based on iSPEC2200 SGML DTD’s. After several years, in 2004, the ATA finally embraced the Association Europeene des Constructeurs de Materiel Aerospatial (AECMA) standard S1000D based on the Common Source Data Base (CSDB).

I cringe when I hear prominent marketing people in the CMS domain making statements like “S1000D is the collection of the iSPEC2200 DTD’s”. In reality S1000D is a lot more than just XML and Schema based definitions. It is based on Product Management Data Base (PMDB) and product-build configuration at the OEM – which in the S1000D parlance has become the Common Source Data Base (CSDB). It is important to recognize that S1000D is also an evolving interchange standard (just like iSPEC2200) and is not necessarily the optimal internal database schema for an airline’s or MRO’s internal reuse of digital documents. In fact it is mathematically / algorithmically impossible to convert iSPEC2200 to S1000D – without direct manual subject matter expert (SME) intervention. Also, one needs to appreciate that while the database characteristics of S1000D are very valuable, the mechanics for the next 20 plus years will expect to see page blocks of AMM, IPC, Task Cards and, so on, to perform their work. This means extensive XSL transformations (XSLT- the transformation language of XML to other formats) will be required to create viewable and usable information.

And last, but not least, there are no commercial aircraft flying in service in 2011 with technical content developed based on S1000D. The first few will be the B787s, A350s and the C-Series. The major OEM’s have categorically stated that they will continue with their aircraft in service according to the standards which were in place when they were launched – aka iSPEC2200 – for the lifetime of those aircraft. Consequently, a CMS has to be capable of accepting/importing content which will be iSPEC2200, .PDF, S1000D, images, and other de-facto enterprise content (MS-Office documents) and dealing with each according to the structure and intelligence it affords. Again, this can hardly be the add-on capability the MRO system BoBs are marketing.

As with early ERP implementations, where tens of millions of dollars were spent and, in some cases, vendors and implementers were sued and lost, the experience was also grim in the early major CMS system implementations during the nineties resulting in very large, experimental, ‘built at the customer environment’, one-off solutions. Just ask airlines like United or Delta, or OEM’s like Boeing, Pratt & Whitney and Bombardier, to share their early SGML systems implementations experience.

Stage enter: XML

What changed the landscape was the introduction in 2004/05 of XML, XML DB, XSLT, XPATH, Xquery, Java products, Web Services 2.0. This has allowed previously custom built solutions to be reproduced at levels of reliable implementation but at much lower price points. Yet the painful issue of integration with MRO IT was still not fully addressed as illustrated in recent years where a major Pacific Rim carrier invested over $100 million in customization for such an integrated solution.

The MRO systems had created, as much as possible, within their data and processes, the ability to take Compliance while managing Job Cards, Maintenance Programs and Work Packages. However, when mature CMS came along and provided the vehicle for dealing with continuously updated OEM input with each revision and process it quickly and correctly, the MRO systems had to re-assess their boundaries and where the Change Authority should belong for such core data.

For example, an IPC is a great source of data load to a parts master. An MPD management tool with controls and audit trails and revision to revision change impact analysis is another great feature that can reduce engineering workload and elapsed time to compliance in recreating the airlines approved maintenance program.

But here is an anachronism. Today, in the pure MRO business there is essential dependence on component maintenance manual(CMM) illustrated parts lists (IPLs) produced by the 15,000 plus component suppliers. Only a handful of these have migrated to standards-based digital data offerings and most of them still supply .PDF or MS Word documents. So a CMS system must indeed accommodate these significant data types. Another anachronism exists in the world of Business Aircraft which is somewhat stuck back in the 1990’s and bound to the proprietary viewer based CD-ROMs as a source of digital content data.

Advantages of CMS over MRO/IT ‘bundled document management’

1. XML and CGM editing tools supporting both DTD and Schema, and associated validation.
2. Job Card Editor (XML) linked with digital MPD, AMM – not a cut and paste paradigm but rather a reference anchor based solution.
3. Management of revisions from OEM, official revisions at the airline.
4. Anchor Management.
5. Minimum revisable unit management.
6. Customer originated changes.
7. Temporary revisions surviving against full revisions – if necessary.
8.  Attaching SB’s / AD’s.
9. Resolving effectiveness for tail-MSN and SB’s against published content.

10. Ability from a single collection to generate subset of views and intentionally offer different revisions of manuals to different end users / consumers.

11. Audit trail for all changes and revisions.

12. Audit trail: the ability at any point to be able to produce any previous revision and ensure authenticity and change authority.

13. Publish content to the Web but also to media, to portable and mobile communicating devices like electronic flight bag (EFB), iPAD, etc. (ensuring management of revisions).

14. Effective architecture that supports databases’ multi-TeraBytes of data.

15. Deals effectively with .PDF and with scanned image documents from originals.

16. Web 2.0, W3C and IT Standards compliance such as SOAP, SOA, CORBA.

17. Industry standards compliance (and continuous validation) for iSPEC2200, S1000D (in all its revisions).

Factors contributing to CMS gaining front row and center in MRO IT

Why is it that in 2011, there is such a lively interest, from global participants in airline operations and MRO, in CMS with it no longer being considered an afterthought to MRO IT implementations?

1. The growth in the airline industry is being driven by far eastern and developing economies, which have not been caught up with the European/North American financial crisis. Developing economies have younger populations with access to better jobs and economic futures, essential elements for sustained growth in airlines.
2. Regulators have increased the number of non-compliance fines or have threatened to do so to airlines and MRO’s which could not prove that the documentation they used was the most current and effective relative to the configuration of the aircraft they were flying.
3. Price, performance and variety. The domain of XML and associated tools is truly mature and there is a wide choice in products and expertise available. While most product and consulting services are based from North America and Europe, it should not be underestimated that some key expertise is now available at outsourced major services providers at rates 25%-50% of typical North American/European expert rates. As CMS and MRO system integration is often resource intensive, this will have a key impact in the market.
4. Some key integration projects between major pure MRO IT and pure CMS have been successfully announced and completed.
5. Following airline consolidations, new managements have discovered decades of legacy systems that are inappropriate and inadequate for their newly defined integrated needs and they’re willing to invest to achieve the full benefits of their corporate consolidation through rationalization and replacement of their IT systems.
6. The claims of pure MRO system BoB vendors have been proven to be insufficient for the airline industry’s complete CMS needs and, in some cases, some of their technology / expertise partners are no longer viable concerns.
7. The integration points and interfaces have been well defined and proven between major ERP and CMS and, in some cases, between Best of Breed and CMS. They have been understood and proven and some traditionally cumbersome processes within MRO systems are now being delivered more effectively by CMS.

If you want to be in full compliance and have the benefits of integration between your MRO system (Best of Breed or ERP) and a Digital Content Management System (CMS) you have to engage with products and vendors that offer commercial aviation MRO/CMS expertise and products, and have proven their ability to achieve such integration.

Why do we need both MRO IT and CMS in commercial aviation?

Here are some classic examples why both CMS and MRO systems are essential to prove compliance:

1. Effectivity resolution between CMS and MRO system. Digital Content (AMM, IPC, MPD) have effectivity breaks by tail-MSN and by SB (pre- and post-modification). Effectiveness resolution must be performed by the CMS software so that the mechanic or the planner can be shown the most effective tasks to complete or parts needed to obtain for the problem at hand. However, the true effectivity is known only by the MRO system as it records where the effective components/rotables are really installed, as opposed to the manufacturer serial number (MSN) they were attached originally at the OEM factory. Also, the MRO system knows which SB has been applied to which tail by which date. So this information needs to be passed back to the CMS for it to selectively display the valid information through the Interactive Electronic Technical Manual (IETM) viewer. I am unaware of any Best of Breed MRO system which performs this task on its own.
2. How, for compliance purposes, is it possible to link and imbed your temporary revisions and your incoming SBs to the requisite AMM page blocks or IPC figures, without a full scale CMS? The short answer is that it’s not possible.
3. Similarly, how do you introduce the correct Job Card content by linking the MPD line items to the requisite AMM tasks and then passing them to the Work Package which is scheduled for Production by your MRO system, without a full scale CMS?
4. How do you attach link the 8130/EASA Form1 to a serviced component?
5. Where do you record the completion of an SB/AD or a Job Card? And, how do you keep the permanent record – with some tasks and sub-tasks requiring two signatures (mechanic and inspector) and some requiring three?

But I feel that I must really stop here, before some readers start arguing that CMS and MRO Systems are overly complex!