Chapter 2 Notes

Chapter 1 – Selecting & Implementing Computer Systems

Content- 2.1 Analyzing current information needs 2.2 Collecting sales information 2.3 Establishing system requirements 2.4 Requesting proposals from vendors 2.5 Contract negotiation

2. 1 ANALYZING CURRENT INFORMATION NEEDS

The Identification, Evaluation and Selection of hospitality technology systems can be complex and time consuming. Many properties appoint a project team. The project leader generally has overall responsibility for purchasing the technology system. This person determines a schedule for the purchasing process and monitors the team's progress. The process begins as the team analyzes the current information needs of the business, collects relevant technology sales literature, and establishes system requirements. The results of this preliminary research are used to formulate a request for proposal (RFP) from vendors. The process continues with the evaluation of proposals and product demonstrations, contract negotiations, and the implementation of the new system. Throughout the process, it is helpful to keep the "nevers" of technology purchasing in mind.

• Never purchase hardware before software. After selecting software first, identify the hardware it requires.
• Never make a purchase decision based solely on cost. Too often, economic factors are given a disproportionate weight in the decision process.
• Never lose control of the purchasing process. Develop request for proposal documents, script on-site vendor demonstrations, and apply uniform criteria when evaluating vendor proposals.
• Never rely on enhancement promises. A system feature that is advertised, but not yet available for sale may not actually become available for some time.
• Never be the first system user. New systems have no operational history and, therefore, are difficult to evaluate.
• Never allow technology to dictate operations. Changing operations to fit the demands of the technology is reverse logic (i.e., the tail wagging the dog).
• Never be the largest system user. Pushing the capabilities of a system's processing speed, file parameters, memory capabilities, and other functions may lead to a series of problems, many of which may not be resolved in a timely manner.
• Never be the last system user. System maintenance, ongoing technical support, enhancements, and the like may be difficult or impossible to obtain once the vendor has abandoned the product.
• Never allow a vendor to rewrite the business's technology requirements. A system that meets vendor specifications may not meet business needs; the focus must be on business needs.

Information Needs

The first step in analyzing the information needs of a business is to identify the types of information that various levels of management use in the course of operations. This can be done by compiling samples of reports presently prepared for management - for example, the daily operations report, basic financial statements, and reports. Once collected, the reports can be analyzed in relation to such variables as purpose, content, distribution, and frequency.

Report analysis identifies the types of information management uses, but does not necessarily reveal the information needs of the business. A separate survey needs to be conducted to evaluate the effectiveness of the format and content of current reports. Survey findings can provide the basis for immediate improvements in the information system and enable a more in-depth analysis to include flowcharts and a property profile.

A property profile compiles statistics about the installed information system. The types of categories and number of individual entries will vary from property to property. A property profile can be invaluable when communicating information needs of the business to system vendors. A well-designed property profile allows vendors to compare the property's information needs to those of similar properties. In addition, a property profile enables management to conduct a more informed and efficient review of technology sales literature.

2.2 COLLECTING SALES INFORMATION

Sales Literature

After creating a property profile, management should collect sales literature on a variety of technology systems that meet the general information needs of the business. Literature collection can result from:

• Sending inquiries to state and national hospitality trade associations.
• Attending hospitality industry trade shows.
• Visiting local technology system suppliers
• Conducting online searches for hospitality technology vendors

Trade associations and other organization regularly sponsor state, regional, and national trade shows. Attendance at trade shows typically places management in direct contact with hospitality technology vendors.

Management can also secure product information by visiting local system suppliers. This approach can be time-consuming and may not provide a representative view of the range of products on the market.

Perhaps the most effective approach to fact-finding is to use the information obtained from trade associations, attendance at trade shows, and visits to local vendors to formulate a general interest inquiry to be mailed or e-mailed to vendors of hospitality technology systems. This can be an efficient means of securing necessary information on various system solutions. Management may also choose to use broadcast mailings to secure more specific information, such as:

• Hardware documentation
• Software documentation
• Netware documentation
• Lists of installed users
• Sample report formats
• Sample training materials
• Suggested training and implementation scheduling
• Annual financial statements of the vendor’s business
• Purchase/lease options
• User support and maintenance programs
• Sample system contract

Gathering this information early in the process may prove valuable later when standardizing the response form that selected vendors will be required to complete when submitting system proposals to management. Before formulating the issues and categories of responses that will appear on the request for proposal document, management must analyze the needs of the business in light of the sales information collected.

2. 3 ESTABLISHING SYSTEM REQUIREMENTS

Having analyzed the business's information needs and collected relevant sales literature, management's next step is to establish system requirements. This does not mean that hospitality managers must become experts in technology system design. Instead, management must be able to identify critical elements such as:

• Determining what data needs to be processed
• Establishing how that data will be processed
• Indentifying how processed data will be stored and reported.

