IT systems adoption Part 1

Author: Allan Bachan, VP, Managing Director, MRO Operations, ICF

Subscribe

Allan Bachan, VP, Managing Director, MRO Operations, ICF considers the rate of technology adoption through Covid-19 and how to optimize IT systems adoption.

ICF is a growing global consultancy firm (figure 1), headquartered in Washington DC and that has doubled in size every five years over the past twenty years. The diverse staff of eighty nationalities is distributed across 67 offices globally and they speak seventy languages. The business’s revenue in 2019 was $1,2bn.

ICF’s capabilities are across five key areas. These include Advisory, Program implementation, Analytics, Digital and Engagement. Highlighted in figure 2 are the areas and elements which we’ll touch on in this article. We’ll look at business processes, program design, analysis and benchmarking, assessment and evaluation, business intelligence, IT modernization, transformation and training or knowledge transfer.

ICF applies its capabilities to the aviation community across seven practice areas including aerospace & MRO, airports, airlines, aircraft, sustainability, tourism and transactions. The business has existed since 1963 with the aviation practice opened in 2007 with the acquisition of SH&E and the further acquisition of AeroStrategy in 2011. The consultancy has several partnerships and affiliations with bodies like IATA, the World Travel and Tourism Council and the Airports Council International. ICF is also an ISTAT (International Society of Transport Aircraft Traders) member which supports our Aircraft practice.

ICF’s work is global (figure 3) and includes commercial airlines, MROs, lessors, airports and government agencies. Fundamentally, ICF has been supporting the entire aviation eco-system on a variety of projects over many years.

INTRODUCTION
To introduce the topic, there has been a rapid pace of advancement with technology and business adoption of that technology (figure 4). However, just 40 percent of organizations are on the latest release of the business systems that they use; only 60 percent of what is installed of those systems is actually used and just 50 percent of all business processes and tasks are enabled with modern technology.

To improve this situation, our solution models at ICF are designed to measure how well business processes are enabled; identify potential opportunities; map out how to close the gaps; and to build a continuous improvement framework and thereby institutionalize this as an ongoing behavior.

Before we delve into the ICF models, let’s take a look at considerations for COVID-19 (figure 5). A McKinsey study showed that 55 percent of businesses around the world have accelerated digital adoption by seven years in just seven months of 2020. This is, of course, unprecedented and driven by coping mechanisms to COVID-19. BDO advises on how being nimble can help organizations leapfrog their less nimble rivals. According to an Engine B2B study, Robotic Process Automation (RPA) is of the highest interest when it comes to modernization moving forward. Automatization, automation and digitalization of business processes are therefore key priorities.

However, before embarking on any improvement program, you should know where your current maturity stands. That’s the key focus of this article.

ADOPTION STUDY
We’ll first look at the Adoption Study model. There are five steps that make up the Adoption Study model (figure 6).

Know what you do today
First, there should be a business processes catalog, a list of the core responsibilities within the area under study. The list should be hierarchical in nature and should have all of the functions broken up with a defined set of processes for these functions which are best represented diagrammatically in process maps. Within these maps should be tasks and decisions which have to be undertaken by specified roles within the organization: tasks which fall into categories such as Critical Path, Value Added and High Risk. Another way of looking at this would be identifying the important few as against the trivial many since there will be hundreds of tasks, if not thousands, within a process set – once they have been documented.

A quick example to illustrate this would be, if you’re looking at, say, the maintenance planning division within an airline, there would be functions such as Forecasting, Manpower Planning, Resources Scheduling and Work Packaging. Then, within each of those functions, there will be step-by-step process paths and how they are executed by the staff within that division. For example, with work packaging, one may have to prepare the task cards, pull off a due list, do a tally sheet, collate the cards, put them together dispatch them… all of which constitutes a process. It is important to note that these would be cross-functional representations most times, which will involve people from other parts of the organization, including supply chain, production, engineering and other divisions.

Know what IT assets you have and what they are used for

The second thing to do is take an inventory of all of the IT systems that support this business area and functions. Frequently, that will be part of a larger enterprise system. These systems are usually presented as modules or a combination of applications. With an example like maintenance planning, there may be a planning module or it may reside within engineering or other parts of the application. These modules and applications may have the same names as business functions but, in some cases, they might not. Also, in several cases, business tasks may be done using screens from other modules. For example, engineering staff may manage parts master record information in the materials management module.

So, get a list of all screens and programs that a user would typically use for the business task: all users should be included, administration as well as end users. Programs confined to the IT world or people who manage rules and access in the system should also be documented, not just end user transactions. Even the reports and the way that you would pull, say, overnight reports; those should also be included. Then identify all the configurable, system dependencies for each screen and program. This will include settings or options, parameters, workflows, tables and reports: these can be known by unique names depending on the system. Once steps 1 and 2 have been completed, you’ll be ready to do the Adoption study.

