MRO/ERP vs. CMS/Tech Doc

“The gap in perspectives between MRO/ERP and CMS/Tech Doc in aviation maintenance -Business Process and System”

MRO/IT Singapore, October 26&27 2010Thanos Kaponeridis, President and CEO,

AeroSoft Systems Inc.

Preface

• There are two schools of thought:

– Airframe / Engine OEM ‘will donate your Aviation M&E (MRO) plus Digital Content Management Systems (CMS) ‘Gratis’ as part of your ‘iron’ procurement / loyaltypart of your iron procurement / loyalty strategy….

– The solution will be provided by the Independent Software Vendor industry through integration of the different ‘excellence and competence’ essential to achieve a ‘no bias’ solution (not dependant ( pon a single a/c OEM!)

OEM vs. Airline vs. MRO• OEMs deliver a completed (new) aircraft with a BOM, STC’s, Mod-sums

– Updates with SB’s, AD’s (Effectivity by MSN!)– Issue ‘Revisions’ on TechDoc (AMM, IPC, MPD, MTCM, WDM,SRM….)

• An airline and their requirements for M&E Management– Compliance

• Analysis of SB’s, AD’s and their ‘effectivity to their own fleet configuration!C t t i t– Cost containment

• The illusive goal of trying to meet the “DOC / DMC” per OEM contract!– Procurement (to enable compliance and cost containment)– Availability of A/C for Flight (a variation on ‘cost containment’)Availability of A/C for Flight (a variation on cost containment )

• 3rd party MRO and their M&E System Management (with variations of Airframe, Component, Engine shops etc.)

– Detailed estimation / bidding– Facilities / Capacity Utilization (and planning)– Execution per ‘Package supplied by Airline (with limits, effectivity etc. etc)– 8130 /EASA Form 1 generation

Progress reporting– Progress reporting– Billing / Invoicing

M&E versus CMS• M&E Systems were established long before CMS

– Timeframe 1975-1985– Platforms: IBM Mainframe, IBM Midrange Systems, , g y ,

“Proprietary Minis” (HP, Prime, DG), DEC/VAX !, Unix (“monospace fonts, green/blue screens, ‘fishbowls’/tty’s…)F i li d b i i ll 2000– Functionality and business process: typically 2000-3000 different screens, non-normalized data models / tables.

– Data Model and Process Model “roots” – Financial– Data Model and Process Model roots – Financial Accounting, Inventory Management – certainly not the ATA DataModel and CommonDataDictionary

• Then they added configuration management and regulatory li “MSG3 li t i ft i th ’compliance: “MSG3 compliant aircraft proving they’re

airworthy to their Regulator and following the ‘MPD’ intent of their OEM’s through their AAMP – for FAA FAR Part 121 and EASA Part 145 (lower standards for Charter, General Aviation, Cargo carriers etc.)g )

M&E versus CMS• CMS…

– In this timeframe: “Tech Doc was issued per ATA Spec 100 ‘Paper Manuals (initial B747 in 1970 was fill d ith t f t ittfilled with one set of typewritten documents)

• And it was being authored on mainframeAnd it was being authored on mainframe systems with ‘two pass’ systems imbedding formatting codes and text

Historically• MRO/ERP

– Database / Records / Tables – PARTS – and Inventory– PARTS – and Inventory– Utilization and Limits – Configuration Management (BOM of A/c as ‘maintained)

Financial Information– Financial Information– Complete Maintenance History on all components – Maintenance Production/Execution/Records keeping

Tracking Planning Scheduling Procurement– Tracking, Planning, Scheduling, Procurement• CMS

– Content Management Systems D t M t S t (B f )!– Document Management Systems (Before)!

– Image management systems (Before that!)– They relate to ‘OEM information about ‘Parts, Configuration, Procedures

“AMM IPC (!) MPD (!) MTCM WDM CMM SRM– “AMM, IPC (!), MPD (!), MTCM, WDM, CMM, SRM, ….FCOM/QRH/AFM..….

M&E and TechDOC functional allocation

M&E Documentation Systems come from?• Classic M&E system trying to do “CMS”!

– Job Card Systems” managing M&E Records with references to ATA100 printed manuals….

– Managing printed revisions as ‘parts’…with ‘mods’ (at best!)