Determining what data to process involves identifying the information tasks that can best be performed by the automated system. Management must carefully weigh what is to be gained through technology. Will automation improve guest services? Will it increase operational efficiency? Will it enhance management's decision-making effectiveness? Other factors to consider when determining which data to process include the ease of identifying, collecting, entering, and coding data. These factors are essential to the timely processing and output of information.

Determining how data is to be processed is a matter of ensuring that the algorithmic design of the software programs corresponds to the formulas management prefers. The term "algorithm" refers to a prescribed set of well defined, unambiguous rules or procedures leading to the solution of a problem. Too often, management assumes that hospitality industry jargon, such as "occupancy percentage" and "food cost percentage," means the same thing to all system designers. The truth is that hospitality properties differ in terms of the variables incorporated into these calculations.

In order to ensure that the selected system will process data according to the property's standards, management should survey individual operating departments seeking detailed explanation of how formula variables are to be handled. This master list of formulas and the accompanying explanations identify major system requirements that vendors need to address when submitting a proposal to management.

Determining the formats in which processed data will be output as information involves decisions that may change the structure and style of current business forms, guest folios, guest checks, management reports, and other materials. The information needs of the business and the format preferences of managers should dictate the choice of the system's output capabilities.

2. 4 REQUESTING PROPOSALS FROM VENDORS

After translating information needs into system requirements, management is ready to request a property specific proposal from industry suppliers. A request for proposal (RFP) is typically made up of three major sections. One section informs the vendor about hospitality business operations; a second section establishes bidding requirements for vendor proposals; and a third section deals specifically with user application requirements.

The first section of the RFP should contain an overview of the hospitality business, list objectives and broad operational requirements for the system, and briefly outline the scope of vendor relations and support services. The overview of the hospitality business should include a detailed property profile based on its information needs. Listing objectives and operational requirements for the system offers management the opportunity to identify and designate particular system features as mandatory or optional, thus assisting vendors in the preparation of responsive proposals. An outline of the vendor's responsibilities should include the proposal submission deadline and should encourage vendors to submit as much information as possible relative to such areas as:

• Network configurations.
• Application descriptions.
• Maintenance and support services.
• Installation and training programs.
• Guarantees and warranties.
• Payment plan options.
• Future expandability of the proposed system.

The second section of the RFP establishes bidding requirements for vendor proposals. Allowing vendors to formulate bids using a proprietary or arbitrary format will force management into using an unstructured evaluation process. All proposals should be submitted in a standardized response form supplied by management to facilitate price and performance comparisons. Note that structured formatting enables management to conduct comparisons between proposals using a common set of dimensions. Vendors should also be required to include a statement of financial history and stability. The final section of the RFP needs to address specific system application requirements. RFP form that structures vendors' responses to application requirements. Since all vendors are required to use the identical response format, management will be more efficient in evaluating competing proposals. Once created, the RFP (printed, electronic, or online) is distributed to the vendor community for response. After receiving an RFP, most vendors will contact management and conduct a site survey.

Site Survey

After receiving an RFP, vendors typically contact the property to perform a site survey. The purpose of a site survey is to allow the vendor to better understand the specific business operations of the property that may affect system design. The physical parameters of a property help determine appropriate types of hardware and network configurations.

Evaluating Proposals

After conducting a site survey, the vendor completes a system proposal and submits it for consideration. While there are many ways to evaluate a proposal, a multiple rating system can be an efficient and effective method.

A multiple rating system applies the same criteria to judge the worth of each vendor's proposal. Generally, the criteria consist of several issues that management considers critical to the business. Management then rates the vendor's response to each issue on a scale from 1 to 100. The higher the rating, the better the proposal is deemed to address the issue. Since some issues will always be considered more important than others, simply totalling the ratings on key issues may not necessarily identify the best system proposal. In order to identify the best proposal, management must rank the issues in the order of their importance. This can be accomplished by assigning a percentage value (or weight) to each criterion, denoting its relative importance within the overall evaluation scheme. The ratings for each issue are multiplied by their appropriate percentage values and then totaled to yield an overall score for each vendor proposal. The proposals receiving the highest overall score identify the vendors with whom management should seriously consider scheduling product demonstrations. The following example illustrates how a multiple rating system can be used to evaluate proposals from three different vendors.

Vendor Product Demonstration

A product presentation is intended to allow management to view, first-hand, how the proposed system components operate to achieve the promised results. In order to control this process, management should consider using a scripted demonstration format.

Scripted product demonstrations (scripted demos) prevent vendor presentations from becoming a confusing show of "neat system tricks." With scripted demos, management provides each vendor with a script indicating which applications to demonstrate, ensuring that the session addresses features relevant to the business. This approach also provides a standard to ensure that every demonstration covers the same functionality.