Understand the relationships between functions and IT assets

 To do so, you have to map every task and decision in each process and the related software ‘assets’ where an asset is a dependency from the technology used to perform the task. We call this the ‘as is’ or ‘solution’ Blueprint. There may be many ways to access system screens or programs: the shortest path is to start from the role with which you are dealing; then measure how many assets are used, how many tasks are enabled and how well enabled the tasks are within these assets. That’s the internal measure but the external view is also important. It’s a good idea to look at what is available within the industry for tasks that are not fulfilled well enough with technology tools. There may be more mature tools to automate some tasks or there may not and that’s okay even if there are not any available; not everything can be automated.

What’s even more important is that, while there may be available technology, you have to make sure that it fits your overall IT landscape. We have seen organizations try to couple end-of-life applications with brand new ones and something always breaks.

Business processes catalog
There are four key steps in creating the business processes catalog. First, look at the organization’s hierarchy of business functions: for example, if you look at a typical MRO system, there are key functions including engineering, planning, production, quality, supply chain, finance and human resources. It’s important to view this exercise as collating functions and processes rather than departments. Therefore, some departments would have multiple functions or, in other cases, functions would cross departments. In many ways, all four steps in figure 7 can be carried out concurrently. For example, a function can become a process or a process can become a task, depending on the hierarchy that you are building. Some tasks, based on the level of importance, may also be broken out or elevated accordingly.

Creating detailed cross-functional maps for each process does require some work. If documentation does not already exist in the form of procedures manuals, then this has to be interviewed out of organization personnel in interactive workshops. It is important to include all stakeholders and, as we can see, the RASCI-VS (Responsible, Accountable, Support, Consulted, Informed – Verified, Signatory) index has to be captured. Another way, instead of interviewing this out, is observing how it actually works within the enterprise. Beyond the usual Responsible, Accountable, Consulted, Informed, we also advise to have support, verified and signatory RASCI items. The Support role is really assigned to the technology objects where the system is used to fulfil the task or the system may be autonomous as a responsible role in fulfilling the task. The usual SIPOC (Supplier, Inputs, Process, Outputs, Customer) method of developing process maps is encouraged. By the time the processes have been documented, hundreds if not thousands of tasks will have been identified therefore it is again important to focus on the important few as opposed to the trivial many, as we’ve already seen (above). Critical, Value Added and High-Risk paths within each process should also be identified. These can be around financial, regulator, quality, compliance or other measures.

Relative to MRO IT projects, ICF brings a best practice catalog of four hundred or so prescriptive processes based on our long experience across multiple projects and multiple geographies as well as the specific business models of airlines and MROs.

Supporting IT systems
The next step is to take an inventory of all technology objects (figure 8) which are used for that business area. Include applications, integration and data objects. Ensure the capture of all applications including desktop and one-off tools which may be in Excel or other MS Office tools. Also include any APIs (Application Programming Interfaces) and peripheral systems such as ERP (Enterprise Resource Planning), Finance or HR (Human Resources) systems. Data might also be in paper forms or other data repositories such as SharePoint: be sure to capture those as well. Maintain these as a hierarchical list identified to modules and applications. This makes it easier to align technology objects to business functions, processes and tasks.

For every transaction, screen or page, within those systems there will be configuration options or settings which influence the behavior of the screens with which a user may interact. An example of that would be that, in my phone, the way that I read my mail and the settings can be different from the way in which you read yours as well as the way you would configure a banking App or any other type of application. All applications will have user-configurable options. These should be identified based on the parent objects, screen or program. Based on the actual system, the names of these settings and options will be different; however, in almost every case, it will be ‘settings’, ‘options’, ‘workflows’, ‘tables’ and ‘reports’.

In part 2 we will continue with the adoption study, looking at the ‘as-is’ blueprint, measures and gaps, adoption improvement and EPC support.

Contributor’s Details

Allan Bachan
Allan is a Vice President at ICF with 32 years of industry experience as an Aviation M&E, MRO and Supply Chain solutions and systems domain expert. He is responsible for ICF’s MRO Operations and IT practice and he manages the Aircraft Commerce Consulting relationship with ICF. His experience includes managing application design, development, and full cycle implementation – from selection to go-live – for strategic clients in the MRO industry using different commercially available MRO IT products. In his career, Allan has fulfilled the following leadership roles: MRO IT practice and technical lead; MRO systems Product Principal; M&E and MRO Solutions Director and Manager of Technical Records, Maintenance Planning and Production Control.

ICF
ICF is a global consulting services company with more than 5,500 specialized experts, who are not typical consultants. They combine unmatched expertise with cutting-edge engagement capabilities to help clients solve their most complex challenges, navigate change and shape the future.