– ‘Re-authoring Job Cards within ‘records oriented data structures’!t i i f “SPEC2000” li if ibl– striving for “SPEC2000” compliance – if possible or

desirable!– Linking / ‘pouring’ OEM ‘content’ into the ‘instructions

area of “M&E managed sceleton.

CMS / ‘ t ’ f• CMS s/w ‘roots’ come from– OEMs driven requirements– “Interleaf, Frame’…– SGML, CGM – ATA-100 becoming ATA iSPEC2200

• Rev mgmt, Effectivity Management, “Cross doc links/revision validity”….

– S1000D+– Doc management / Open Systemsg y

• “Not image management”!– So what are they missing?

What is Missing from MRO / ERP• Data Model and Process model is ‘different’ (not ‘wrong’ just different) from CMS• There is a ‘Data Model’ (ATA CSDD ) but it is safe to say NO SYSTEM is

implemented using it!p g• “SPEC 2000” is all about PARTS and what can be ‘done with them• Initially loaded from OEM supplied ‘lists (IPC, MPD, BOM) for ‘new aircraft but

– Must be loaded and maintained from actual ‘as maintained’ aircraft configuration after that!after that!

• RDBMS most suitable ‘engine’ (CMS uses XML DB / OODB)• Client / Server architecture most popular delivery/installed platform• Mostly built with 4GL tools / Client Server implementations using “RDT/Citrix” toMostly built with 4GL tools / Client Server implementations using RDT/Citrix to

extend over Web.– Late entrants: Java, C++, .NET, XML, COBRA, “VM”, “Browser”

• Fundamental design principle : Each Part is unique and can only be used ‘in one place’place

– Systems take ‘pride’ on the “DBA” type single/controlled method of definition of ‘parts’ before they can be used etc. etc.

Basic building blocks of CMS

– “CMS” Repository (Effectivity Management, Revisions management, workflow, revision, structure validation, local g , , , ,content management….)

• Underlying with an XML-DB, OO-db or RDBMS (?) – “Editor”(s) for different data types (SGML/XML, “CGM”…) but

also managing other popular proprietary structures (.DOC, .XML, .PPT, …MSProject, MSACCESS….)

– “Bridge”(s) between ‘editors’ and ‘repository’– “Validation” of DTD/Schema in ‘importing/exporting– “MRU” level editing/re-use (not Page or Document …but Task,

Subtask, Note, Caution/Warning, …..)– Online ‘viewing’/management environment– “Publishing engine(s) for various outputs (“WEB” …- including

mobile technology, “CD/DVD”, PAPER (yes!)…)– “Viewers” for different ‘content types’ – graphics, animation!– Interface / API to “M&E” (the ‘Good Old Parts, A/C config,

limits ‘systems’)

What is Missing from CMS

• It starts from an OEM perspective• “ATA-100 roots”: Documents