2.5 CONTRACT NEGOTIATION

Before entering into contract negotiations with a vendor, management should secure copies of several standard contracts used by vendors of hospitality technology applications. These standard contracts are typically written in favour of the vendors and may not provide the kind of protection that the business may require. Management should examine these contracts carefully and obtain legal advice from a qualified attorney. If the attorney has no working knowledge of technology applications, management may also need assistance from an experienced technology applications consultant. In any case, the standard contract offered by a vendor serves as the starting point for contract negotiations. Since the actual sale has not yet been completed, management (the buyer) maintains a great deal of leverage in negotiating changes to the vendor's standard contract.

Contractual Arrangements

In relation to hospitality technology, there are several types of contractual arrangements. Three common agreements are:

1. Single-vendor contracts.
2. Multi-vendor contracts.
3. Other equipment manufacturer (OEM) contracts.

A single-vendor contract refers to an agreement to purchase hardware software, and NetWare from the same vendor.

In most cases, the vendor makes the necessary hardware, software, and NetWare modifications before system implementation. A single-vendor contract clearly identifies the vendor's responsibilities in relation to system performance and security and avoids the kind of confusion that may arise in other contractual arrangements when the lines of responsibility are not so clearly defined.

A multi-vendor contract refers to an agreement to purchase system components from more than one vendor. The hardware components may be purchased directly from the manufacturer or purchased through a software vendor, who serves as a value-added reseller. In either case, the hardware components or the accompanying operating system may require modifications by the software provider in order to perform effectively. Similarly, network features may require modification based on hardware and software specifications.

An other equipment manufacturer (OEM) contract refers to a situation in which a business agrees to purchase hardware, software and NetWare from a single source and the single source takes responsibility for the performance of the technology application. OEM contracts generally involve purchasing a complete system that arrives at the property ready for installation. This kind of contractual arrangement provides a business with the equivalent of a single-vendor contract, as all hardware, software, and NetWare customization is performed by the OEM.

Installation Factors

After completing contract negotiations, management must make final decisions on such installation factors as:

• Training.
• Site preparation.
• Design of materials.
• Initial entry of database elements.
• Acceptance testing. • System conversion. • Documentation.
• Contingency planning.
• System security and data privacy.

The following sections discuss each of these installation factors.

Training

Training should begin before installation and continue throughout the implementation process. The primary users of the system will be those individuals responsible for data entry, report generation, and system maintenance. These persons should begin active (hands-on) training with hardware components and software applications before installation. Training sessions are normally conducted by vendor staff members or vendor representatives using manuals, books, CDs, DVDs, video, web, and other media.

Site Preparation

Site preparation refers to architectural or engineering changes that must occur before an automated system can be installed. The extent of these changes depends on the size of the property and the kind of technology being installed.

Design of Materials

Details regarding any printed materials output or used by various applications must be resolved before implementation. This is also true of guest-related touch point applications (a touch point being any area of the business with which the guest interacts). Lodging properties may choose to design both printed and electronic formats for reservation confirmations, website interfacing, broadcast mailings, guest folios, may be redesigned for food services businesses include guest checks, broadcast, mailings, menus, promotional materials, and management reports.

Data Entry

Before system installation, management and vendor representatives must develop a plan for data entry that will populate the application database. This is a critical area of technology planning that often is overlooked. Once the system is installed and implemented, the content of the database is necessary to define the scope of potential applications.

Acceptance Testing

Before adopting or upgrading an application, management should conduct extensive acceptance testing of the candidate technology. Acceptance testing involves more than simply checking whether the application works. Tests should be developed to determine whether automated operations function according to standards defined by management. Fundamental areas of acceptance testing include:

• Hardware efficiency.
• Software reliability.
• Data integrity.
• Network security.

System Conversion

System conversion is the process of transitioning from an installed (legacy) system to a new system. System conversion within a hospitality operation can be difficult and trying. Two commonly used conversion strategies are parallel conversion and direct cutover conversion.

Documentation

Adequate system documentation for each component is critical to the success of system operations beyond the initial training period. Documentation is essential for ongoing training of staff and for identifying underused system capabilities and possible weaknesses within the system design. The three most important forms of documentation, whether they be available in printed, electronic, or online format, are the operator's guide, technical manuals, and system flowcharts.

Contingency Planning

The purpose of contingency planning is to define procedures that are to be followed when an automated application does not function properly. Contingency planning is an important aspect of technology implementation.

System Security and Data Privacy

Proprietary guest information and operational statistics are among the most valuable assets that a hospitality property can possess. Paper and electronic records are subject to physical damage from fire, flood, and so forth. Electronic records may also be vulnerable to threats that aren't as visible, but can be just as devastating as physical threats. The flexibility and interconnectedness that make networked systems so valuable also make them subject to internal and external threats, both deliberate and random.