Aviation MRO IT: What's in your solution blueprint?

When new systems replace legacy applications, they often bring their own issues. Data integrity, low adoption, and decreased staff productivity are common complaints. Maintenance, repair, and overhaul (MRO) technology is no exception—as systems evolve, we find fresh challenges to overcome.

The central premise of the solution blueprint is design. At its core, the blueprint solves known problems and plots the course for next steps towards solutions for those to come.

During and after implementation, how effectively does your organization solve known issues? Does your team instead get immersed in learning all about the new system? How much of this is to seek solutions versus expanding knowledge of the software? If you’re operating in more of a software learning mode than a business solution mode, potential problems can fall through the cracks.

Further, the blueprint is a living and dynamic charter that defines organizational and system behavior. It should be measured, monitored, and maintained.

So, what’s in a strong MRO information technology (IT) solution blueprint? These three essential elements can help ensure a smoother path during legacy system modernization.

Clear business processes

Well-managed business processes are critical to all operations. They lead to advantages such as:

• Standardization: All stakeholders understand and execute tasks in the same way.
• Redundancy: There is less risk when talent leaves or becomes unavailable.
• Efficiency: Performance is optimized, and variances decrease.
• Consistency: Documenting, auditing, enforcement, and compliance are easily realized.

To quickly recognize opportunities for improvement, you are best off using defined process maps. At a minimum, responsible roles and organizational units, tasks, decisions, inputs, and outputs should be clearly represented.

The entire MRO organization needs a hierarchy of processes for each functional group. At the highest level, these typically include engineering, planning, production, supply chain, human resources, and finance.

Ownership should be assigned using a RACI (Responsible, Accountable, Consulted, Informed) index, and you should conduct periodic audits against predefined performance and compliance criteria. It also helps to maintain detailed step-by-step procedures for each task within processes as an easy reference guide for all stakeholders, participants, and actors.

Properly-configured technology components

Software and hardware technology components are essentially tools to enable business processes. They also have roles and tasks within operations and are dependent on processes. For example, a barcode scanner performs a scanning task, and a printer performs a printing task. Hardware like this is easier to understand and map than software.

Screens, webpages, and program names and numbers are commonly used to access and execute business tasks. In a software application, this typically occurs using a menu path or a typed, touched, or voiced command. That’s one element of a software “dependent” or attribute in the primary user interface. There are several other software configuration attributes which may be known by application-specific software names, including tables, switches, parameters, codes, workflows, licenses, and reports.

To successfully execute a “create purchase order” task in an MRO IT system, for example, the following software attributes must be known and configured in the application:

• purchase order (PO) type (from a PO type table);
• approvers (in workflows);
• authorized PO creators (access licenses); and
• format (report or form).

Once configured, these are launched using the menu path or command by the end user.

Because these configurable attributes also influence and affect the behavior of other tasks in the system, their definitions for any organization must be standardized and well-coordinated across all MRO processes.

Any best-of-breed MRO IT application on the market today has a range of 2000-4000 configurable attributes. Imagine the enormous number of possible permutations and combinations.

To put it in simpler terms, the settings and options on your smartphone for the same device and apps are different from mine. It’s about user preference.

Keeping current catalogs

A full MRO processes catalog is about 200 or so discrete, but interrelated, process diagrams with all organizational roles and technology attributes mapped out. This knowledge and specifications repository must always reflect current operations and system configurations. It is the primary go-to for all end-users and system support personnel.

Business processes and procedures need to be continuously measured, monitored, and improved. Also, most MRO IT software applications will have at least one version release per year along with periodic patches, bug fixes, and other updates by the software vendor.

The challenge is to remain agile for all business and software changes spanning the gamut of the blueprint elements. This includes adjusting and adding processes as maturity and capabilities change, and as system functionality is altered and introduced.

Picture two scenarios:

An end-user—a maintenance technician—needs to move a part from one aircraft to another. System updates must happen in real-time. The vendor releases a new version of the system. It includes both major and minor changes. There is an internal desire to launch this release as soon as possible.

Scenario 1 – User manuals

Those familiar with aircraft maintenance know that all of the work done on the aircraft must refer to the approved aircraft maintenance manual (AMM). While cannibalization is frequent in some organizations, it is not something a particular technician will do on a daily basis. Access to a step-by-step manual, which must be referenced in a corrective action write-up, certainly helps. Regulators ensure the correct and current procedures are followed by quoting the AMM reference.

Similarly, to sustain excellent production standards and sensible balance of hands-on work versus system updates (direct and indirect time)—as well as to preserve data integrity—a tailored step-by-step user manual for the IT system updates is also helpful.

Where is this “manual” stored and how is it kept up-to-date? Is it easily accessible by users? The manual should seamlessly interact with the MRO IT system screens by task, and your team’s actual experiences should be key sources for its content.

Scenario 2 – Managing releases

MRO systems need a documented release management strategy and plan. Clear ownership is important—does it belong to the business or the IT organization? The impact of a new system release or change on current business processes and procedures is minimal in a well-managed environment. All configuration attributes or system programs, along with alerts as to the roles that are affected and how, are available within hours or days, not months.

Once changes are known and understood, a consolidated project for comprehensive adoption can be defined. This includes processes, data, and system configuration changes—all well-coordinated and with assigned owners.

Execution of the project includes system configuration, testing, training, and data tasks. This should be seamless within your organizational structure. Done properly, release management is continuous—albeit with varying intensity at certain periods of the year.

A blueprint built to last

The key to continuous improvement is a complete awareness of your current state at any point. Only then can improvement analysis occur.

This current state exists in your solution blueprint. Detailed business processes are mapped with enabling technology components, providing the best possible representation. Structured measurement, monitoring, and improvements to the blueprint need to take place across the MRO business and IT support organization—regardless of whether business or technology initiatives prompt change.