Myth 1
Procure hardware before application software.

Assumption: Securing the hardware components of a system as a first step will assist hospitality management by simplifying architectural, electrical, network and related installation expenditures, thereby enabling more precise project cost estimation and implementation scheduling. Securing system hardware first also helps generate staff excitement and may contribute to promoting guest-related interest.

Truth: Procuring system hardware before application software is a sure fire path to disaster! It is difficult to search for preferred software after system components have been specified. In fact, hospitality managers tend to complain more about seeking compatible software for installed hardware than nearly any other technology problem. Inevitably, questions will surface relative to hardware support and/or operating system compatibility with application software. Management must exercise care in this area and is wise to shop for application software first, hardware second. This situation is especially likely to arise when searching for a new property management (PMS) or point-of-sale (POS) system, or when management personnel change and the new staff desires to update the installed software without having to replace existing hardware. Such a search is similar to trying to locate 8-track tapes when the hospitality’s stereo equipment consists of an 8-track tape player. Since modern recordings are packaged onto CDs, the search for a conforming format will be difficult, if not impossible. The same will be true when trying to run a Windows 7 application on an antiquated DOS-based PC platform.

Scenario: Assume hotel management is reviewing several hardware vendor advertisements and determines that a MAC possesses numerous desirable data processing features and is available in a color that fits well with the front office decor. Once management purchases the MAC hardware, next it will have to begin searching for compatible hotel front office software. This is the time when major selection problems are likely to arise, assuming there are a few front office software modules that run on a MAC.

Best Practice: Best practice dictates identifying application software first and compatible hardware second. As mentioned, a similar situation may arise when management strives to replace the currently installed application software only to discover that later versions of the software are not compatible with legacy hardware. At some point management should consider the replacement of installed hardware. Such a search can be painstaking, costly and nonproductive.
Adage: “Without compatible, quality software, computer hardware makes a great…plant stand.”

Myth 2
Hospitality IT requirements are oversold.

Assumption: Hospitality system supplier representatives are compensated on a paid commission-basis and therefore will seek to oversell system components and features that may not be necessary. In an effort to increase personal earnings, vendor salespersons are likely to propose more hardware components, software modules and peripheral devices than are warranted. After all, it seems only logical that the more components sold, the higher the commission earned.

Truth: More often than not, hospitality technology tends to be undersold, not oversold. When a system is undersold (i.e., fewer than necessary components, programs or services are included) its bid price will be comparatively lower and hence the vendor may enjoy a competitive advantage when management reviews system price quotes. While on the surface this may not appear to be a smart approach to system design, consider that once a system is installed, it is more economical to add to it than to replace it. In other words, a low-bidding vendor is confident that once management selects and installs the undersold system, it is not likely to displace the system once it realizes additional components are warranted. A hotel or restaurant that selects a system primarily based on low-cost criteria may award the bid to a vendor that derived a somewhat arbitrary cost based on an inadequate system design. While this can happen by accident, often management fails to connect the initial system bidding process with the subsequent purchase of additional products necessary to render the system capable of fulfilling desired outcomes. Management should exercise caution in a competitive bidding environment.

Best Practice: Use a request for proposal (RFP) approach to the technology marketplace. An RFP requires that management describe its operational processes, automation needs and various parameters (number of covers, waitstaff, transactions, workstations, etc.) so that a qualified vendor can propose a solution that thoroughly addresses information technology requirements.

Through the development of the RFP document, the property performs a self-assessment to communicate comprehensive knowledge of operations. Vendors are given specific instructions of response to guarantee that required functions are properly addressed and that costs of each are itemized. Managers need to be familiar with the RFP process and inform candidate vendors that responses will be connected to a system contract. In other words, whatever stipulations the vendor includes in response to the RFP, those stipulations will become part of the eventual system contract. This procedure encourages vendor representatives to propose realistic, functional system designs while discouraging artificial underselling.

Adage: “It is better to expand an installed system than to remove the system and begin anew.”

Myth 3
Trust your vendor to manage the purchase process.

Assumption: Since hospitality system vendors are more experienced with technology than the average property manager, it is best to select a vendor that can help guide the purchase process; the vendor will keep management informed as the process progresses and develop a sound budget and implementation plan.

Truth: Management needs to actively participate and control the purchase process. A process that is not controlled is considered out of control. While vendors can be excellent partners in technology implementation, the goals of hospitality management and the system provider tend to be different.  When management delegates and/or loses control, many wasted hours and unnatural delays in system installation, training and testing are likely to occur. Such results often arise out of confusion and distraction. A popular and effective technique for controlling the purchase process from the beginning is to adopt a scripted demo approach. The basic concept of a scripted demo is for management to provide candidate vendors with a set of specific transaction scenarios for which the potential application (or system) will be used to resolve during a product sales demonstration (e.g. self check-in, split tendering, separate checks, etc.).

