This article appears in Issue 18: the April / May 2015 edition of the Aircraft IT MRO eJournal. For your own free subscription to the eJournal – click on ‘SUBSCRIBE FOR FREE’ for full details.

Preparing for MRO IT System Implementation or change

Process Design and Solution Definition

“No matter how hard people work, they can’t overcome a flawed process design, much less the burden of no design at all.” That was Dr. Michael Hammer in his prophetic, as it turned out, turn-of-the-century book “The Agenda”. From our point of view as MRO IT professionals, it’s particularly true that process design is a key tenet for any MRO IT project.

The big picture
However, before even the design stage, we must first understand the opportunities that can be realized by MRO IT as well as its limitations. MRO IT systems are key enablers of business processes with technology tools but are not processes unto themselves. They can be used in different ways for the same functions, and they can be configured differently depending on business processes. Considering that a good software product serves clients with different business models and fleets in many geographies, there is no one best way to deploy the software that will work for all. Newer systems are only catalysts for improving the related processes, and the client should seek to identify process gaps and remedial approaches to prepare for the IT system implementation. The client should also remember that choosing any particular software configuration option is no guarantee of best fit. Process documents are tools for continuous improvement, so methodology and approach should be standardized. The outputs should be multi-purposed, revision-friendly, and reusable, and process maps should be fully capable of supporting the solution definition (blueprint).

The role of processes in the implementation model
Business processes play a critical role in the MRO IT implementation cycle, inasmuch as good process maps will define the quality of an implementation project. The diagram in Figure 1 below shows a common model for the major stages in an MRO IT implementation with typical timings, the tasks to be done and, as importantly, the levels of (new MRO system) competence that the client team should ideally be at in order to properly fulfill on the respective deliverables at each stage.  The role of process diagrams in each stage is especially indicated in blue font. It should be noted that process mapping begins long before the software implementation kick off and the final processes survive long after go-live.  

The evolution of process maps in implementation
The model in Figure 2 shows the evolution and multi-purposing of process maps throughout an MRO IT implementation cycle. In the preparation phase, the client defines a clear vision of what it expects to enable with technology. This involves documenting the as-is processes and using best industry practices and a blue sky approach. The to-be processes are built on this definition of desired processes when mapped to the software. The resulting future processes are the basis of the solution blueprint and any BRDs (business requirement documents) for software development. Acceptance criteria and more step-by-step details can then be added to these key processes to become the test scripts to be executed for UAT (user acceptance test). More refinement and formatting can also be done for training scripts, controlled manuals content and change management communications.

For this model to be a success, the desired processes must be comprehensive and of a satisfactory standard before the start of the software implementation. Unfortunately however, that desired or ideal state definition is too often overlooked. In some cases, even the current as-is state assessment is abandoned and people assume the software will automatically fulfill the adoption of the new system processes and the desired to-be state. This is a huge mistake.

It is a myth that simply inheriting the built-in processes of the acquired software will be automatically beneficial to the client.

1. MRO IT software products result from good business practices, not the other way around. These software products are still evolving and development is subject to the vendor’s product plan. The product plan is a consequence of the needs of the client base and emerging industry demands.
2. The software serves many MRO business models. Examples are: outsourced maintenance, third-party services for profit, mature back shops, no in-house maintenance, line maintenance only, etc. A good software product will therefore have many configuration options for the respective business model. These options are not easily identifiable at a granular level and must be learned in product training.
3. If you do not examine your current state (as-is) and define your desired state, you may never know:
   a.    The true opportunities for improvements specific to your business.
   b.    The good practices (evolved over many years and with the investment of many people’s efforts) that you may potentially be throwing out.
   c.    Which software configuration options would best suit your specific purposes.
4. It’s nearly impossible for someone to learn all of the integrated functionality of a new system and use that knowledge to define a to-be solution within nine to 12 months.

