Coming Of Age
In 1986, the International Standards Organization (ISO) created the Standard Generalized Mark-up Language (SGML), a set of specified rules for organizing and tagging large documents needing frequent revisions in a variety of formats.
Utilized extensively by government, law, the military and many industries, including aviation, ISO 8879:1986 — SGML — would revolutionize the flow of information. All manner of data interchange between manufacturers and airlines, as well as within airlines, and the methods for delivery to the end-user would be radically improved. Process efficiency was a given, and huge savings numbers were tossed around like autumn leaves in the wind.
It is now 2013, and the airline industry is still waiting to achieve these results. There has been some incremental uptake of SGML or mostly the derivatives of it, such as HTML and its many variants and the more well-known XML. So far, though, SGML has failed to transform the industry.
Various proponents — flight crew, aircraft manufacturers and airlines — billed the electronic flight bag (EFB) with the same gusto as they did SGML. The EFB has great potential, but has so far failed to live up to its own promises. Similar to SGML, the struggle has not been with the technologies involved, but rather the aviation industry’s inability to implement the changes — business processes, cultural changes, etc. — necessary to successfully support these advancements.
The same issues continue to cloud the potential benefits of EFB now as they did in the beginning. Perhaps some adjustments in perspective are needed to rethink the view of the technology’s potential, drive some fundamental change in the manner in which EFB is approached by the industry and hopefully deliver greater success in EFB projects in the future.
Naturally, flight operations would take some ownership of an EFB project. However, because the EFB, like a computer, is not just an instrument in the cockpit, the IT department must also take part ownership of the project.
Framed as an “enabler” similar to other technologies before it, the EFB is unequivocally a tool for re-energizing, re-engineering and revitalizing the operational domains within an airline. Its potential value ranges broadly depending on the scope of various projects.
Consider, for example, one particular planned five-year EFB program. Based on a strategically specified collection of EFB capabilities, its business case delivered a financial benefit to a particular airline of US$304 million. This figure was the discounted cash flow (DCF) benefit, which means inflationary aspects and the time value of money had been accounted for in the cost-to-benefit analysis for the project.
The DCF is a time-based measure of project cash flows against the cost of capital. While this method has some limitations, this project was worth an astounding US$304 million more to the company than the “do-nothing” option currently in place. Return on investment (ROI) exceeded 48 percent, and the resulting savings totaled one-third of those the chief executive officer considered necessary to keep the airline in business.
Despite the financial potential of and critical need for the project, it failed. The problem, apparently, was not with the technology, nor was it due to difficulty integrating the various parts or even their costs. Quite simply, the airline could not adequately adjust its method of operation and processes and had not thoroughly considered the degree of change necessary to make the project work.
While this was a large, pan-organizational project, many other projects have demonstrated similar ROI numbers in the planning stage. Therefore, the EFB is certainly of value in terms of efficiency, savings and flexibility … potentially.
Unfortunately, promised results are often not achieved. Most senior airline executives know the exact cost of a project. In addition, they can knowledgeably discuss the inevitable ocean of “sunk costs” incurred when projects fail. However, so far, very few have been able to articulate the supposed value of the project or the benefits derived from its implementation.
One airline executive recently stated that neither he nor anyone on the project team could explain the purpose of their EFB project, except that it “seemed like a good idea” and there was “lots of potential down the road.” Interestingly, this project was implemented. However, its true value to the organization is still being assessed, as is the way that value will eventually be delivered.
Indeed, what is the point of the project if there is not an overarching strategy for its implementation and subsequent evaluation? Without downstream reviews, how can the effectiveness of the change be measured? Even further, what exactly should be measured?
Airline pilots have been enticed by the EFB concept since the late 1980s when Boeing introduced the electronic library system (ELS), which was intended as the vessel to contain all the intelligent data gathered from SGML developments. Again, there was a lot of promise. Boeing claimed an airline could do “anything” it wanted to do with the ELS. However, at the time, Boeing did not define “anything,” leaving airlines to figure it out in the midst of a bold new information revolution they have struggled with for years.
Nevertheless, Boeing did set a price for ELS, and it also failed to consider the additional costs associated with the execution and airline-side implementation. The price tag, in the absence of any real measurable ROI, simply scared the airline industry well into the next century.
The industry’s response to the cost associated with ELS stems largely from the manner in which various industry developments have been introduced over the years. SGML was, and still is, one of the most robust information enablers of our time. It has the strength to be a standard and has by way of its derivative, HTML, delivered the World Wide Web. However, the aviation industry viewed SGML with excitement well before the Web existed.
A few exceptional people realized SGML’s potential and took their ideas to the International Air Transport Association (IATA) and International Civil Aviation Organization (ICAO). Soon after, the Air Transport Association — now known as Airlines for America (A4A) — formed several committees to look into various uses for the standard. These deliberations continued for many years but were hampered by a fundamental lack of direction. There was not a business case or strategy in place for directing the way SGML was to be utilized within the industry.
While significant work was done by some members of these organizations, a greater amount of time was spent working through semantic differences. There was also confusion about who the end user of the resulting interchange standards would be, and attempts to clarify the issue fuelled arguments among various committee members with differing interests and perspectives.
Aircraft manufacturers needed SGML to streamline supporting documentation from various upstream suppliers and efficiently channel it to airframe customers with minimal effort, thereby eliminating the mammoth task once necessary to consolidate paper copies of the same information into various aircraft manuals. Airlines viewed the standard as a timesaving device in the publication and amendment process, but did not consider it a resource for smart electronic data. In addition, carriers had their own unique documentation to contend with.
All interests, it seems, were more focused on the desired format for delivering the information, which drove much of the debate for years, rather than the product itself. Eventually, pilots joined the discussion and expressed the need for functionality that would provide better access to timely information in the context in which it was required.
Finally, the IT community introduced new technology that moved the focus from developing a standard form for enhancing data interchange between and within aircraft manufacturers and the airline industry to the justification process and effort necessary to pay for the tools.
When To Run Calculations
There’s a fine line pilots must consider when running calculations on an EFB. If a calculation is run too far in advance, additional calculations will likely need to be made, especially involving weather, weight and payload. However, if the calculation is run too close to the holding point, there’s a risk of not completing the task in time and losing the slot on the runway.
Before SGML could advance further, it was passed over in favor of HTML and XML, shelving decades of work. Unfortunately, lack of planning and business-needs evaluation resulted in the various committees involved drifting from one direction to the next as their membership changed without any true resolution. This trend continues today, as the time between new product iterations continues to narrow.
The EFB development process to date has faced similar challenges with competing interests driving unnecessary costs into projects and refocusing efforts on the product again, rather than the initial purpose of the device. As with SGML, EFBs also have their share of competing interests. Pilots want EFBs because they perceive the device will make their lives easier, thus giving flight operations part ownership in the project.
To further complicate projects, an EFB is a computer, not just an instrument on the plane, so it must be controlled, approved, managed and maintained within the IT infrastructure and standards of the airline. To add to the complexity, only supported applications may be deployed within most airlines, which complicates things when flight operations, for example, want an application that is unsupported.
A change in perspective, then, may be the only way to ensure the EFB does not follow the same path as SGML. When evaluated, implemented and utilized correctly, the EFB is an organizationally holistic tool. Its function is to enable change to business processes throughout an airline and provide business intelligence that empowers it to manage situational circumstances better.
To focus on the device itself in the absence of an overarching strategic view renders it almost dead weight. Therefore, extracting the EFB’s inherent value to an airline is the crucial issue. Even if EFBs are cheaper and easier to acquire than ever before, they cannot be assumed to be so inexpensive and/or easy to implement successfully within an airline.
The airline is now carrying more overhead in terms of weight on the aircraft, and additional lines of business and administrative overhead associated with the device may create a fiscal drag. Unless the airline has a clear strategy for what it wants to achieve or “enable” with the EFB, it is likely the device will become an optional extra to existing processes, even when so many tools are available from the supplier side of the market through which considerable value can be extracted. On their own, these tools are worth little, but when integrated with lean business processes and supported by holistically implemented enablers, such as EFBs, the savings illustrated earlier become possible, even routine.
Performance, for example, has long been a key tenet on the savings side of justifications for EFB. There have been volumes of material written about the potential value of using just the right amount of thrust for a given set of conditions.
These benefits take on greater significance when the cumulative effects of performance adjustments are accounted for, as necessary, in well-developed performance applications compared with the page-derived alternative.
There are few such applications on the market. However, and perhaps even more significantly, not all are able to provide the granular detail needed when applying adjustments for minimum-equipment-list-driven corrections and instead place the same singular gross penalty as the paper alternative. As a result, they do not enable great change — or add great value.
On the operational side, up-to-the-minute environmental and aircraft conditions — weight and airworthiness data — are required to provide optimal results, from which benefits are achieved. So when does the pilot run the calculation? The most ideal time for maximum benefit is near the holding point. Of course, as the aircraft approaches that point and is then next in line for departure, stopping to run a calculation on an EFB is impractical and risks the wrath of air traffic control. In some cases, the aircraft may lose the slot, which can result in considerable delays.
On the other hand, running the calculation too far in advance — 30 to 45 minutes ahead of departure — may necessitate additional calculations, especially if the wind and/or temperature fluctuate or last-minute adjustments are made to aircraft weight involving fuel or payload.
To mitigate the need for these calculation changes, short cuts creep into the operation. The weight is artificially inflated initially to accommodate last-minute passengers or freight. Wind components are rationalized to be less favorable by random values, including reducing the headwind or increasing the tailwind to ensure the prevailing wind at the time of takeoff does not generate the need for a re-calculation.
In regard to temperature and air pressure, one increases and the other is reduced to “pad” results further and ensure a limiting takeoff does not occur. However, that’s just the point. These applications are beneficial because they create a limiting takeoff, more or less. By the time an aircraft takes off, either poorly conceived software, under-utilized software or random human intervention has eliminated the potential benefits of such applications. There is a big gap between an application’s potential and real delivered value.
The gap can be reduced by rigorous strategic considerations regarding the purpose, rather than just the product, of a holistic EFB program. Still, many airlines persist in putting “the cart before the horse,” buying a piece of hardware because the price point is desirable, irrespective of the rest of the program. Then, a set of “requirements” must be developed to justify the reasons for the decision. Perhaps a few applications are considered, purchased and loaded.
For all their potential value, successful EFB programs encompass more than buying a piece of equipment, loading apps and then switching it on, no matter how cheap and easy the device or how logical one app or the next may appear. Deciding why a particular EFB was purchased or how it will be used — after the fact — leaves little room to negotiate and, more often than not, guarantees friction among various departments when potentially valuable new technology is thrown at existing business processes and operations.
The “why” and “how” should guide decisions about which device to choose, rather than the other way around. This small yet vital distinction is just as important on the supplier side as it is for the airline side of projects — no matter the product involved.
Electronic Flight Bag (iPad)
Little Rock Air Force Base is shaping the future of aviation by testing a new electronic flight bag.
Even when a supplier’s hardware or software can perform exactly as the supplier stipulates, an airline’s perception of how the product will operate in its environment must be considered thoroughly. In addition, some aspect of the supplier’s offering may not function correctly within an airline’s environment, especially when utilized in conjunction with existing applications or hardware of which the supplier is not aware.
These challenges may prohibit both the airline and supplier from experiencing the full benefits of an EFB program. The earlier implementation requirements are identified, the better — for both sides.
The answer then is for an airline to fully consider the purpose of an EFB program before choosing a product or a supplier. As well, the supplier should be as insistent of the “fit” as the airline is insistent on its qualification criteria for the supplier.
A wide array of capabilities is available from suppliers in the EFB market. Nevertheless, when EFB implementations fail, airline management confidence in future projects wanes and ultimately supplier orders dry up. Internal and external relationships can be negatively affected for years to come.
An airline considering an EFB program should begin the process with a rigorous analysis of its own existing operations and business processes. This assessment serves as a vital baseline for contrasting the value of potential conceptual results. From there, airlines develop “what-if” scenarios that specifically address how the many operational processes that contribute to the day-to-day and crisis operations will be impacted by an EFB program. Gaps in the ability to simply change the process to something more efficient will likely be filled by technology, such as the EFB.
Eventually, a clear understanding of the potential new way of doing business coalesces, from which the requirements necessary to reach an optimal level of operational efficiency and flexibility emerge. These requirements can then be developed into formal definitions that both airlines and suppliers can utilize to guide the technical and organizational transition.
Moreover, development of robust operational scenarios facilitates the establishment of strategic processes necessary to ensure the right criteria are used to choose application functionality and identify potential implementation challenges in advance. This approach supports the translation of potential benefits into tangible savings.
Of course, this approach may require suppliers to work a bit harder than they would selling shrink-wrapped software. However, the benefits to the supply side include increasingly successful implementations, growth in new and returning business, and stronger customer relationships.
On the airline side, there is the realization that an initial in-depth evaluation will lead to greater cost savings later and higher rates of project success presently and in the future.
From its tentative beginnings a quarter century ago, the EFB has come of age. The market is full of mature, almost commodity-priced hardware, as well as a broad and growing inventory of specialty applications that airlines can use to strengthen their agility.
As the pace of technology development continues to increase, agility has become a crucial component for carriers to effectively compete. Growing demand for sometimes scarcer resources will push airlines to operate more efficiently and with greater flexibility.
Certainly, EFB is an enabler — a foundation capable of supporting the ever-changing demands on airline operations. However, this foundation cannot be considered in isolation from the rest of the structure without an eventual structural failure.
Unfortunately, concentration on technology first and its purpose later has been a hallmark of two of the most potentially beneficial developments in the aviation industry during the last 25 years in terms of operational capability, efficiency and value to airlines. It is inconceivable that they have taken so long to develop. Airlines and suppliers must collaborate to find better ways to bring developments such as SGML and the EFB to the industry, successfully and more quickly.