SETTING THE STAGE | SQL Tips & Techniques (Miscellaneous)

In August of 1990, Omega Airlines's Strategic and Technological Planning Group presented the Board of Directors with a request for a ‘global’ authority for commitment (hereafter referred to as an "AFC", this proof of commitment or sign-off must be obtained from Omega Airlines's Board of Directors and Steering Committee before work can proceed on a project) for a strategy to replace the Honeywell-Bull system. The strategy would involve the replacement of the Honeywell-Bull with an IBM mainframe and the conversion or replacement of more than 5,000 applications that were then executing on the Bull system. The funds requested with this AFC (each AFC represents an allotment of funds that is committed whether to a specific phase of a project or to an entire project), in the amount of US$36 million, would be used to convert 1,500 Bull programs to the IBM mainframe platform, while the remaining applications would be replaced with new applications under separate projects. (Since the ‘Bull Migration Project’ actually comprised many projects spanning several years, several AFCs needed to be obtained, in some cases, for each major phase of each project.) The request was approved (Verville, 2000).

Since then, a number of initiatives were undertaken to execute this strategy. The Board subsequently approved the replacement of the revenue accounting system for the Finance Branch and the procurement, inventory management and aircraft maintenance systems for the Technical Operations Branch. These initiatives represented somewhat less than 40% of all the applications that were on the Honeywell-Bull system.

Five years later (1995), more than 60% of the 5,000⁺ applications still remained (in whole or in part) on the Bull, awaiting conversion or replacement. While various projects involving the initial 1,500 programs were progressing, they had yet to be all delivered, and numerous others still needed to be started. Major upgrades of both hardware and software were needed to support critical applications, such as payroll and the airline schedule. Other major areas included Finance, Human Resources, and Sales Reporting. In the interim, continued maintenance was being provided for the Bull, though without any new enhancements.

Y2K Systems Failures

Up to this point, Omega Airlines had, for the most part, adopted a status quo approach. However, status quo was no longer feasible. In January 1995, the urgency of this situation was escalated when one of the applications on the Bull failed. An investigation into the problem revealed that the application had tried to perform a forward-looking date function (looking five years ahead) that the Bull's operating system did not support. It became evident that other applications would experience the same problems and serious system failures on the Bull were imminent. Thus, the ‘Year 2000’ (Y2K) issue became a major problem for Omega Airlines, the impact of which would be felt starting in 1999.

So it was, that in the fall of 1995, the Information Technology Group presented a revised ‘global’ AFC to the Steering Committee for the planning phase, for eventual presentation and approval by the Board in May 1996 (date later changed to August 1996). This AFC, for more than $2 million (which was approved), would authorize the IT Group to proceed, in the first part, with an in-depth evaluation of the different alternatives available to Omega Airlines and to recommend either re-investment in the Bull technology or completion of the Bull de-hosting program.

Several key issues influenced the evaluation by the IT Group, the most significant of which were the reliability (or rather, the unreliability) of the Bull platform and the inability of the applications and processing environment to support the turn of the century (the Y2K problem). Given the uncertain condition of the Bull and the critical nature of systems such as finance and human resources, some applications had been partially migrated, some had been duplicated, and still others had been developed on an IBM host system (both systems [the Bull and the IBM host] were then integrated through a series of interfaces). Because of the gradual and partial migration, and in order to provide better integration, functionality, data integrity and overall architecture to facilitate their maintenance, the IT Group's evaluation also included the reassessment of some of the applications that were already transferred (in whole or in part) to the IBM host.

Investigating Options

In light of these issues, the IT Group examined four possible scenarios with which to meet this situation involving the Bull environment (hardware, software, and peripherally affected systems):

upgrade the current Bull environment and stay with the current applications;
upgrade the current Bull environment and renew the applications;
convert the remaining Bull applications to an IBM compatible environment and invest the minimum required on the Bull system; and,
eliminate the Bull system completely and
1. purchase new software packages, or
2. convert or
3. rewrite the applications for their IBM systems, or
4. outsource the functions.

The first two scenarios were considered unfeasible given the probability that the vendor, Honeywell-Bull, would be moving, over the next few years, towards open systems and that they would be providing decreasing support to their mainframe product line. From Omega Airlines's perspective and relative to their goals, Honeywell-Bull would not be the strategic mainframe ‘vendor-of-choice’ for the long term and, hence, the decision was made to move away from this platform.

