The balance between IT, Flight Operations and Engineering is a critical one, as Shaun Rattigan, Technical Director Aviation Intelligence explains

Having worked for a number of years in both corporate IT and the aviation sector with technical and implementation projects, I’ve found it interesting to note the pendulum swing between the very tightly controlled days of mainframes, through the heady world of PCs (remember the first IBM PCs… and IBM ATs?) and right back to today’s corporate governance of Prince 2 and other business processes.

This paper is not a passing shot at IT, or even at the governance processes generally in place within large airlines and corporate organizations: heaven knows we needed something. But, how many airline systems still have at their heart the spreadsheet with its user-created macros, or the Access database? As we develop more complex systems we need ways of managing their roll-out into the business. It is no longer a case of this or that system providing the information to make good tactical and strategic business decisions; it is a case of understanding how all the airline’s data can be used to provide an integrated data source across the various systems.

It is also pause for thought

In today’s rapidly changing business environment, airlines and, indeed, the wider corporate world have to think about how they can quickly adapt and respond to a massively changing market. How can we apply greater savings; whether to the operational systems or to the purchasing process? How can we generate more income whilst maintaining a safe, quality service to the passenger? The airline sector is, thankfully, one of the most regulated, particularly around flight operations and engineering, with very tight controls about what systems are put onto the aircraft and what engineering processes are in place within the airline to ensure the right components are installed.

Here, however is where we start to diverge from the norm. Historically, IT systems within airlines have formed part of the wider corporate systems, with IT looking at the normal day to day business activities of managing a wide variety of data types, systems, interfaces, technologies etc. The application of good governance is (or at least it should be) common sense, to ensure a level of control in the selection, design and implementation of complex and interacting systems

We are getting very good at taking the corporate approach to different systems, implementing a range of methodologies that allow us to pass through the various control gates and governance structures that make sure we are on track and within budget when implementing these systems.

If it sounds like sarcasm, it’s not; we really do need common sense and structure when implementing large systems, but here is the rub, it’s the project manager who suffers the slings and arrows of outrageous governance (apologies to Shakespeare).

‘Well he should have been prepared.’ I hear the call and I totally agree.  Most project managers, including myself, will have gone through the governance gates, knowing they were really not ready, to just try and keep the project moving through the gate process and keep the project on the planned timescale, as the next gate is not for another week or so: a painful learning experience.

However, there is a question: is the aim for the gates to provide some sort of ritual gauntlet or a positive arena to ensure the programs are on track? The net result is that the project manager can become more interested in ticking boxes to get through the gates than ensuring the deliverables meet operational needs.

What’s this got to do with the flight operations?

It’s this; are we are in danger of getting so busy implementing the governance process that we forget what it is we are working towards? We rightly implement these systems as part of a corporate approach but sometimes do not take into account the regulatory and operational requirements, particularly, of Operations and Engineering. Project managers are generic and perceived not to require any operational or engineering knowledge which they can factor in as part of the project resource. This, though, impacts directly when decisions are made, often from an IT perspective, without any real understanding of the effect on Operations or Engineering because the decision needs to made quickly whereas it would take time to engage with the users.

This is, of course, a generalization and there are a number of airlines implementing good solid corporate governance whilst still covering the specific business needs of Operations and Engineering.

‘Airlines are in the business of moving people, they just happen to have to fly planes in the process’

This was a comment from one airline. Although true, it neglects to take into account of the requirements to perform this role under a Civil or Federal Aviation Authority regulatory regime.

The rapid approach of aircraft such as the Boeing 787, and Airbus 380 and 350 is going to massively change the way we look at IT systems within airlines due to the thousands of software parts we will now have to create, manage and distribute. These are classed as engineering components and, if the IT community treats them as just pieces of software or just configuration files, we are in danger of compromising the engineering controls in place to manage the controlled ‘Black labeled’ aircraft parts.

IT has historically taken the approach that all these systems are just data and we can just manage their storage, access and distribution using the normal IT data centers, can’t we? However, these data centers have been established to take care of airline data corporate data requirements, making good financial and systems sense. But flight operations and engineering have some very tight regulatory and operational requirements to fulfill. Why, for example, can’t we just store these software parts on the datacenter servers and control access? It’s just a piece of software isn’t it?

Have you ever walked around an engineering hanger and looked at the end-to-end process for receiving a part (and its associated documentation) from the manufactures; or even visited the secure cages where the parts are stored before they are booked out by a licensed engineer and delivered to the aircraft? The concept that the manager can walk into the stores, gain access and take one of the parts simply because he is the manager is not credible. The regulated engineer has to do it and to sign all the relevant material. But what about the IT system administrator: don’t they need access to the servers to manage them and are they certified?

The text so far has been a general introduction to the pendulum. Edger Allen Poe would have the pendulum moving nearer to the hapless individual on each swing. We, on the other hand, are watching the gradual move to implement corporate governance. Overtones of drama, perhaps, but the story still holds true. We have a situation where the operational teams of both engineering and operations are not consulted or involved when new IT systems are being addressed and with generic project managers implementing these systems with the notion that they can engage the relevant skills for decisions from appropriate departments.

In principle it’s an excellent idea; in practice, however, the systems may work from an IT perspective but may not match the operational and regulatory parameters. We have the IT department to implement IT systems; we just need input from Operations. This argument is too one-sided and the other side needs to be considered: what happens when operations and engineering go their own ways?

The other side of the argument