As the controlled vendor demonstration progresses, management will direct and expect the vendor to illustrate the application’s handling of the specified transactions. This technique forces the vendor to focus on features that are important to the hotel or restaurant, as opposed to the features deemed important by the vendor. Since most technology product presentation sessions tend to become an unfocused collection of neat system tricks that bolster the vendor's confidence, they often tend to frustrate the potential purchaser. As the scripted demo session progresses, it is advisable that management suggest alternative transactions to those previously scripted. By changing the prescribed scenarios on the fly, management can keep the vendor actively involved while ensuring the demonstration has not merely become a preprogrammed simulation of the desired scenarios without actually developing them in a live state. Following a scripted demo session, successful vendors will be informed that they will be invited back for a follow-up demonstration in which they can show any product or system feature not revealed during the scripted session. Scripting transactions that are typical for a specific hotel or restaurant enables management to better determine which product or system can best fit current operations as opposed to having to modify operations to fit a specific vendor system.

Scenario: Assume a restaurant is contemplating the procurement of a new POS system and identifies four candidate products. Each vendor is contacted and informed of management’s interest. Management provides each vendor with a copy of its main dining room menu and instructs the vendor to program the menu into the candidate POS system for an upcoming product demonstration session. In addition, management formulates (scripts) a dozen scenarios that typify POS transactions at this specific restaurant (e.g., gift cards, mobile payments, daily specials) and sends the scripts to the vendors. Giving each vendor 90 minutes to present their system’s handling of the provided scripted transactions, but that management reserves the right to change scenarios on the fly during the session. The goal is to place management firmly in control of the purchase process. Those POS systems that handle the scripted scenarios best are identified as finalist candidates and invited back for an unscripted demonstration session. The implementation of a sequenced scripted and unscripted session has been shown to be highly reliable and advantageous.

Best Practice: Best practice dictates that a scripted demo approach should be followed. During vendor product demonstrations, management must direct and control the sessions. Additionally, management should require the vendor to use hardware components, application software and peripheral devices referenced in the vendor’s proposed system configuration during the product presentation. Emphasize to the vendor that transaction scenarios are to be demonstrated one at a time, in a specified sequence (i.e. scenarios should not be modified or re-arranged or re-organized in any manner). Advise the vendor that each vendor representative should be technically and operationally competent as scenarios will likely be changed on the fly during the demonstration session. Encourage each vendor to perform a site survey prior to product presentation to ensure familiarity with hospitality operations. Lastly, inform vendors that finalists who successfully pass the scripted demonstration stage will be invited back for a second product discussion in which the vendor may demonstrate any additional system features which the scenarios failed to illustrate. A second visit ensures the vendor a more serious and interested audience while providing an opportunity to establish product differentiation among competitors.

Adage: “If you do not control the purchase process, it will control you.”

Myth 4
Promised IT features will always be delivered.

Assumption: When an important hospitality system feature is discussed with a vendor’s representative, often that feature will be included in the hardware functionality or application software modules and be readily available for use with promised capabilities. Systems capabilities typically function as described during sales/marketing discussion and presentation sessions.

Truth: Sometimes system features that are important to management (deal makers/deal breakers) may not always be part of an acquired product or system. The techno-term for this situation is vaporware. Vaporware is used to explain the seeming disappearance of promised functionality, capabilities that appear to have evaporated from the system toolbox. 

Scenario: Assume management seeks robust frequent diner software as part of a replacement POS. During the purchase process, the system representative described the system’s frequent diner software as a major competitive advantage and provided persuasive testimony that convinced management to make the system its preferred selection. Before, during and after POS installation, management sought to learn more about the inherent frequent diner software. Documentation was reviewed, installed hospitality users were contacted and online support technicians were consulted. All of which led management to conclude that the desired capability, as described during the sales meetings, was missing from the implemented POS system. Despite the fact the system decision hinged on this featured application software, it became apparent that the vendor’s promised “robust” frequent diner software did not exist. Since management did not require the vendor representative specify in writing that the frequent diner software would function as described, there was minimal recourse. Although the frequent diner software was initially considered a deal maker, the installed POS system would not likely be removed given the installation, training and architectural changes associated with implementation. Care must be taken to require that all desired applications be reduced to writing and included in the application software section of the RFP as well as the eventual system contract. One technique that is helpful is to adopt an RFP template that contains three response columns relative to system components and features: Available now as described, available but different than described and not currently available. This approach ensures that competitive RFP responses are evaluated on a comparable basis while placing eventual contractual constraints on the successful vendor.

Best Practice: Best practice dictates using a request for proposal (RFP) format that forces candidate vendors to respond to capabilities within deliverable timeframes, and using the three reply categories described above forces vendors to respond directly relative to each proposed application.

Adage: "Vaporware is the number one selling system product.” Since vendor representatives tend to promise system capabilities before the engineering department has perfected them, hospitality management is wise to force the vendor to qualify an RFP response, on a time certain basis, knowing that RFP responses will be part of the eventual system contract.

