Nobody wants to do it, but most airlines will probably have to adopt new maintenance information systems eventually. Challenges abound. Fortunately so do choices, one of the most important of which is whether to go for a Big Bang or a phase-in approach. If the phased approach is selected, should it be by fleet or by function? Which functions should go first?
Experts differ on these answers. Much depends on circumstance, size, tradeoffs between cost and risk and whether an enterprise resource planning (ERP) or best-of-breed maintenance application is being installed.
Fabiano Faccoli, Swiss AviationSoftware's VP for customer services, recommends a standard Big Bang implementation. It applies whether there are five or 5,000 users. “If you phase it in, time and cost can explode,” Faccoli says. “There is more risk and it can fail.” All customers install core functions, with a few non-core functions optional.
Swiss AviationSofware's AMOS first reviews existing processes. This knowledge-transfer phase takes 2-3 months, explains Thomas Schulz, senior manager business consulting. Total implementation time varies by airline type. Small carriers with no heavy maintenance can be up-and-running in 3-6 months. Larger, more complex airlines take 6-18 months.
Data migration effort depends on size, age and complexity of the fleet and requires anywhere from one to 20 full-time staff. “The big challenge is getting clean data out of the old system, not getting it into the new system,” Schulz says. “They can get help from outside companies, but they must validate it themselves.”
The most common implementation mistake is underestimating data migration. “They should start on day one on data transfer,” Schulz says. AMOS obliges clients to complete three cycles of data transfer before going live. “The first will have some errors, but they can start training people after it.” Transfers should be run in real time because they will stretch hardware.
The second biggest mistake is underestimating change management. Average customers must assign three to five people to the project, plus key users in all departments affected by implementation. AMOS offers a six-hour eLearning module for light users, mechanics and storeroom staff. Training of back-office heavy users takes 3-6 days. Phasing in a complete ERP by fleet type is hard because the same mechanics work on different models, notes Hannes Sandmeier, VP applications development at Oracle. “You must train for different systems and must build temporary integrations between the new and old applications. These are costly and time consuming.”
Oracle phases-in by function, starting with financial, human resource and supply-chain management. “You get a huge return, then you do maintenance and engineering functions,” Sandmeier says. Modules that belong together must be kept together.
Finance, human resources and supply-chain modules can be installed in as little as six months, but supply-chain modules require data cleansing, which is the big hump in most implementations.
Airlines usually start implementing Oracle cMRO with finance modules—accounts receivable and payable, the general ledge and fixed asset records—to gain confidence and experience and then move to more difficult M&E functions. Total implementation takes from 2-4 years. A common mistake is failure to embed aircraft and engine manuals in the new system, so mechanics still have to walk back to the technical library.
“Big bang is the shortest, least costly but risky,” summarizes Evan Butler-Jones, Mxi Technology's product marketing manager. “It also requires the most people diverted from operations to the project at one time.” Phased implementations are less risky, take longer, may produce early benefits and divert fewer people.
Mxi phased in Maintenix by fleet type with. Over the first eight months most functions were implemented for new , for which no data cleaning was needed. The next three months were spent adding remaining functions and covering Dash-8- . Ethiopian is now extending Maintenix to the other 33 Boeing aircraft in its mixed fleet. “They proved success on 777s to the rest of the organization, mechanics and the board of directors,” Butler Jones says. “They showed quick wins.”
Implementation can be phased by function, starting with maintenance management (what has to be done), configuration management (what can be done), and record management (proving it is done it right). “With that and data cleaning done, you can show compliance, but you did not have to train large volumes of people,” the Mxi marketer explains. “Then you can push into planning, execution and material management where you will have to train many people.”
Phasing may mix fleet type and function. New applications must integrate with back-end ERPs. That complexity depends to some degree on how warehouses are organized, but sometimes operational changes can substitute for technology fixes for a while. “There may be multiple systems and duplicate costs,” Butler-Jones acknowledges. “You must trade these off against gains from phasing it in.” Most Mxi customers choose phases, but Lan Airlines did a Big Bang for its 130 aircraft.
The First Modules
Smaller airlines with one legacy system usually go with Big Bang, while larger airlines with many older applications go with phases, says Lidia Escobar, director of data migration and implementation at Trax.
Some Trax customers start data transfer with static files like employee training, quality assurance and manual libraries. “They bring that data in first and stand up the modules that use it first,” Escobar says.
The toughest data to clean is maintenance requirements, checks, service bulletins and airworthiness directives required for the engineering module. So both these data and relevant modules may come later.
Rich Bergmann, senior executivfor supply chain management at Accenture, proposes another phasing scheme. “Start with inventory-management and part-availability systems, get material systems right first. These offer the best business case. And if you try other modules and these are not ready, it will shut down.”
Next, automate work cards to save mechanics' time. “You should make all documents and technical diagrams electronic and centralized,” Bergmann says. Then extend the supply chain so managers know where they can have access to parts without overstocking them. “You want to get visibility into your supply chain instead of paying big dollars to hold parts.”
Bergmann would finish with payroll, time and material and job certification functions. “After that you can bring in electronic signatures to work cards.”
The Accenture consultant says temporary interfaces are a challenge with legacy systems, but not with new, Web-enabled applications like Trax and Mxi. “They are well–architected.”
Sharhabeel Lone, partner for global business strategy at SAKS Consulting, says phasing in ERP both costs more and is riskier due to the many interfaces to legacy systems that were written in old languages. “Board members think phased is lower risk, so tell them you will examine that in planning, and then you make the case for Big Bang,” he says.
In most cases, phasing in best-of-breed costs more but reduces risks, because “you can always go back to the old system,” Lone says. But he judges Big Bang the most cost-effective approach even here. Either way, “You must manage the board's expectations. Tell them up front that it will not be as good as your old systems in some ways at first. It's a bitter pill you need to build for the future,” says Lone.
Oliver Wyman Partner Peter Feldman says it is essential to have subject matter experts for all areas covered by the new system participate. “Make sure the business runs the software, not the other way around.” He recommends setting up two separate groups, one to lean out business processes and the other to implement the new software. “Both should stand on their own as improvements. Combining them should produce exceptional value.”
Fred Klapetzky with Marsh McLennan advises keeping cross-referencing tools synchronized throughout implementation. Exception reports may have two numbers assigned to them and strict review must ensure they are correct. He also stresses three other precautions: a disaster recovery plan if hardware goes down; a business continuity plan if software fails; and running both old and new processes in parallel before cutover.