While the vendor can bring product knowledge to the project, it is up to the operator to provide the project with good knowledge of its business: as it is, issues it needs to mitigate, and as it wants it to be. Bringing both capabilities together creates a collaborative effort that should result in a better definition of the to-be solution. Once the desired processes have been clearly defined the implementation project is cleaner and more purposeful. The process maps are used throughout to ensure the software satisfies the client’s business functions. This helps to avoid the need for extended discovery cycles by vendor resources, rework, and for remediation mini-projects after go-live.

Developing the process maps
Executing the plan is just as important as the implementation model. All projects change as problems with resources, scope, and timing crop up, so the plan must be flexible. As long as the implementation approach remains on course, reacting to changes and issues will be much easier. This model advocates a processes-based approach vs. a product-based approach. It is extremely important that that the process-based focus is maintained and that the time needed for each phase – to develop staff on product knowledge and to have them vested in defining the solution – is well spent.

All too often, when a client is caught unprepared, the default becomes what’s immediately visible and comprehendible based on where the implementation team is on the learning curve. That then becomes what is prematurely adopted as the de-facto solution. Much later, when system knowledge is improved (mostly after go-live) this is regretted and it takes a longer time to repair, if at all possible, with many challenges to overcome.

There are four key stages in the processes development cycle with distinct steps in each.
Stage 1: Create a processes catalog.

• This is a hierarchical list of all your business processes by function.
• Use content from existing systems.
• Draw from your policies and procedures manuals – mainly GMM (general maintenance manual), GPM (general procedures manual) and TPM (technical procedures manual).
• Include wish lists and blue sky items.
• Include existing requirements lists.

Stage 2: Document as-is processes.

• Provide a baseline for identifying gaps, but do not make it overly detailed.
• Choose a methodology and tool or template (e.g., iDEF0, UML, BPMN).
• Glean information from manuals, structured interviews and observations.
• Capture all systems-dependent tasks.
• Include forms and reports where applicable (as instruments of inputs and outputs).

Stage 3: Create desired processes.

• Optimized for where more than one process exists for the same function; common for:-
  Multiple AOCs;
  Multiple systems;
  Duplications.
• Apply pan-industry knowledge.
• Use a blue sky approach.
• Evolve the details:-
  Improve tasks step by step;
  Redefine roles;
  Consider how things should be done;
  Identify and define relationships and dependencies;
  Apply notional KPIs (key performance indicators);
  Merge and consolidate tasks and processes where possible.

Stage 4: Create to-be processes.

• Map software objects to processes and tasks.
• Amend and alter processes where appropriate.
• Evolve BRDs (business requirement documents) as needed.
• Produce the solution (definition) blueprint.

The processes catalog
This catalog is the product of requirements and current procedures with a systems perspective. It is typically a hierarchical list of about 400 processes for the MRO system. In the sub-functions listed in the RFP (request for proposal), the operator defines what it seeks from the new system. The procedures that are employed today are typically included in the GMM and systems user manuals. What additionally is being sought is taken from knowledge of best industry practice and similar but more mature operators. While the process topics can be taken from internal perspectives and content, it is a good idea to involve participants with external and broader industry thinking and experiences. You may even encounter pre-defined process catalogs and models. Some vendor RFP responses will also provide prompts for additional processes and process groupings that should be included.

The as-is processes

At this stage, it will be necessary to document the as-is processes using the diagram templates and tools you have elected. To keep these documents consistent (therefore, more useful) they should use a standard template. It matters less which program you use as each has its own merit – Microsoft Visio or a COTS (commercial off the shelf) program for BPM (business process management) – as long as the output is consistent for each process documented – see below for a Visio (common desktop application) example.

When filling the as-is documentation template, the level of detail should be sufficient to identify opportunities for improvement, but not overwhelmingly detailed. Following the approach below makes this easier.
1.    Read available documentation and represent the process as a flow in the template.
2.    Observe the tasks and activities in the operations environment.
3.    Interview the key stakeholders and actors or players in the process.
4.    Collect any artifacts that are used or produced in the process (forms, reports, screenshots, etc.)
5.    Store process diagrams and artifacts in a (shared) structured and controlled repository.