The third scenario of converting applications to the IBM platform would allow Omega Airlines to continue to operate. However, it would not address the issue of inadequate functionality or the gap between what was provided by these systems and what is required to run the business in an increasingly competitive and complex environment.

Lastly, the fourth option would eliminate the Bull host completely and would position Omega Airlines for the future with either new software packages, modified and enhanced applications, or with the functions being outsourced. All of the applications that remained on the Bull system were reviewed against these four scenarios.

The IT Group also evaluated these scenarios on the basis of financial considerations (cost and benefits) which they included in their Business Case and which are summarized below:

Cost:

With the third scenario, straight conversion (without enhancement), over the next 10 years, of all remaining applications (Finance, Human Resources, Payroll, etc.) from the Bull to an IBM-compatible environment with minimal investment on the Bull system, was estimated at US$65 million.
With the fourth scenario, the same applications could be replaced and enhanced for an additional US$15 million, hence US$80 million, over the same 10 year period. However, in this case, there would be significant benefits.

Benefits:

With the third scenario, there were no foreseeable benefits.
With the fourth scenario, headcount could be reduced by 37, representing savings of US$9 million. An additional US$12 million could be saved as a result of improved cash management and expense control. Additional benefits estimated at US$110 million could be derived through access to valuable management information, mainly in the areas of profitability and sales.
(The economic justification was based on the realization of the headcount savings, the cost reductions and 25% of the management information benefits. The IT Group also estimated that this implementation could yield a return of 20.5% and would better position Omega Airlines for the future.)

While the IT Group concluded that the third and fourth scenarios were the only two viable options available to Omega Airlines, they recommended the fourth which would lead to the elimination of the Bull system.

Buy, Convert, Re-Write or Outsource?

The IT Group then proceeded, in the second part, to evaluate the options available to them in the fourth scenario, namely, the options of buying a software package(s), converting, re-writing or outsourcing the applications. For this, they performed functional requirement analyses, developed the request for supplier proposals, and developed the business case and schedule required to complete the project. This ‘second’ part (with some overlap from the first part) of the AFC was referred to as the "preliminary analysis and planning phase of the Bull replacement project".

In their evaluation of the fourth scenario, the IT Group determined that for some of the applications, conversion would be the most feasible option available to them due to the specificity and uniqueness of the software functions for Omega Airlines. For other applications, re-writing was the best solution. For others still, the purchase of a software package offered the most cost effective and timely solution.

Final Recommendation and ‘Go Ahead’

A summary of the IT Group's final recommendations and project plan were presented to the Board and included:

to remove Omega Airlines completely from the Bull;
to renew/replace the applications and thereby provide enhanced functionality for Omega Airlines users;
to reduce application maintenance costs;
to improve system and functionality integration by renewing/replacing systems; and
to assist in improving Omega Airlines's business processes.

The Board granted their authorization for commitment (AFC) providing the ‘go-ahead’ for the IT Group to commence the Bull replacement project.

One Issue Still Outstanding—Buy or Build?

The only decision that remained was whether to build or to buy. While the option of rewriting the Finance, Human Resources, and Payroll applications was initially reviewed, it was discarded early on (February 1996) in favor of buying a packaged solution. It was readily agreed that "in the 1990s, you do not build, you buy, especially if it is software that is a generic application or in generic use by the industry". With the decision being made to purchase a packaged ERP software, Omega Airlines's Project Leaders proceeded to plan a set of activities which they then used to select the appropriate technological solution.

A Request for Proposal (RFP) was subsequently issued in March 1996 to several software vendors, four of which responded, three of which were thoroughly evaluated. In July 1996, the packaged software solution by PeopleSoft Inc., a recognized industry leader, was chosen to provide Omega Airlines with its integrated Finance, Human Resources, and Payroll applications. Not only would this packaged software allow them to implement within a short time frame (especially given the imposing deadline of 1999 less than three years in the future), but Omega Airlines surmised that the use of a standard software package would allow them to rapidly implement new functions developed by the software provider and would also reduce their internal development cycle for modifying the software to meet their own unique requirements. Again, the argument that was presented was that when software is already available on the market for a generic function or is in generic use by the industry, "you don't build, you buy." Omega Airlines's management reasoned that since every company has financial and human resource systems, it makes little sense to invest time, money and effort to build when state-of-the-art software is readily available. Other factors that affected the decision to buy an integrated solution were the restrictions imposed by 1999 and Y2K, then just two and a half years away (Verville & Halingten, 2001).