ANALYSIS OF OMEGA AIRLINE s ERP ACQUISITION PROCESS

ANALYSIS OF OMEGA AIRLINE's ERP ACQUISITION PROCESS

This section presents a detailed account of the processes and activities that Omega Airlines completed for the acquisition of PeopleSoft's ERP software solution.

Planning Process

"The more work you do before selecting the package, the better. It decreases the surprises and allows you to prepare ahead of time all things that have to be considered in order to put the package into place and there is certainly quite a number of them" (Project Manager – Technical).

Planning encompassed all of the activities that Omega Airlines deemed necessary to pursue this endeavor. In global terms, planning included meetings to determine schedules, priorities, participants, resources that would be required; activities and tasks that would need to be completed; types and sources of information to be sought; and so forth.

It could be seen that there was a great deal of planning done by Omega Airlines for this acquisition. Much thought and attention was given to every stage of the ERP acquisition process during this phase (planning) so as to lay the foundation for undertaking the acquisition. The planning that was done by Omega Airlines addressed the following issues:

• Participants—Who would participate in the different phases of the acquisition?

• Acquisition Strategies—How would the organization approach/deal with the vendors?

• Establishing Requirements—What are our organizational needs in each of the areas that would be affected by the software?

• Establishing Evaluation Criteria—How would we evaluate the software and against what criteria?

• Contingencies—What contingencies do we have to fall back on should there be a delay or if the final negotiations fail or we are unable to find a suitable packaged solution?

Participants

The Director of Enterprise Systems/IT was responsible for the acquisition project and he selected the main person (the Project Director) who would lead the acquisition process for this project. Responsibility of the overall process/project was given to the Project Director who, in turn, had to select the various managers, leaders and individuals who would participate in the process. Individuals were recruited from within the organization. These individuals were from the various departments that would be immediately affected by the new technology. In all, Omega Airlines's Acquisition Team consisted of a core team as well as several smaller teams, one for each of the 12 business sectors that would be directly impacted by the new technology. Each of the teams also included an IT (technical) representative. Additionally, external consultants (IT specialists) were also hired for this project.

One of the Project Director's objectives in recruiting people for this acquisition project was his concern for the long-term buy-in and support of the users for the chosen software. One of the keys to ensuring that buy-in and support would mean that he would have to make certain that many of the individuals from Omega Airlines's core team would participate not only on the project team for the acquisition of the packaged solution, but that they would also be part of the implementation project. As per the Project Director:

"…on the project team, I tried to bring in people that would to be part of the selection and also would be part of the implementation. So that they could not say, ‘Why did you pick this product? That would never work!’ So you wanted to avoid that, so I brought in users and project people that were going to carry this thing through right to the end. So they had a vested interest in picking one they could make work."

For Omega Airlines, this approach worked very well. Participant continuity (team members and end-users) for the acquisition through to full implementation helped to ensure user buy-in of the chosen solution.

Users played an important role in Omega Airlines's decision process. It was important to Omega Airlines's management that users buy in to (actively endorse and support) the new technology. Without this buy-in, Omega Airlines's management felt that the project would be in jeopardy. According to the Director of Enterprise Systems/IT, what Omega Airlines wanted was "a consensus from the users for the decision". By having heavy user involvement in the project, management believed that the Project Team would have the support or buy-in from Omega Airlines's user community that they (both management and the Project Team) needed. Hence, management wanted each "sector of activity to be represented" by users "so that we would have the buy-in". User participation in the project gave Omega Airlines a sense of partnership "with the various users communities and let them come up with a recommendation that they felt comfortable with" (Project Director).

Omega Airlines's Steering Committee also had a role in this acquisition process—they oversaw the project. The Steering Committee was able to allow the acquisition process to flow relatively unencumbered by alleviating obstacles. As per the Director of IT:

"We had a couple of key decisions made by our Steering Committee during our planning phase, which was earlier on—let's stop considering the Bull scenarios, such as upgrading the Bull; let's stop wasting time elaborating the Bull upgrade scenarios. That freed up our time to work on the other scenarios. Another key decision was, if it is out there in the market, we are not going to consider coding. That was another key decision that freed us up. You could have elaborated hundreds of scenarios in this type of acquisition. We would have been all over the place and working on poor scenarios. Fortunately, our Steering Committee helped us eliminate scenarios."