– A ‘Feature’ (that’s how mechanics learned to view the aircraft– A ‘Bug’ – Document paradigm fails….

• iSPEC 2000 most prevalent standard (in terms of a/c flying today)– What’s “misunderstood most” about iSPEC 2200?

• NO it is not .PDF (although it has been included in the definition!)• Effectivity Model• Revision ModelRevision Model• IntREF / XREF validation• INTERCHANGE STANDARD NOT AIRLINE INTERNAL CONSUMPTION!

• S1000D will take over (which Revision ?!)• Fundamental concept: Information should be based on a common

‘source’ but re-used (and transformed) from that source as often as it is suitable and must be capable to be ‘augmented’ in a controlled manner

MRO vs CMS in the early days

• MRO M&E systems were too busy trying to keep track of where are the parts, and where is the money (spent)Wh it t d ibi ‘d t il d i t ti ’ f• When it came to describing ‘detailed instructions’ for maintenance the photocopied ‘ATA 100 paper’ was printed in ‘mountains’ – for the job cards in a work packagep g

• Tech Records was full of people just receiving the ‘yellow pages’ (TR’s) and the LEP/TOC updates and filing them in those binders with the ‘Rev Bars’ and

k d h d / f t ( ith t d btmarked up header / footers (without a doubt a complete set for one a/c type was 50 feet along a wall).

• No one ‘imagined’ about ‘data mining’ into all that ‘paper’paper

• Some (futile) efforts in ‘scanning / OCR’ of ATA-100 ‘paper and attempting to use ‘image management solutions’

M&E CMS Myth Busters• “You don’t need a separate Digital Document Management System”

– “We have an add-on” module that’s adequate and freeNo difference between M&E/MRO and “document management” and CMS– No difference between M&E/MRO and document management and CMS

• ATA iSPEC2200 is ‘out of date’ - YOU NEED S1000D compliant Systems• Airline CMS can operate independently of your M&E System

“One soft are package ‘fits all si es/needs’ of airlines M&E or MRO operation”• “One software package ‘fits all sizes/needs’ of airlines M&E or MRO operation”• “Airline M&E and 3rd party MRO / CMS needs are the same”• “We (Airline, MRO, Low-cost Supplier) can build it better / cheaper ‘in-house’”

R l h h l / ‘ t d’ l b t– Real cheap – we have low / ‘outsourced’ labor rates • “We (s/w supplier) don’t need to deal with Revision Management / Data

Conversion• “Single vendor can develop ‘all integrated elements’ from scratch”• Single vendor can develop all integrated elements from scratch• “You need a ‘Large Single Supplier’ to obtain the best M&E/CMS solution”• “All System suppliers have the same cost basis/structure

therefore they all can offer similar pricing”– therefore they all can offer similar pricing

Commercial and Regulatory Requirements

• Regulations demand the same level of M&E (and Tech. Doc) diligence and Airworthiness Compliance from a 3 Aircraft “Startup” operator p p pas they do from a 300 A/C “National Carrier” under FAA Part 121 / EASA 145

The M&E System for both requires the same• The M&E System for both requires the same functionality – (or do they?!)

– Regional Operations, high cycles/landings, multiple-stage t d l tili ti l d ith “ i ht il bilit ”routes and low utilization coupled with “overnight availability”

of aircraft for maintenance provide challenges and opportunities that large carriers do not have!

– Can they afford ‘real time data transmission infrastructure’ for M&E?

– Do they have the infrastructure of a ‘tech. writing department’?

• The “cost / affordability” issue is certainly a y ydifferent matter!

Commercial constraints

• IT/IS spending in Airlines and MRO’s should be around 1.7% - 2.5% of Revenues

– In 2010 this will be much lower due to the currentIn 2010 this will be much lower due to the current economic climate.

• A $5 Billion operation leaves 100Million / yr. totalOf thi 10% ld b f M&E k $10 illi– Of this 10% could be for M&E aka $10million…

– Adequate to implement “fully integrated systems”

• For a $500 million operator this is $10Million still $ p $enough for large systems at $1.0M for M&E –begins getting ‘marginal’ and until recently this is the lowest threshold of the ‘popular systems’

• For a $50-100Million ‘Startup’ – not enough funds to run an RFP process – never mind procuring and implementing a system!

…Major vs. Regional….• Yet M&E can be as complex or more at Regional / Tier

2&3:

– 1500 Flight Logs / day vs.100-200 Flight logs for the ‘major’ –small national carrier

– 300 ‘a/c’ to schedule/reschedule (with associated crews, maintenance …

– 15,000 rotables tracked (assuming homogeneous fleet!) vs. 3000-4000 for the ‘major – this ‘explodes’ with different j pOEM/fleet types…

– 20 minutes turn around at gate vs. 2 hours– Landing gear / APU ‘utilization’: High cycles, ‘low utilization’!– Essential to utilize ‘over-night window’ for phased

maintenance!

• At least in the NA/Western Europe …in Cargo, GA and the Developing World they do fly at 3 a.m.!

– Real-time ACARS messaging does not yield practical results for a 1 hour stage-flight

– Cannot ferry a 1-2hour ‘stage length’ aircraft to “Low Cost MRO’s / Regions across the globe for labo r cost red ctions!MRO’s / Regions across the globe for labour cost reductions!

So the ‘Systems that manage the Regional’s M&E has to be at least as ‘robust’ as the one for the “Major” and has to provide real ROI!has to provide real ROI!

“No need for separate Document Management System”

• Content Management at MRU of digital data is not ‘Document Management’

• Document ManagementDocument Management– 20,000 page, 5000 illustration “MSWord document” vs. “Digital Content /

Minimum Revisable Unit” management!• Oh yes... ‘those darn graphics’…(CGM, SVG,…?)y g p ( )• “Lets convert everything into PDF”!• “Let’s scan all your paper and keep the images ‘indexed’”• “SGML iSPEC2200 DTD’s are simple to convert to schema based p

XML”• “Boeing and Airbus digital data (and Bombardier and Embraer!) are all

the same”• “We can ‘do it all’ with a couple of developers”• Even Oracle and SAP bring digital content / document

management partners to the table – and it’s not SharePoint!

One software ‘fits all sizes/needs’• If M&E software is highly complex and (claimed-

to-be all encompassing) then it is too expensive to license and implement across the board !

– Suppliers will offer ‘a handful of modules’ to pass the Procurement Budget ‘bar’, then as the system appears ‘non-workable’ due to missing ‘modules’ the vendor will keep offering/adding them until the price p g g pand complexity goes again beyond the original plan!

• “Military s/w implementation background can solve commercial/civil aviation” (the implication i th t j t h t ‘d b d this that you just have to ‘dumb-down the system’!)

– Costs/Price points, Complexity, Regulations, ‘Large project expectations’, Business Process variance….

• Managers recommending ‘too expensive and incomplete systems which overrun budgets and take forever to implement will never admit to it’: These are career limiting confessions!These are career limiting confessions!

M&E + CMS

• The correct solution is not “M&E/MRO” system with some ‘documentation capabilities’with some documentation capabilities

– Or

• CMS with ‘some M&E database information”

– Instead

• BOTH M&E and CMS need to co-exist

– They’re not ‘competitive’ they’re complementary– They must be INTEGRATED!y

(1) Revision load process. This first part

(2) Revision load –impact analysis. This second step helps the user to make proper actions on what to load

CMS Steps

DigiDOC working repository area

loads the data into the repository and produces applicable reports which can be manually used but also used the impact /boeing/boeing/757/MPD/MI structure

actions on what to load and also to resolve potential conflicts.

43

Data organized and aligned with the data in the working repository area:

revloads/boeing/boeing/757/MPD/rev21-MI structure

analysis tool.

revloads/boeing/boeing/757/MPD/rev21-MI structure

/boeing/locals/757/MPD/MI structure3

Original OEM data converted to an interim quasi XML

The second step is to align data so it looks like format and structure within the working repository area. In this way it becomes possible to the revision loader to make the load as well as making the impact analysis, so the user can resolve conflicts if any.

2Original OEM data converted to an interim quasi XML structure including binaries like gfx, pdf, word, etc.

XML-originals/boeing/boeing/757/MPD/rev22.xml

The first step in the loading process is just to

Original OEM data as received. Examples are:

originals/boeing/boeing/757/

The first step in the loading process is just to convert things into a format which is applicable to the format of the same data within the working repository. In most cases it means data is moved into an XML structure potentially including some binaries like Word, JPG, etc.

1originals/boeing/boeing/757/MPD/rev22-MS-EXCEL

originals/boeing/boeing/757/TC/rev11-PDF

“ROI”

• Calculated ‘Total Cost of Ownership’ invested and then ROI in terms of ‘Total Expected savings’

• Riddles we frequently encounter:– Extend the period for ROI!– “Hide true costs” – which include ‘learning period’ after training

E l d th d t i / l t– Exclude the data conversion / clean up costs– Exclude the interfaces to all other systems the legacy system was

interfaced with (Finance, Flight Ops, Logistics, other in-house systems)– Rarely include in-house resource needs in using and supporting costsRarely include in house resource needs in using and supporting costs

for the application– Hardly ever ‘baseline’ the BEFORE and AFTER picture openly

• We have accepted the metric where is ‘X’ is software license TCO ends up at around 8-10X when ‘all internal/external costs’ are calculated over 5 years!

……more Design Choices• REGULATORY CONSTRAINTS:

– Digital Signature Standards (Sign-off, authentication)“Non Revisable Digital Document” Standards ( PDF vs XML)– Non Revisable Digital Document Standards (.PDF vs XML)

– “Prove OEM data is same as data in ‘your system’– Prove ‘version used’ is the most current / effective / applicable

Ho ‘real time’ is the ‘as maintained stat s of a/c s hat is in s stem?– How ‘real time’ is the ‘as maintained status of a/c vs. what is in system?• e-Business (and associated ‘docs’):

– ProcurementR i– Repair

• All subject to MSG3 compliant aircraft / maintenance programs?– If “A” and “C” check and ‘Hard-times’ programs are the basis of

Regulatory Compliance and OEM MPD/MRM/MPM we can’t get ROIRegulatory Compliance and OEM MPD/MRM/MPM, we can t get ROI on contemporary solutions and Proactive Health Monitoring / Maintenance Systems….!

Data Conversion/Validation: who’s job is it?

• The one point we (the IS suppliers) agree: Data Conversion is the costliest / riskiest part of an implementation

• Yet, many (M&E / MRO) suppliers don’t ‘price it’ or ‘assume it’ …..• The only way to have a ‘new system’ accepted in Production is to

prove that it manages ‘clean / correct data’ (even if you have to fix the previous-legacy system’s errors!).

• Do you think because “Boeing or Airbus” have sent you an SGML instance tape that the ‘data is correct or perfect’?!

• CMS leaves vendors no choice: YOU HAVE to convert incoming iSPEC2200 ‘interchange’ format to local/airline re-usable/deployable formats and validate all along – As often as every 30 days for TR’s and EVERY 90 days for full revisions for each doc type and each aircraft type….!

All System suppliers have same cost basis

• … therefore can offer similar pricing

• 100 man-years development of ‘one system’ has a cost base of $10Million – this must be recovered in a reasonably short period to meet investor demands and liquidity

• You can ‘beg borrow or steal IP’ and copy / re implement with• You can beg, borrow or steal IP and copy / re-implement with newer tools…’!

• You can ‘promise to write the software/solution at real cheap (outsourced) rates specific for that airline(outsourced) rates specific for that airline

OR

• You can legitimately purchase and license IP / technology (at opportune times) and continue improving, integrating and advancing

AeroSoft’s Integrated Solution

Financial

Onboard devices linking to data

bus and transmitting to

ground

Flight Operation S t

System

AeroBUY

System

Line Maintenance

DigiPLAN

DigiMAINTor

WinPMI / WebPMI

DigiDOC

DJMData

Data

DigiDOC™Engineering Services Line Maintenance

Engineering ServicesProductionCustomersData loaded

from OEM

IE GUI

from OEM

Data loaded Synchronization

Authors Browser

CD ROM

Web Browser

Data loaded from customers

SynchronizationScan Module

CD ROM Module

Data loaded -other

M&E System

DigiDOC Server

Online IETM and paperOnline IETM and paper

DigiDOC™ Document FlowView Official documents - Only

Boeing, Airbus, Bombardier, etc

AMM, IPC, MPD, SB, TR’s

P bli h f di t ib ti

OfficialJob Cards and documents for Production / Line / Workshop

Airline In-house Documents

Supplements

Publish for distribution

Supplements

Airline In-house Library

Information

M&E System Link to M&E System

Manage, Review

Authored y Link to M&E SystemDocuments

DigiDOC™ Customer Originated Changes

Click Button t t t L lto start Local

Edit

DigiDOC™ Operator Maintenance Requirements

MS Load

MR Revision Management

Maintenance Requirements

Create # Gen Maintenance ProgramsMS Load

CollisionAnalysis

Create

V lid t

Update

# Gen

A

View

Maintenance Programs

Validation

Validate

Archive Export

Approve

Regulators…

OEM MPD

Rev n <XML>

OEM OEM MPD

Rev 2 MS Excel

Planning / Job Card A li ti

OEMMPD

Rev 1

Applications

DigiDOC™ Review, workflow of MPD changesAuthoring Area: MPD classificationFolders below are virtual folders, which gather MPD items based upon different cirterias. The user has in this example clicked the ”REV – unclassified” folder, which then is presented in the right frame.

This MPD is a newly loaded ITEM from the OEM. The changes are high lighted so it becomes easier for the user to classify the ITEM. The classifications in this case are named APPL (Major and N/A (minor) The ”pink” bar in the official

This button shows a preview of all data within the ITEM, see next page..

N/A (minor). The pink bar in the official version indicated that the previous version was classified as APPL.

DigiDOC™ Mod Status integration with M&E

DigiDOC™ API Link from M&E System

• Integrating with the Mod Status in M&E System

DigiDOC™ Interactive Viewer

DigiDOC™ Multimedia support• We have plug-ins supporting formats that cannot be natively rendered by a

browser – like “IsoView “

Thank you very much!

• WWW.AEROSOFT.AERO

• WWW.AEROSOFTSYS.COM