GDS DATA BASE MAINTENANCE: THE NEVER-ENDING CHALLENGE – PART 1

H & A Report May/June 1997

Sixty million roomnights — that is the estimated hotel booking production by Global Distribution Systems in 1996. GDSs now deliver a significant proportion of hotel reservations. Any hotel company hoping to secure some portion of those roomnights is required to list extensive rate, description and availability information in a minimum of four systems – AMADEUS, Apollo/Galileo, SABRE and Worldspan.

For many hotel companies achieving the goal of up-to-the-minute information accuracy in each GDS is a struggle. In this first of two articles, I will chronicle the evolution of the GDS data maintenance process. The second article (which will appear in the next H&A Report) will identify both the current technology and emerging options and will profile several significant update technology choices.

The task of timely data base maintenance has become considerably more difficult since hotels first became available for booking by travel agencies in GDSs, about twenty years ago. Both the breadth of property information displayed, and the proportion of it which is highly volatile (particularly rate and availability data) have grown markedly. And we as hoteliers must accept considerable responsibility for this growth.

Initially the GDSs stored a limited number of rates and room types, 5 to 8 of each was the rule, and revisions were relatively infrequent. Data entry generally took place within a few hours, or days at most, of information receipt. The exception was the annual entry of the following year’s rates, when the entry time lengthened to several weeks. Despite the fact that the central reservation system plus Apollo, Datas II, Gemini, PARS, SABRE and System One (as well as additional systems in some cases) all had to be maintained, the update traffic could be dispatched manually, without serious delays.

Over time, however, the hotel industry pressured the GDSs to expand their data bases, to achieve full product presentation and to gain competitive advantage. We urged data base expansion to accommodate unlimited room types, unlimited numbers of rates, unlimited negotiated rates, complex rules of sale, and even packages. The result is that we now find ourselves in an environment where revisions are constant and even relatively “static” data is subject to frequent amendment.

To understand the challenge of timely GDS data maintenance, it is essential to bear in mind that the GDS update process is highly complex. While one might initially assume that the same techniques and technology would function for all GDSs, the truth is that each system has developed its own procedures and pathways. The result is that there are as many differences at the detail level as similarities. Specific techniques for four or more individual systems must be mastered by GDS data base maintenance staff.

Growth in the number of updates was driven by a combination of two factors. The first was GDS productivity growth (eventually matching or even exceeding 800 service volumes) which in turn drove interest in presenting accurate and compelling property information, to capture market share. Second, implementation of revenue management techniques compounded the problem by generating numerous and frequent data revisions. To combat fast-growing update backlogs, hotel companies looked to three groups: their in-house MIS departments, the GDSs and third party technology vendors. Not unusually, progress came in waves.

IN THE BEGINNING…

In the earliest years of hotel listings in the GDSs, the update process was entirely manual. GDS terminals were installed in central reservation offices and all data changes, including those to availability, were entered by hand. The process used was akin to telex traffic and the priority assigned to non-airline messages was low, sometimes resulting in oversold situations.

The first major step in automating the update process was implementation of Type B electronic availability updating. The most time sensitive and numerous, availability updates were in many respects the simplest to automate. Central reservation systems were enhanced by hotel company MIS staff to create update instructions for each GDS whenever the CRS’s availability data base was itself updated. These instructions were in turn automatically communicated to each of the GDSs, either through dedicated circuits or through the ARINC network. By the late 1980s all major GDSs accepted “AVH” availability updates.

 MAGNETIC TAPE UPDATES

Automation of the availability updating process through AVH messages eased the update load temporarily, but the pressure of growing volumes of updates to rates and property descriptions remaining to be manually entered into each GDS continued to build. An early answer was the preparation and weekly delivery of magnetic tapes, but their use was confined to several large hotel companies and just two GDSs.

In this process updates made in the CRS data base were copied to an off-line queue (using the same queuing approach as the AVH updates) then transferred weekly to a magnetic tape for delivery by courier to the GDS. There the tape was mounted and the data copied to the GDS’s data base. The precursor of approaches which would receive widespread implementation a decade later, magnetic tape updating met with limited utilization.

SWITCHES

Activation of the THISCO and WizCom International GDS switches facilitated the update process further. While principally intended to facilitate reservation processing, these switches provided their users connectivity to all GDSs via a single circuit. In doing so, they substantially reduced the on-going programming effort required to maintain individual, customized reservation and update links to each global distribution system.

THE SECOND WAVE – ROBOTICS AND OFF-LINE TRANSFER

Once availability messages were being distributed to the GDSs quickly and with few, if any, errors, attention turned to the feasibility of automating the rate updating process. Changing existing rates, adding new rate seasons and establishing new rate codes were, by comparison with the availability updating process, immeasurably more complex.

As the challenge of timely data entry became steadily more difficult, the initial response was typically to add more data entry staff. This, however, was far more difficult to accomplish than appeared on the surface. The diversity of systems and procedures resulted in a long learning curve before update proficiency was achieved. The intensity of the work often resulted in employee burnout after two to three years. The entry process was slow, even for system experts, and the economics of installing multiple terminals for each system were not attractive.

Two initiatives attempted to solve the problem. The first involved robotics technology borrowed from the airline industry while the other built on the off-line data accumulation and transfer efforts used previously to prepare magnetic tapes of update data.

In a 1988 program jointly introduced with Utell International, Nick Lanyon and his team at Lanyon, Inc. launched the first generation of terminal emulation technology for hotel data maintenance. Utilizing a communication co-processsor board and proprietary software originally designed for the airline industry applications and further customized to each GDS’s operating environment, the Lanyon rate update product – labeled Lanyon-RATE – electronically mimicked the data base clerk’s keystrokes.

Hotel companies using Lanyon-RATE modified their CRS to automatically copy all changes to their CRS rates into an off-line queue. The Lanyon product, which was installed in a stand-alone PC, then emptied the queue. Utilizing the same commands that would have been typed by a data entry clerk and the same GDS circuit, it robotically transmitted update messages to the GDS.

Developed in a DOS environment, Lanyon-RATE was not without its shortcomings, some of which were imposed by the hotel company CRSs with which they linked. Data deliveries were largely restricted to updates of currently loaded rate seasons and rate types, rather than communication of new seasons or other data. Further, the data processing capacity of the technology environment in which the Lanyon product functioned occasionally resulted in congestion when very large files, especially rebuilds of entire hotel rate files, were attempted. Nonetheless, Lanyon-RATE represented a giant stride forward and bought an important, and much needed, breather for many hotel companies and their GDS data base administrators. Lanyon-RATE is today the most widely used robotic rate update technology in the lodging industry.

In tandem with the terminal emulation initiative came development of bulk data update functions by the GDSs. Off-line collection of CRS updates, specifically-reformatted to each GDS’s specification, served as the first step in periodic electronic transmission of the data over the same dedicated circuits used for the GDS terminals. While the initial efforts were halting, and the number of participants limitd, bulk data update technology has gained slow but steady acceptance, as the flexibility of the update capabilities has steadily grown. Today the bulk data update capabilities of the GDS are extensive, as indicated in Figure 1.

Figure 1. GDS Bulk Update Facilities

The range of GDS updating options is today expanding more quickly than at any time in the past. The choices include new vendors, new software-only tools and robust multi-product integrated suites, which offer single-stop updating capabilities. The next article will identify the options available for global distribution system data maintenance and focus on several of the especially innovative products