The Purchasing Department also had a role that began early in the acquisition process and that was facilitated by a partnership approach initiated by the Project Director. During the Planning phase, the Project Director met with both the Manager of Capital Equipment Purchasing and the Project Manager – Technical to establish their Request for Proposal (RFP) process—exactly what their goals would be with the RFP, what their time line was for it, and what the transit conditions of the RFP would be. Although the Manager of Capital Equipment Purchasing described his role in this process and that of his department as primarily being to "negotiate and get the terms and conditions under a contract that involved our insurance people, taxation people, our law branch, myself, the user group and the user group firming up the specifications", this example illustrates how Purchasing can play a role in the acquisition process for more than just the final contract and issuing of a P.O.

Acquisition Strategies

Acquisition strategies are strategies that Omega Airlines employed that impacted their Selection process. Omega Airlines's strategy for approaching the various vendors was to bring them all together in a central location and present them with an overview of the type of technology they were looking for. They felt that this would enable them to reduce the list of potential vendors and thus eliminate incompatible technologies or solutions early in the process. It also provided another means for Omega Airlines to gather more information on each of the vendors. As stated by the Manager—Capital Equipment Purchasing:

"…a meeting in a North American city of all potential vendors. This is unusual because normally we would keep the vendors in the dark about whom they would be competing against. In this particular case, we wanted to get a feel for who could do the work for us and also allow some of them the opportunity to team up or partner together in order to give us the full scope or full sweep of applications which was, ultimately, what we wanted."

This approach is an example of an unconventional and unusual Acquisition (Buying) Strategy that Omega Airlines employed to deal with the vendors. While some companies have lists of qualified vendors that are accessible by the public, this apparently was not the practice at Omega Airlines. Hence, for Omega Airlines, it was unusual that the competitors were made aware of each other. Also, what made it unconventional was that they gathered the competing vendors together at a neutral site, i.e., a conference room in a hotel. This, apparently, gave the ‘knowingness’ an edge that had an effect on the vendors in attendance (with one dropping out of the competition).

Another strategy that Omega Airlines planned was to have the short-listed vendors present, over a two or three-day period, their proposed technological solutions. For their presentations, each vendor would be required to use pre-determined scenarios supplied by Omega Airlines.

Establishing Requirements

Given the wide-sweeping range of areas that the software solution was expected to cover, Omega Airlines had to determine exactly what requirements would need to be met by the technology as well as what their own business requirements would be, both current and future. They looked at their current resources—what they had, what they were lacking. They determined what they wanted that was not being met by their current systems. In addition to looking at the requirements that would need to be met by the new technology, they also ascertained the resources that would be required in order to acquire and implement this technology. Hence, they assessed their staffing resources, they considered the time requirements, they looked at the financial requirements—how much it would cost to add more staff; they examined their own systems architecture—would it be sufficient to support the new technology, and so on. They covered all areas of the organization. As per the Director of IT:

"…evaluation criteria and we put them in the RFP. Implicitly, the evaluation criteria were all in the RFP as we were asking vendors to describe each process for each business sector, how they were doing this, if they had software to handle this…"

Establishing Evaluation Criteria

Omega Airlines's Acquisition Team established criteria for three distinct types of evaluation:

• vendor,

• functionality

• technical

Vendor evaluation criteria included size, financial stability, reputation of the vendor, etc. Functionality criteria dealt with the features of the software and included functionalities specific to front-end interfaces, user-friendliness and so on. Technical criteria dealt with the specifics of systems architecture, performance, security, etc.

Omega Airlines established all of the evaluation criteria (with very few exceptions) for all three areas early in the acquisition process (during the Planning Process) because the majority of it was needed for incorporation into the RFP that would be sent to the vendors. This document would inform the vendors, in great detail, of the criteria against which they and their software solutions would be evaluated. As per the Director of IT:

"…evaluation criteria and we put them in the RFP. Implicitly, the evaluation criteria were all in the RFP as we were asking vendors to describe each process for each business sector, how they were doing this, if they had software to handle this…"

Contingencies