Some Airlines have sidestepped the issue with two separate IT divisions; one for general IT and the other specifically engineering and operations biased. This is great in principle… but expensive. To cut costs, most airlines have consolidated all IT into one single department but it is surprising how many of the people with specific aircraft-based technical skills have been replaced by general IT people.

This is causing more problems now that Windows is heading into the cockpit with the implementation of windows based EFBs. Who sorts out the ‘blue screen of death’ when a profile becomes corrupt? Not IT as they cannot go anywhere near the aircraft or the black labeled parts. Not engineering as they are following the fault finding process laid down in their ops manual. I would be able to retire if I came up with a full fault finding diagnostics manual for windows. And what about the encrypted data sent to the aircraft by Wi-Fi or 3G: is that the domain of engineering, the communications company or the airline IT?

The issues arise because not only are the boundaries becoming blurred but, as we centralize support requirements, the intricacies of each system become lost and, if we are not careful, we end up delivering a generic system which may not actually meet the regulatory needs of the aviation authorities. Even when we have a separate IT division all is still not well as we then move to the other side of the equation, which is that we now implement an operations and engineering centric IT department. The systems may meet what the airline needs operationally to fly the planes and satisfy regulatory control requirements but data may not be accessed and used in other areas if it is considered not relevant to the rest of the organization, and besides, they won’t understand it will they?

What use is an ACARS message to IT?

One airline, due to union requirements, has its flight data monitoring (FDM) data on a physically separate system locked away in a separate room with controlled access on the premise that the airline cannot use the data to manage pilots operationally. Again, this is great in principle but the net result is that a massive amount of data that could give operational and safety benefit and could save the airline large amounts on its fuel management or flight planning is not accessible and integrated.

And it does not stop at the separation of the data. Data suddenly becomes the realm of operations and engineering and the airline loses the concept of a central source of information because suddenly there are multiple sources for the same information – usually after it has been processed through other systems.

Between a rock and a hard place

A good example of this type of mismatch is fuel management, On the one hand there is Operations saying that the pilot has uploaded so much fuel;, this, however, does not tally with the fuel chit from the ground handling company and, even worse, there is no way to rationalize the invoice against the fuel uploaded as nobody is quite sure which one of the two to use in the corporate accounts system.

The fuel department generally ends up being caught in the middle between IT and the corporate accounting system, and Operations with their data. The accounts team tries to rationalize the various invoices against the fuel uploading whilst the operations team is trying to get the pilot to complete fuel forms accurately. This is where taking an holistic view makes sense and a number of airlines are now using ACARS to get the information back either from the EFB or from the flight computer before integrating it into the back-office systems.

Here however is the real question. Who is responsible for integrating the airline data? Is it IT, with the corporate centralized systems and data warehouses, or is it flight operations with their operational imperatives; or even engineering with the maintenance?

The truth is out there

I used to enjoy watching the X-Files television series because there was generally a question left hanging at the end of the program; left hanging with the viewer. The IT vs Operations question is a little like that in that there is never a right or wrong answer for a specific airline: each one has its own system and business requirements. Some airlines have totally outsourced the IT function (that’s a discussion for another time) whilst others have large ‘in house’ IT teams. Others still have small IT teams and are running the airline via spreadsheets and databases.

The answer lies generally somewhere in the middle: the corporate machine has brought some control to the delivery of applications and systems to the airlines but at the cost of reactivity and response. Some have the ‘just do it’ approach and, although reacting quickly, end up having to do costly additional work downstream because they are generally looking tactically and have to rework interfaces or try to get the software supplier to change the systems.

At the moment the pendulum is on the corporate side of the equation with airline management seeing the benefits of centralization but not the pain that is causing for operations and engineering teams, particularly where the implementations directly impact of the operational processes and systems

What’s the point?

So, why raise the question at all when the benefits of a centralized IT function and process appear to outweigh the problems? The answer is that we need to redress the balance making sure that when we are implementing these systems we are not just ‘capturing’ the operational and engineering requirements but that they are integral to the solution. That as project managers, we are not just implementing a process but we understand the technical, regulatory and governance aspects of what it is we are implementing and the direct impact for the airline. And for management teams, that Operations and Engineering are not just a hindrance to the IT strategy, who don’t appear to understand why IT wants to drive it, but that their requirements are core to what the airline is doing in terms of safety and delivery of a world class service.

On the one hand we have the corporate IT system designed to save money by integrating the business data and, on the other, we have the view which is not so much interested in the direct cost saving but more on the systems required to manage and fly the airplanes and compliance with the regulatory requirements.

The truth, as always, is in the middle

We need governance but we also need the reactiveness of the ‘just do it’ approach. Corporate governance needs to be in place to aid airlines in implementing systems and not as a mountain for the project teams to climb. For IT to successfully engage with Operations and Engineering, it needs to prove that it can understand their issues.  This may mean requiring that projects managers are technically competent or simply making sure that the implementation teams are fully engaged and respect each other.

There is not a wide range of systems that operations and engineering require but IT does need to understand them and stop treating them in the same light as generic corporate IT systems.

Balanced approach

The pendulum needs to come back towards the middle and hopefully stop without the fear that Edgar Allen Poe induces. As IT becomes more involved with the operational and engineering aspects of the airline, it will have to manage the new aircraft and their respective communication and systems requirements, it will also have to adapt and ensure that the new systems are implemented alongside the operations and engineering sectors.

Can these overarching governance processes add value? Of course they can if the requirements are approached with common sense. IT needs to engage with the operations and engineering departments but with premise that the data and systems they are working with may need additional understanding that is outside the pure IT scope.