Myth 5
Being an early adopter is advantageous.

Assumption: Installing an innovative, new product or application can provide cost savings and productivity enhancements and therefore it is best to be among the first hospitality businesses to implement the product or application. From a competitive advantage perspective, being first means being best!

Truth: There are long-established technology rules of thumb: 1) never be the first user of any product or application; 2) never be the largest user of any product or application and 3) never be the last user of any product or application. For early adopters there simply is no benchmark upon which to judge an application’s capabilities since there are no prior observations. Additionally, as management struggles to effectively control the system selection process, an unproven application can pose challenges that become dysfunctional to operations. The reason management should be hesitant when considering becoming the largest system user is due to the fact the hospitality property will constantly be testing system boundaries, file sizes and other parameters of the system. Stretching such capacities can be harmful to data processing capabilities should such limits be reached or exceeded and system functionality is compromised. For example, an application that works well at a 160-room property may not support the higher demands encountered in a 1,500-room property. It is best to identify an installed system at a hotel or restaurant with similar parameters (staffing, transaction volume, hours of operation, etc.) than to be the biggest system user that likely tests the system’s capacity management. Similarly, when a hotel or restaurant becomes the last user of a system, this implies that the vendor has left the industry and therefore the support network and future development base is thereby significantly weakened.

Scenario: Assume a restaurant purchases an innovative wireless POS system. Given that this will be the system’s first installation, there is little confidence that beginning cost estimates will be reliable. Architectural decisions, network constraints, communication linkages, signal quality and related issues may well be ongoing as the vendor strives to implement an unproven, unique system in a precarious environment. Once installed, concern may shift toward unexpected and/or unexplained operational problems or system glitches. 

Best Practice: Avoid being the first, largest or last application or system user. Considered requesting a list of installed users and comparative measurements of business parameters prior to considering adoption.

Adage: “Never be the first, largest or last user of any product, application or system.”

Myth 6
Proprietary systems are the most desirable.

Assumption: When seeking a complete, end-to-end system, several facets of negotiation, contracting, support services and future developments are simplified when a technology provider is the sole source for hardware, software, firmware and peripheral devices. The association of products and processes may be built on a proprietary platform unique to the vendor and not built on an open industry standard. Dealing with a single vendor, even if the system is proprietary, is advantageous from a system component compatibility perspective.

Truth: By definition, a proprietary system, often referred to as a vanilla system or closed system, is one that is constructed based on exclusive, private parameters, protocols and peripherals. The technical specifications of a closed system include components and core applications are not divulged. With a proprietary system, management is obligated to deal with a specific vendor, regardless of how strained the relationship, and is typically provided a limited set of feasible alternatives. On the other hand, an open system allows management to shop for hardware, software, and netware components from a range of compliant products that can be placed in a configuration to produce a compatible, workable solution. Most often, a non-proprietary system is described as incorporating a best-of-breed technology approach as management is able to select applications based on desired outcomes and not limited by a single vendor’s offerings. It is for this reason that open systems are often the preferred methods of operation.

Scenario: Assume a proprietary restaurant POS system is purchased and installed. It may not be long before management seeks additional supplies, hardware and/or software components. When searching for compatible products, management will quickly learn that there is only one source of supply, but an open architecture system in which hardware, software and netware would be immediately compatible (akin to plug and play). While hospitality industry-wide standards have existed for some time relative to compatibility and/or integration, there are vendors that continue to offer proprietary system architecture. Precautions should be taken to consider the differences between open and closed system design.

Best Practice: Best practice often dictates selecting a non-proprietary system, especially when system flexibility is desired. Open system architecture can solve many operational problems while providing management with an array of hardware, software, peripheral and network options. How can a hospitality enterprise determine if a system vendor is promoting a proprietary application or system? One way is to inquire as to whether the application software can be purchased independent of the hardware. An affirmative response indicates the product is non-proprietary and a more open choice as the hardware can be procured from various alternate sources thereby not tying the property to a single source. Plug and play is one of the key goals of non-proprietary systems. In addition, a best-of-breed application allows management to select preferred software modules and application features from among a variety of system suppliers. For example, consider configuring a best-of-breed network involving a back-end accounting application from one vendor, a POS system from a different vendor, and a tee time scheduling package from a third vendor. So long as these applications adhere to industry interchange standards, then a best-of-breed system can be gained. This approach allows management to select and install the most appropriate hardware, software and netware for each individual application area, regardless of vendor source.

Adage: “When you select a proprietary system, you become artificially dependent and restricted to a single vendor.”

There are few industries that implement technologies as intricate as those installed in the hospitality industry. A large hotel, for example, may rely on as many as a dozen different system applications, many of which, by necessity, will require interconnectivity. Given the inherent complexities associated with hospitality information systems, it is important to be mindful of hospitality technology myths so as to avoid the pitfalls so often encountered when seeking to identify, procure, install and operate technology solutions.