Given the possibility of not being able to find a packaged ERP solution that would meet the needs of the organization—what would they do? With Omega Airlines, there was no contingency plan per se. Although they did allocate a budgetary buffer of $3.5 million in case of delays in the implementation of the chosen solution, this was not a full contingency plan. So, while they had contingency money, they did not have a contingency plan.

For Omega Airlines, this project offered no alternatives. There was no room for ‘what will we do if we cannot find an ERP solution?’ They had to succeed. They had to find an ERP solution that would work for the organization. This was a "do or die" project.

Information Search Process

What is most significant about the Information Search process in this case are the sources of information that were used by the Acquisition Team. Two types of sources were used: internal and external.

As to the internal information sources, Omega Airlines availed themselves of information from various sources within the organization that included individual users, team members and internal consultants. These internal sources provided information primarily on the organization's requirements (existing and forecast) at all of the levels and in all of the areas that the technology would impact.

External sources were sought to provide information about software solutions that might best meet their needs. Omega Airlines conducted a marketplace search, gathering information from such varied sources as external consultants, publications, trade shows, conferences, references, professional networks, internet and research services such as the Gartner Group.

Other means that Omega Airlines used for obtaining information from the vendors were a Request for Information (RFI) and an information session. Omega Airlines used the RFI to gather information from the vendors in order to "size the cost of the software" (Director of Enterprise Systems/IT), among other things. This, coupled with the information session enabled Omega Airlines to determine, among other things, its long-list of vendors.

It should also be noted that the credibility of the source of information was important considering the amount of readily available and often times unreliable information that one has access to. As per Omega Airlines's Project Control Officer, they found Gartner Group to be a credible source of information.

Selection Process

Concurrent to the Planning process, several iterations of screenings (which could be considered as part of the Selection process) were done during the Information Search process prior to arriving at a short long-list of vendors. Selection and evaluation criteria pertaining to both vendors and technologies were used to screen for vendors who could supply the type of software solution that Omega Airlines was seeking.

For the most part, the Selection process began at the point when Omega Airlines received the RFP responses back from the vendors. With the RFP responses in hand, Omega Airlines then proceeded with the paper evaluation of the vendors' packages, that is, they evaluated the responses as they were presented, at face value, on paper. During their evaluation of the responses, Omega Airlines became aware of discrepancies in how the costing was done from vendor to vendor, a problem they attributed to their own lack of clarification. Nevertheless, they proceeded to narrow their selection to arrive at their short-list of three vendors. At this point, though, Omega Airlines asked the three short-listed vendors to re-submit certain parts of their responses, requesting that costing be done along specific lines and that clarification be made on some items. As indicated by the Project Control Officer:

"There was a lot of clarification that had to happen. Obviously, your proposal is never quite what you want it to be. We had to have the three short-listed vendors do things like re-quote because we were not as precise as we should have been, in terms of how we wanted to quote pricing…[this was done] to provide a consistent view so that we could really, truly compare to make sure that we had the same numbers, viewers, same size of user communities. And, of course, every vendor is different—some by users, some by size of mainframe, and whatever."

Once the re-quoted responses were received from the vendors and Omega Airlines had reviewed them, Omega Airlines proceeded to invite the three short-listed vendors to do on-site presentations of their software solutions.

As mentioned above, although the Screening of Information could be considered as part of the Selection process, it occurred during and is commonly understood to be a necessary part of any search for information. During their search, Omega Airlines performed high-level screenings of information to narrow the field of possible vendors/solutions.

So, while it is commonly understood that information screening is done iteratively throughout any process, we are not considering it as part of the Selection process proper, but rather as an integral part of the Information Search process.

Hence, we have chosen to demarcate the Selection process as beginning with the activities following the return of the RFP responses from the vendors. In the case of Omega Airlines, their course of action for the Selection process involved two primary objectives/tasks, those being the evaluation of the RFPs and the formation of the short-list of vendors.

Evaluation Process

There were three distinct types of evaluation that were conducted by Omega Airlines: vendor, functionality and technical. Evaluation criteria for all three types were developed in the Planning phase of the acquisition process.

Vendor Evaluation

The Vendor Evaluation was conducted based on criteria that were established during the Planning process. Each of the vendors was evaluated in terms of its financial stability, reputation, etc., based on Dunn & Bradstreet reports and other information.

