Cover Image

Not for Sale



View/Hide Left Panel
Click for next page ( 24


The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 23
Best Practices for Integration 23 Figure 3-6. Step 4. Step 4: Define Success and How to Measure It Figure 3-6 indicates the level of effort of the stakeholders for this step. One of the keys to success in an integration project is first creating the definition for success for the project. The middle managers will create the overall definition for success. This definition draws on the priorities defined in Step 1, Define Business Objectives and Identify Information Needs, but should consist of measurable items. The data owners defined in Step 3, Determine Who "Owns" the Data and Identify the Systems, will be responsible for the data and the integrated system and will eventually drive the reporting. Thus, they are the best people to define success for their individual data and systems. Examples of successes at this level Reducing the delay before a particular piece of information is available and Increasing the accuracy of a piece of data. After the successes are defined, create a plan to measure success. This plan should detail, for each individual system or piece of data, how to test the integrated system to measure success as defined by the stakeholders. Create the plan at this step in order to drive the rest of the integration process. The plan will be revised as new information comes to light in future steps, but changes to the plan should be reviewed to ensure that such changes are consistent with the overall priorities of the project. Case Study Step 4 Because a major goal for the airport was to reduce the airlines' cost, the overall success would be measured by a reduction of the average cost per enplanement. The team decided that this overall success would be achieved by reducing the unneces- sary staff time spent correcting errors in the data, entering data more than once, rebilling tenants, and re-calculating the rates and charges as data was updated. The team defined one of the measures of success as: "Successfully integrating flight data and airport-generated passenger counts, resulting in decreased reliance on airlines' self-reporting." This would also support the airport's overall goals by reducing the cost of auditing and bad debt write-off. Based on the Project Manager's esti- mates of the potential reduction of cost after the successful implementation of the integration, the CFO and CEO agreed that the project should proceed. Step 5: Define All of the Business Rules Figure 3-7 indicates the level of effort of the stakeholders for this step. Data alone do not tell the full story of any large enterprise, especially an airport. Airports deal with complex contracts that drive complex business rules, and understanding these rules

OCR for page 23
24 Integrating Airport Information Systems Figure 3-7. Step 5. is pivotal to the integration process. The business rules for an organization help describe how it goes about achieving its goals and the restrictions that apply. For the integration effort to be successful, the business rules that apply to the data being integrated need to be thoroughly understood and documented. Although the integration effort might involve multiple complex processes, only the business rules that pertain to the pieces involved in the integration effort need to be collected. An airport's use and lease agreement delineates the space and facilities leased by a particular airline, as well as the rights and responsibilities to use the public and common-use space and airfield facilities. Additionally, rates, fees, and charges can be calculated in accordance with a rate- making methodology contained in or referenced by the use and lease agreement. The contracts might also vary from customer to customer, which further increases the complexity. Under- standing and documenting these business rules can save an airport millions in the purchase of expensive software that does not fit the airport's complex contract structure. The following is an example of a business rule related to airline contracts at an airport: A few individual airline agreements provide incentives to attract aircraft maintenance work to the air- port. Some of the airline agreements call for not charging for the landing fee related to mainte- nance ferries, provided that the aircraft does not occupy a gate or carry inbound passengers or cargo. The agreements further provide that these ferries would be noted on the carriers' monthly reports. The resulting business rule was that airport staff will normally deduct the weights of these landings from the airlines' reported total gross landing weight before billing the airlines for the standard fee. After the rules are clearly defined, some airports bring in consultants who prepare a require- ments analysis. For some of the processes being integrated, a pre-existing requirements analysis might be available. In this case, review the business rules pertaining to the integration effort for completeness and accuracy because information processes can change over time. Also, the infor- mation process being integrated might have conflicting business rules, which requires that the appropriate data owners meet to resolve the conflicts. When a requirements analysis is not available for data or a process, it might be necessary to create a new one. This analysis usually takes the form of a document that lists in plain English each of the rules pertaining to a process or piece of data. This document answers the following questions: What are the inputs to the process? What are the preconditions necessary for the process to begin? What are the outputs from the process? What is necessary for the process to be completed?