This is where good SME (subject matter expert) skillsets count heavily: understanding your systems and the business functions.

The desired process map
The desired processes definition is the stage that is most often overlooked. The as-is efforts can be very superficial since the outputs are considered disposable in the context of the to-be. In much the same way, designing a desired way of operating is also considered disposable since people expect to just adopt the processes in the new software. As explained before, this is only partly true. Instead, people should expect to adopt the new software to improve and enable business processes. Figure 4 shows the contrast of an existing as-is process map taken from a procedures manual to a desired map using a defined template for software enablement. This is used for illustrative purposes where a structured as-is documentation effort was not existent.

1.    Who or what is doing this task or making this decision and what is his or her role? Note: MRO System is a role name.
2.    To which department or function does this role belong, and what is that function?
3.    How would you like the new system to support this task, i.e., what do you expect of the system?
4.    If this is a system supported task, what do you expect to enter (input), what do you expect the system will do (system) and what is the expected output?
5.    Is there any kind of alert you would like the system to send? If so, should it be configured or automatic in the new system? This will be part of the workflow.
6.    If this is a system supported function, is it done with real time system processing or delayed system processing, i.e., what is the mode?
7.    Any other comments to be included in notes?

This is again where good SME skillsets matter to determine what goes in the data fields.

Creating to-be process maps
Creating the to-be processes is iterative throughout the definition phases of the project. However, interactive workshops must be conducted with the vendor and the client in attendance to define to final to-be state.

One model to achieve this is provided in Figure 6 below.
The workshops should ideally occupy a daily activity cycle lasting approximately six to eight weeks or until all maps and system objects are covered. As per the model, each process is estimated to take about 200 minutes on average to cover. In some cases this can be as little as a few minutes when the client process maps evenly with the system.

Client: The End-to-end function and process group outline
The client educates the vendor on its processes using the diagrams. It also highlights any software mapping it has completed to date.

Vendor: Describes MRO system for that topic
The software vendor:-

• Explains the system’s approach to the relevant topic.
• Points the client to the software program which fulfills the business process task and provides all the available resources and materials.
• Provides known best practices with the software.
• Makes any design limitations clear.
• Suggests any alternate methods in the system.

Client: Process map walk-through
The client:-

• Leads a process-by-process walk-through at the detail level.
• Highlights current interpretation and mapping of the process with the MRO system for validation.
• Outlines the rationale and any legal, environmental or regulatory influences for the process design.

This step (above) is highly interactive with the next step.

Vendor: MRO system walk-through
The software vendor leads and:-

• Does the process walk-through in the live MRO system.
• Highlights key differences and merits of options.
• Ensures end-to-end mapping and execution of the process in the software, including inputs and outputs.
• Gives potential role definitions for the process steps.

Vendor: Record change items

• The change items list master is maintained by the vendor.
• The issues log is also maintained by the vendor.
• Any potential risks and gaps are immediately highlighted.

Both Client and Vendor: Summarize and move to next sub-function
This is an interactive step for both the operator and the software vendor to

• Review for each function and sub-function.
• Get verbal acknowledgement from both sides on final disposition of items.
• Repeat for the next end-to-end function or sub-function and process.

In many implementations, the workshops are often misconstrued as another product training session, almost as if the vendor is trying to convince the client. While that is indeed a part of it, it should be more focused on the fulfillment of the client’s business processes rather than a negotiation of accepting the software without regard for what the client wants. This model avoids that risk by being highly interactive and providing an equal stake for both the client and the vendor. The vendor grows its knowledge of the business while the business grows its knowledge and understanding of the product. You can’t accept a solution definition that you don’t fully understand. Understanding across teams also prevents unnecessary customizations and software development efforts.