Functional Evaluation

Responsibility for the evaluation of each technology's functionality rested with the Project Control Officer while responsibility for the evaluation of its technical aspects rested with the Project Manager – Technical. It is to be noted that the Functional Evaluation proved in and of itself to be an important process for Omega Airlines. It was during the Functional Evaluation that users participated in the decision process. Functional criteria that were established and questionnaires and scenarios that were developed during the Planning phase of the acquisition process were implemented during this process. Short-listed vendors were invited to participate in a two or three-day demonstration of their technological solution. According to Omega Airline's Director IT:

"We then proceeded with demos, three-day long demos with our users. In each case, we had about 50 people (business analysts, project managers, but mostly regular users) who attended these demos."

Technical Evaluation

In parallel with the Functional Evaluation, Omega Airlines "also had a team of technical architects looking at the technical aspect of it" (Director of Enterprise Systems/IT). Most of the technical criteria that had been established during the Planning stage and included in the RFP were now tested with the technology. In addition to this, the Project Manager – Technical utilized a methodology developed by IBM called ‘World-Wide Application Development and System Design Method.’

This allowed them to "work with the vendor to define what the major building blocks" were as well as to identify:

• the major components that were part of their solution;

• the servers, workstations, network components, database management systems, etc.; and,

• the processing of data on each of those

What Omega Airlines's Technical Evaluation team learned provided them with an understanding of the "interplay between the various components, workstations, server, traffic going over the network and what the impact of that would be—‘Is there a lot of traffic?’ and ‘What would the response time characteristics be on a local network versus a WAN?’" The Technical Evaluation team also had to determine:

• the volume of data,

• the volume of processing, and

• the sizing of the various components that were necessary to support all the processing and data that resides on them

In addition to this, the team "looked at the ability of the whole infrastructure, end-toend, to support the availability characteristics. In other words, if I lose a terminal, I lose a line, I lose a router, I lose a server, what would happen and what would I have to do to be able to maintain the availability?" The Technical Evaluation team also looked at the software's security from the standpoint of how it was defined and managed.

Again, many of the above requirements were established during the Planning process and added to the RFP.

As part of their Evaluation process, Omega Airlines used pair-wise comparisons and assigned weights and scores to the various areas of evaluation.

Choice Process

The acquisition process culminates in the Choice process and consists of the ‘final choice’ or ‘recommendation’. The final choice or recommendation that resulted for Omega Airlines, according to the Project Control Officer, "matched the evaluations all the way through."

In addition to the pair-wise comparison that was done in the Evaluation process, a meeting was convened of all of the representatives of the various business groups to see if there was a consensus on which technological solution was the most appropriate for Omega Airlines. A ‘round robin’ format was adopted and each business sector representative was able to review the cumulative scores and present a brief summary of the reasons for their scores. It was during this meeting (which lasted ten hours) that Omega Airlines's Acquisition Teams reached a consensus, though not unanimous—one group, Time and Attendance, felt that SAP met their needs much better than PeopleSoft. Nevertheless, once all of the arguments were presented and the Time and Attendance team members became aware of all of the factors relating to the choice of PeopleSoft, they accepted (perhaps reluctantly, perhaps not) the arguments presented by the majority of the teams. It was also made clear during that meeting that Omega Airlines's management was committed to "bridging the gap in Time & Attendance with PeopleSoft somehow" (Project Director). Hence, they voted for PeopleSoft.

"At the end, in one big meeting of ten hours, we reviewed each area for each business sector. The meeting consisted of twenty-five people, each representing their sector of activity. Each, as we reviewed the evaluations, presented a summary of the reasons for their scores. What we wanted was a consensus from the users…for the decision. With heavy user representation, we would have their buy-in. We wanted each sector of activity to be represented there so that we would have buy-in. We did not have unanimity. We chose PeopleSoft, but for Time and Attendance, SAP was better. …We did not take a formal vote, we just did a final round-table, and I think based on that, we chose People Soft. The person representing payroll said, 'Time & Attendance is much better on SAP, so I vote SAP'. But, when that person listened to all the arguments from everybody, they rallied behind the decision because it was obvious that there were more reasons to choose PeopleSoft than to choose SAP. We said that we will bridge the gap in Time & Attendance with PeopleSoft somehow…[M]y decision…and my recommendation to the team was for PeopleSoft because it gives us the flexibility to change while with SAP, you have to implement SAP as is otherwise you get into big trouble—this is when a two-year project turns into a five-year project if you try to change too much."

"…when that [those] person[s] listened to all the arguments from everybody, they rallied behind the decision because it was obvious that there were more reasons to choose PeopleSoft than to choose SAP" (Director of IT).

It can be noted that the user community had enthusiastically embraced the PeopleSoft product. If the teams had chosen SAP, they would have had much greater difficulty selling Omega Airlines's user community on the benefits of it than with the PeopleSoft product. The Director of Enterprise Systems/IT was very aware of this and believed that it would have been difficult to achieve success without user buy-in and acceptance of the new technology.

It should be noted that while PeopleSoft was the Acquisition Team's choice, it was in fact their ‘recommendation’ as it had to be presented to the Board of Directors for their final approval.

The Choice process that was noted in the Omega Airlines case consisted of one element, a final recommendation or choice. This recommendation was subsequently conveyed to a body outside the Acquisition Team (the Steering Committee [Board of Directors]) for final approval.

As a note about this case regarding the final recommendation, Omega Airlines could have been influenced by the fact that they had previously acquired financial or accounting software from Dunn & Bradstreet (D&B). While Omega Airlines had considered D&B's solution (D&B was on Omega Airlines's short-list of three vendors), the issue of D&B being a former supplier to Omega Airlines did not appear to have had much (if any) impact on their final choice of software solution.

Again, if it had been an issue, in all probability, it would have been dealt with during the Selection process. Moreover, if, as a former supplier, D&B had been more favorably considered, then we speculate that Omega Airlines would have ranked them first on their short-list.

Negotiation Process

Negotiations were pervasive throughout most of the acquisition process. However, there were, in effect, two distinct types of negotiation processes that took place.

The business negotiations were characterized as being informal, while the legal negotiations were characterized as formal. For Omega Airlines, it was the Project Director and the Manager of Capital Equipment Purchasing who conducted the business negotiations. The Manager of Capital Equipment Purchasing was also involved for the signing of the final contract.

According to the Project Director, the objective of the business negotiations was to iron out the "major issues, come to an agreement, and agree on the words to put in the final letter" which they referred to as a "business understanding document". The issues that were negotiated ranged from terms and conditions, implementation, scheduling, performance, to training, etc.

Once an agreement was made with the vendor of choice (PeopleSoft), "the legal people were ready and available to start the legal negotiations process" (Director of IT). The Project Director relates the following:

“… we entered a business negotiation phase as opposed to a contractual negotiation phase. That phase was to agree on all of the terms and conditions that were critical to the business, anywhere from product support to key terms and conditions. The only thing that we did not do there [was] to translate that into legal terms. The objective was to produce a final revised proposal which was what we called a ‘business understanding document’, a letter of a few pages that clarified everything that we had been negotiating…The objective at the end of this was to give them a letter of intent and advise the other vendor that they had lost.

In the process, we visited the vendor on their site and then re-negotiated every term that we thought was critical. That gave us a final price and allowed us to complete our business case. It also allowed us to go to the Board of Directors with the ‘business agreement’, conditional to the Board of Directors' approval, and this way, we did not lose any time. We agreed on dates whereby we could take delivery of the software with some time for some final contract approval. As soon as we got the funding approved, then we went into legal negotiations. That is so much more detailed—looking at terms and conditions and what happens if ‘OMEGA’ buys a company or sells a company or if, the supplier, went bankrupt or all those other possibilities of ownership, escrow agreements; and all of those types of terms and conditions. That allowed us to put together a final contract and then sign it, and we just made it in time to take delivery as agreed to during the business agreement negotiations phase.”

One of the critical issues that concerned Omega Airlines related to the performance of the software on a wide-area network (WAN).

As to how this process could be characterized, it appeared to us that the business negotiations were fluid throughout most of the process. When asked to characterize the Negotiation process, the Manager of Capital Equipment Purchasing replied that "the negotiations were ongoing—it is an evolutionary process", that they start "the minute we begin contact with the vendor", and that they are "fluid" throughout the acquisition process.