National Academies Press: OpenBook

Integrating Airport Information Systems (2009)

Chapter: Chapter 3 - Best Practices for Integration

« Previous: Chapter 2 - Current State of the Industry
Page 16
Suggested Citation:"Chapter 3 - Best Practices for Integration." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 16
Page 17
Suggested Citation:"Chapter 3 - Best Practices for Integration." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 17
Page 18
Suggested Citation:"Chapter 3 - Best Practices for Integration." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 18
Page 19
Suggested Citation:"Chapter 3 - Best Practices for Integration." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 19
Page 20
Suggested Citation:"Chapter 3 - Best Practices for Integration." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 20
Page 21
Suggested Citation:"Chapter 3 - Best Practices for Integration." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 21
Page 22
Suggested Citation:"Chapter 3 - Best Practices for Integration." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 22
Page 23
Suggested Citation:"Chapter 3 - Best Practices for Integration." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 23
Page 24
Suggested Citation:"Chapter 3 - Best Practices for Integration." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 24
Page 25
Suggested Citation:"Chapter 3 - Best Practices for Integration." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 25
Page 26
Suggested Citation:"Chapter 3 - Best Practices for Integration." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 26
Page 27
Suggested Citation:"Chapter 3 - Best Practices for Integration." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 27
Page 28
Suggested Citation:"Chapter 3 - Best Practices for Integration." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 28
Page 29
Suggested Citation:"Chapter 3 - Best Practices for Integration." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 29
Page 30
Suggested Citation:"Chapter 3 - Best Practices for Integration." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 30
Page 31
Suggested Citation:"Chapter 3 - Best Practices for Integration." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 31
Page 32
Suggested Citation:"Chapter 3 - Best Practices for Integration." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 32
Page 33
Suggested Citation:"Chapter 3 - Best Practices for Integration." National Academies of Sciences, Engineering, and Medicine. 2009. Integrating Airport Information Systems. Washington, DC: The National Academies Press. doi: 10.17226/14234.
×
Page 33

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

16 A successful integration project reflects the time and effort taken beforehand to prepare for the integration properly. Unless care is taken to set the goals and objectives, identify the existing processes and systems, clarify the vision of a successful outcome, and evaluate all of the benefits and costs of integration, the resulting project will not meet the desired outcome. Instead of set- ting up a plan to succeed, an airport might inadvertently set up a plan to fail. Airports that have integrated several systems and achieved results that met the expectations of managers, users, and customers have developed a series of best-practice integration steps that led to their success. This chapter describes the steps those airports have taken. Whether the airport is a small, medium, or large airport, the thousands of complex informa- tion processes and millions of pieces of data are similar. Adding to the equation are sophisticated technical systems, some old and some new, which can make the integration process overwhelm- ing. Therefore, using a phased approach by department or by functional area helps airports realize success. Integrating airport systems using this phased approach has proven more palat- able than the integration of the entire airport. Another way to look at it is: If your desk is full of paperwork, how will all the work be completed in a timely manner? A best practice is to review all the documents, prioritize the workload, and start with a small part of the paperwork before moving on to the next. Part of using a phased approach is performing a financial cost-benefit analysis of the proposed integration effort before beginning integration and updating that analysis along the way. The financial cost-benefit analysis can help an airport determine which functional area to include in the first phase and how much integration makes sense. Throughout the steps, the analysis is updated to reflect new information and the financial feasibility of the project is continually revisited. For example, it might become apparent that, although it originally seemed sensible to integrate the existing financial and maintenance systems, it turns out that it would be more cost- effective to get a new maintenance system that already has a built-in integration with the current finance system. By creating a long-range plan and using a phased approach that adequately reflects the prior- ities of the airport’s business needs and objectives, airports have achieved positive results. After the objectives and information needs are identified, the data are scrubbed clean and data rules are then applied. Identifying specific business-critical information that is important to senior management can help define into what phase and priority the particular integration process falls. Within the stakeholder group described below, airport middle managers can help identify and deliver what senior management needs. If the integration effort is embraced throughout the air- port and is based on basic problem-solving approaches, integration is more likely to occur. The integration process involves many people working together for a common goal and exchanging information between systems accurately, in context, and on time. C H A P T E R 3 Best Practices for Integration

Best Practices for Integration 17 Stakeholders Although the following stakeholder descriptions may not reflect all airports, these descriptions define the categories used in the steps detailed in this chapter. • Airport Senior Managers. For this Handbook, an airport senior manager is a high-level execu- tive responsible for the airport, functional area, or division/department, such as a Chief Execu- tive Officer (CEO), Chief Operations Officer (COO), Chief Information Officer (CIO), or Chief Financial Officer (CFO). These senior-level managers provide the vision for integration projects. • Airport Middle Managers. Department and division heads who run daily operations ensure that information flows are smooth and accurate, and they maintain the IT network infrastruc- ture. These managers need detailed information about their divisions or areas of responsibil- ity. They manage the intermediate steps needed for the integration process. • Data Owners. The staff who input data and calculate information are the data owners. They need to understand the context of their data and how the information is used. These staff need the inputs and outputs to calculate their information. They work with middle managers to identify processes and make the changes needed for integration. The involvement of the stake- holders is often the key for success through the integration phases. Integration Steps The rest of this chapter describes each step in detail, including the stakeholders involved in each step and the relative intensity of their involvement. Figure 3-1 shows the sequence of steps toward integration. In Figure 3-2, senior management is heavily involved, as indicated by the four-person graphic in the first column, first row. Throughout the steps, a graphic of four people in a column represents the greatest involve- ment, while three people represent slightly less involvement, and so on. Stakeholder groups not directly involved in a particular step (as indicated by blank space) should be kept informed of Figure 3-1. Best practices for integration: sequence of steps.

Figure 3-3. Step 1. 18 Integrating Airport Information Systems Step 1: Define Business Objectives and Identify Information Needs Figure 3-3 indicates the level of effort of the stakeholders for this step. Define Objectives The first step in any integration process, and the most important, is for senior management to define clearly what airport goals will be furthered by this integration and what objectives manage- Figure 3-2. Sample of the steps. Case Study Introduction Angelo International Airport (AIA) is a medium-size hub airport enplaning 4.7 million passengers, with 213,000 operations annually. It is served by twelve domestic and two international carriers. AIA’s use and lease agreement has an airfield residual cost center structure, while the terminal complex generally is classified as commercial compensatory in its rate-making methodology. the progress and results, as appropriate. From these charts, readers can quickly find their roles and concentrate on the tasks needed to help make the airport integration a success. Case Study Examples In the following sections, the steps to prepare for integration are further illustrated using a hypothetical case study to track the activities that might accompany an integration effort. Each step of the case study illustrates how a mid-sized airport might undertake to improve airline rates and charges calculations. To do this, the airport chose to integrate information that previously had been handled manually. For the sake of brevity, the case study tracks the general direction of an integration effort and only summarizes the many actions that would be needed.

ment wants to achieve. If the airport has already developed a vision and created a long-range inte- gration plan, then based on those priorities, the project can be scaled using a phased approach that reflects the priorities and objectives defined in the airport’s business needs and objectives plan. To help define the business objectives for an integration project, management needs to iden- tify priorities in the following areas: • Business. For example, is the priority to generate higher levels of revenue, provide better ser- vice to the public, or reduce duplicative staff effort? If all three are priorities for the project, identify which has the highest priority. • Sensitive Areas. Review the potential for sensitive issues that require the involvement of sen- ior management. Such issues can include control of media information and the timing of such data releases, or how the integration may affect staff. • Political. Determine if the political climate may affect achieving the goals of the integration and what information is required to meet political objectives. An airport authority may have different political issues than a government-owned and -operated airport. For example, a municipality may want financial information from all city departments, including the airport, to be integrated and consolidated for auditing and reporting purposes. • Planning. Determine the area with the largest projection of growth and prioritize the integra- tion efforts to mirror the Master Plan. For example, an airport might be planning to gear its facilities to a more common-use environment. Identify the Need for Integration and Why For each individual integration project, it is important to start with a clear understanding of the reasons behind the integration effort. These objectives can be broad, such as “Understand the components of and reduce the cost per enplanement.” However, they should be part of the airport’s overall objectives. Answering the following questions can aid in reaching these objectives: • What problems are we trying to solve with this integration effort? Example: the manual calculation of rates and charges. • Who are going to be the primary users of the integration effort? Example: all of senior management. • What tasks are the users going to perform with this system, and how often? Example: senior managers will access the data from their dashboard. Every other step of the integration process should relate directly to these business objectives. Reviewing the overall objectives periodically throughout the process will help keep the integra- tion process on track to achieve these objectives. If the objectives change, the steps may have to be repeated to achieve the new objectives. As with other initiatives, it is easy to be too ambitious with the objectives for an integration project. It can help to prioritize the objectives and recognize that it may be necessary to defer some objectives in order to accomplish the main goal in a reasonable period and at an acceptable cost. Identify Business-Critical Information After senior management has established the metrics associated with the business objectives, identify the business-critical information and key data elements necessary to calculate the met- rics. For a guide to the business-critical information and key data elements common to most air- ports, see Chapter 4, Airport Information. However, an airport’s particular operations and procedures may require additional information not addressed in that chapter. To complete an airport’s data needs, answer the following questions: • What successes has the airport had? What data and information led to these successes? • In the past, what problems have arisen because of the lack of proper data and information? What data and information are needed to prevent problems in the future? Best Practices for Integration 19

20 Integrating Airport Information Systems • What data do particular reporting circumstances require? For example, an airport can be part of a municipality that requires certain fiscal data reporting. Step 2: Identify, Define, and Evaluate Information Processes Figure 3-4 indicates the level of effort of the stakeholders for this step. Identifying, thoroughly understanding, and evaluating the information processes are key for any successful integration—after all, this information is the core of the integration effort. First, trace each piece of information identified in Step 1 by answering the following questions: • What is the source of the information? • How is that information calculated? • How accurate is that information? • What is the context of that information? • Where is that information stored? • How is that information tracked? • What systems use that information? • What people use that information? • Why and how do people use that information? Information processes that are sound and provide accurate data before integration will be sound and provide accurate data after integration. Likewise, any information or process that is inaccurate or out of context before integration can provide inaccurate and possibly misleading data after integration. Identify any problems in information processes before taking any other steps Figure 3-4. Step 2. Case Study Step 1 AIA’s CFO approached the CEO with a concern that the airport’s current method of calculating rates and charges was cumbersome, prone to errors, and time con- suming. As a result, the CFO felt it would be appropriate to explore the possibility of integrating one or more of the systems that feed data into the rates and charges calculations. The CFO’s objective was to improve the process of calculating some or all of the rates and charges by making the process faster, more accurate, and less expensive than the current process. She mentioned several systems and manual procedures that contribute to the calculations. The CEO Agreed and told the CFO to proceed with the initial steps. He noted that major airport goals would be supported by increasing efficiency and reducing costs to the airlines. The CFO identified the intermediate objectives as reducing both staff cost and lost revenue.

to integrate. Work with data owners to ensure that the processes for collecting, calculating, stor- ing, and using data provide accurate, effective data. Flag data with the following characteristics: • Redundant Entries. Often the same data comes from multiple sources and is used in differ- ent contexts and circumstances. Identify what information is being input more than once. Who enters this? Where do they get the information? How do they enter it? • Manual Entries. Identify what information is entered manually, such as shift logs or informa- tion someone types from one software system to another. Identify which manual entries might be automated to discuss later with an IT vendor. For now, just get information. Who enters this? How? What does it do for us? • Incorrect Data. Data derived from calculations that depend on the incorrect information will also be incorrect. Incorrect data used in calculations will result in incorrect information in the various systems that use the data. Finding these errors can save millions of dollars a year. Identifying the correct data needed is not enough. Evaluate how well the existing processes are working. If a particular process works fine the way it is, the process need not be changed. If, after the analysis, the consensus is that the process should change, it may be beneficial to bring in a specialist accustomed to facilitating process changes. The inertia of having “always done it that way” is a tremendous force, and it needs to be worked with—not against. Changing processes is extremely difficult and might be one of the most challenging aspects of the integration process. Ask the people involved with the entire information process to help fix the problems. If the people who use the process help change the process, they will be much more likely to accept the new process. Step 3: Determine Who “Owns” the Data and Identify the Systems Figure 3-5 indicates the level of effort of the stakeholders for this step. Understanding the data’s context and where it resides is also essential to understanding infor- mation processes. This means identifying which system or systems contain each piece of data that the effort identifies as being necessary to meet the business objectives. Some pieces of data might actually be tracked in multiple systems. There might be pieces of information currently not tracked at all, tracked informally on paper, or in some isolated electronic file (such as a spreadsheet). This Step requires delineating the systems and how data are used in the system. This information and the way it is obtained varies from airport to airport. Best Practices for Integration 21 Case Study Step 2 The CFO asked the staff in Finance and Administration, Maintenance, IT, and Operations to document the source, location, accessibility, purpose, and calculation method of each key piece of data. The CFO noted the person who was responsible for collecting, calculating, and transmitting the data. The CFO discovered that there was often more than one source for key data elements and the data from different sources conflicted at times. The CFO also found that several sources of data needed further investigation. For example, the airport relied on the airlines to report their number of operations and passengers carried, and this data then was used to bill the airlines for their landing and passenger fees. This reliance represented a possible weakness in the process that needed attention. The CFO made a request to the airlines that they provide the source and systems used to provide their reported data. The CEO agreed that the project should proceed and the CFO identified the next steps as appointing a Project Manager and building an airport-wide cross-functional team that would collaborate on the project.

22 Integrating Airport Information Systems In this context, ownership of the data and the systems means the person in the organization who is primarily responsible for the correctness of the data and the corresponding system. The data owners are the people who are directly responsible for maintaining, calculating, and under- standing the context of the data reported to middle and senior management. Although IT divi- sions will always be involved in ensuring correct data and system operation, IT divisions rarely own the data. Also, when referring to a system, the definition is more than the computer systems; the entire data information process can include a software solution, a manual paper-based process, and a workflow that includes verbal communication and notification. Functional area managers can play a large role in tracing data. When there are multiple sources, such managers need to identify the data that should take precedence, and what data will be used from what system, under what conditions, and in what contexts. Each system identified and tracked should be accompanied by a list of how the data are stored, the architecture of the system that stores that data, and whether there is an area to store that data in the new system. In many cases, ownership for most data and systems is not clear cut. Systems might be shared or duplicated across departments. Similarly, many pieces of data might be viewed as critical by different departments. Identifying owners of the systems and pieces of data is important to the integration process, because the owner is the final arbiter for any questions or discrepancies that arise. Without these clear lines of ownership, the integration process can stall in endless meet- ings, with multiple stakeholders arguing about each individual decision instead of advocating the success of the overall project. Figure 3-5. Step 3. Case Study Step 3 The CEO and CFO selected a Project Manager who was knowledgeable in the busi- ness practices of the airport and well respected throughout the organization. The CFO and the Project Manager formed a project team that worked with the key data every day, including employees from each of the functional areas of the air- port. The Project Manager assigned employees as “owners,” which meant they were responsible for inputting, updating, understanding, and ensuring the accu- racy of the data. Discussions with the team identified alternate sources for the data that could be more accurate and timely, as well as the use of the data in each functional area. The team identified over a dozen different systems throughout the airport that needed to integrate to produce the rates and charges. The team decided to recommend integrating these systems in phases.

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. Best Practices for Integration 23 Figure 3-6. Step 4. 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 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.

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? 24 Integrating Airport Information Systems Figure 3-7. Step 5.

• What are the standard workflows through the process? • What are the alternate workflows through the process? When do the alternates occur? Only the business rules that pertain to the pieces involved in the integration effort need to be collected. Also, some of the business rules that need to be collected might pertain to data not cur- rently collected or systems not yet in existence. After the business rules have been collected, review them to ensure they are • Consistent with each other; • In line with the priorities defined in Step 1, Define Business Objectives and Identify Informa- tion Needs; and • Complete. Best Practices for Integration 25 Figure 3-8. Step 6. Step 6: Perform a Gap Analysis Figure 3-8 indicates the level of effort of the stakeholders for this step. A gap analysis defines the gap between where the systems are today and where the integrated system should be. The gap analysis defines missing systems, processes, and data needed to achieve project success as previously defined. The gap analysis starts with the rules and requirements col- lected in Step 5. Determine for each requirement whether there is a gap between what is avail- able and what is required for success. Gaps can take the following forms: • Missing data or business rules, • Inaccurate data or business rules, • Incomplete data or business rules, and • Systems with conflicting business rules. Case Study Step 5 The Project Manager added a member of the airport’s legal staff to the team to ensure that the requirements of the airlines’ use and lease agreements were understood and incorporated into the business rules for the data. The CFO reviewed the draft business rules and found that the contractual rate-making methodology required that the landing fee be calculated using airline self- reported landing counts. Because this business rule would preclude using airport- generated flight data, and thus reduce the potential benefits of the integration project, the CFO flagged this problem for resolution by the CEO. The CEO agreed to try to negotiate a change in the rate-making methodology in the upcoming re-negotiation of the airlines’ use and lease agreements.

After these gaps have been identified, create a plan for addressing them. Some gaps can be addressed simply, by process changes. For example, a missing piece of data can be collected and entered into an existing system. Other gaps can require some attention during the integration process, such as resolving conflicting business rules when two systems are integrated. Larger gaps can require additional systems to be built or acquired. Next, estimate the costs of each of the steps necessary to address the gaps. Some of these cost estimates might be straightforward or negligible because they are a natural outcome of the inte- gration process. Others might not be so straightforward, such as developing custom systems or acquiring commercial off-the-shelf (COTS) software. In these cases, a detailed build-versus-buy analysis must be performed to determine whether a custom system should be built or a COTS system is more appropriate. For more information on build-versus-buy analysis, see Chapter 6, Architecture, Strategies, Technologies, and Contracts. 26 Integrating Airport Information Systems Step 7: Evaluate the Non-Financial Costs and Benefits of Integration Figure 3-9 indicates the level of effort of the stakeholders for this step. Understanding the non-financial benefits of integrating can enhance decision-making and help an airport justify an integration effort. Examples of such benefits include improvement in the customer service complaint areas or the ability to become more proactive in an industry accustomed to rapid changes. Ask the data owners how integration will make them more effi- cient. For example, will it reduce the amount of time spent correcting or re-entering data from one system to another and free them for more complex work? If the data owner is a part of the process, it might be easier for him or her to champion the integration efforts. As noted in Step 2, Identify, Define, and Evaluate Information Processes, when a process is going to change, it will be more positively received if the change benefits the stakeholder. Figure 3-9. Step 7. Case Study Step 6 In Step 5, the AIA integration team identified dozens of business rules that applied to the calculation of the rates and charges and defined the data required to comply with the rules, as well as the sources of the data. Their gap analysis showed that the data from the maintenance work order system was frequently in conflict with the labor rates data in the HR payroll system. The team members from each division met to find a way to resolve the conflict. The resolution called for integration of the payroll system with the work order system and re-defining the business and data rules. After the gap analysis was complete, the Project Manager created an updated project plan and cost estimate for the project. After reviewing the project plan and cost estimate, the CFO agreed that the project should proceed.

Step 8: Evaluate the Financial Costs and Benefits of Integration Figure 3-10 indicates the level of effort of the stakeholders for this step. Most of the information needed to calculate the direct financial costs of the integration proj- ect has been produced in previous steps. In this step, along with compiling those costs, the indi- rect costs of integration need to be reviewed and tallied. Direct financial costs can include hardware, software licensing, consulting, staff allocation during integration, and additional staffing after integration. Indirect costs include the following: • Inefficiencies During Transition. When a new system is brought on line, there may be a period when two systems are run in parallel with one another, or when the transitioning items need to be checked manually. This can result in overtime or increased staffing levels. • Training. When an airport implements a new system that is replacing a manual process or a legacy system, the airport can experience increased training time and lower productivity that results in overtime. As the stakeholders become more familiar with the newer systems and are properly trained, productivity will increase. • Computer Upgrades. A contributing factor to evaluating the financial costs is to ensure that the hardware specifications for the software are adequate and planned for. The types of issues that arise range from simple to complex, such as the need for dual monitors to view the man- ager’s dashboard or for updates to the network bandwidth. • Maintenance. With the purchase of software, continuing maintenance costs may have been over- looked in the cost analysis. Capturing and understanding these charges before implementation Best Practices for Integration 27 The integration phase should benefit the entire airport, including an increase in the non-cost benefits. As part of any airport evaluation, every process that will change should be identified and listed. The benefits of integration will generally fall into three categories: increased accuracy of information, improved timeliness of information, and increased efficiency. Figure 3-10. Step 8. Case Study Step 7 The CEO, CFO, and Project Manager jointly identified the non-financial benefits of the project. To make this assessment, the combined experience of these leaders and their knowledge of all facets of the organization were leveraged. The non-financial benefits included the prospect for improved relationships with the airlines. The airlines’ property officers had often complained that errors in, and re-calculation of, the rates and charges created significant budgeting impacts on the airlines, as well as a fair amount of concern by the airlines’ senior officers. The project would directly address the cause of these complaints. It would also simplify the staff’s related tasks and reduce the time required.

is important to proper budgeting. (For further detail of these types of charges, see Step 12, Main- tain the Systems.) • General Infrastructure. Several elements of the general infrastructure need to be evaluated before integration begins. Will the current network infrastructure support the integrated sys- tem being proposed? Is there enough power and backup power for the solution? With answers to these questions, decisionmakers can modify the approach to integration, and additional network infrastructure can be factored in as a cost of the project. • Backups and Disaster Recovery. Is there an existing backup and disaster recovery plan? Does that plan need to be modified to accommodate the integrated system being proposed? If the new system will be relied on for daily operations, this reliance may introduce significant backup and disaster recovery needs that did not previously exist. At this point, most costs are known and the benefits should be well defined. The evaluation of the costs and benefits should be rigorous and thorough. The following steps in integration will require major financial commitments for hardware, software, and outside services. It is imper- ative that this rigorous evaluation result in a go-no-go decision. The costs and benefits to the air- port as a whole should be analyzed because costs and benefits probably will not be equal for each of the individual divisions. Often, one division will gain more of the benefits while other divi- sions will bear a larger share of the cost. However, if all the airport-wide benefits outweigh the costs, the project is justified and reasonable. 28 Integrating Airport Information Systems Step 9: Determine an Effective Integration Strategy and Technologies Figure 3-11 indicates the level of effort of the stakeholders for this step. As the actual system integration effort begins, the tasks become more technical in nature and will probably require professional consulting and IT resources. During Step 3, Determine Who “Owns” the Data and Identify the Systems, each system was identified and the system architec- ture delineated for each process and data requirement. In Step 9, the stakeholders evaluate the integrated system architecture. Case Study Step 8 The CFO and Project Manager prepared an assessment of the estimated financial costs and benefits of the projects. Their assessment answered the following questions which they knew would be posed by the CEO: • Will we reduce spending in personnel and equipment costs when the integration process is completed, and if so, by how much? • Are you able to quantify the cost associated with errors and untimely completion of the landing fee calculation? • Do we have the staff to implement the system or will consultants be required, and if so, what will they cost? • What will be the cost of the new hardware and software, and what are the 5-year estimates of the maintenance and operations costs? • Will the airlines support paying for this investment, and if not, how do you propose to finance this effort? After a detailed cost-benefit review was complete to the satisfaction of all parties, the CEO agreed to move forward with the project.

To evaluate the system architecture, the IT resources look at each system and identify the tech- nologies available to use in the integration process. (For more information on integration tech- nologies, see Chapter 6, Architecture, Strategies, Technologies and Contracts.) This can include evaluating system architecture for any COTS that will be purchased, as well as any COTS or custom software already in place. The result will be that, for each system identified, the IT professionals have evaluated what different technologies are available to use to integrate this particular system. This is also an appropriate time to determine any costs associated with the integration technologies. Now all the information necessary to choose an integration strategy has been collected. There are many different strategies for integration (some of the most frequently used are listed in Chapter 6). Before stakeholders evaluate an integration strategy, determine the following aspects of the strategy: • How is this strategy commonly used? • What are the strengths and weaknesses of this strategy? • What technologies are usually used to support this strategy? Then answer the following questions: • Do the strengths and weaknesses of the integration strategy match the business objectives? • Does each of the systems identified have available technologies that support the integration strategy? During this evaluation process, many tradeoffs probably will need to be made. For example, a specific business objective might have to be sacrificed in choosing an integration strategy that, while it meets many of the other objectives well, does not allow for integration of important data to meet that specific objective. Another example is that, while the integration of a particular sys- tem is possible, the licensing costs are out of line with the benefits. Best Practices for Integration 29 Figure 3-11. Step 9. Case Study Step 9 Having analyzed the complexities and architecture of each of the systems, the Proj- ect Manager next reviewed the technologies available and discussed with the team and the IT professionals which strategy would be the most appropriate to use. After examining the advantages and disadvantages of Data Warehousing, Enterprise Information Integration (EII), and Enterprise Application Integration (EAI), the team elected to acquire EII software, to enable the airport to access multiple systems in an integrated manner, while not disturbing data stored in each of the systems. This distributed data approach permits the divisions to operate their systems on their equipment with only that data necessary for integration leaving and entering their local environment.

Step 10: Implement the Strategy and Technologies Figure 3-12 indicates the level of effort of the stakeholders for this step. Now the actual system integration can take place. During this step, software is constructed and configured using the strategy and technologies identified in the previous step to create an integrated system. Depending on the software management approach used by the team, opportunities may arise during the construction to test various pieces of the integrated system and verify that things are moving in the right direction. It is important to monitor the integration and evaluate its progress. This information will help show the return on investment for the integration effort and pinpoint areas to improve during future integration projects. During the implementation process, training on all new equipment, systems, and procedures is critical to the success of the project. 30 Integrating Airport Information Systems Figure 3-12. Step 10. Step 11: Test, Evaluate, and Follow Up Figure 3-13 indicates the level of effort of the stakeholders for this step. After the integration is complete, a final start-to-finish test of the integrated system should be per- formed so that all stakeholders have a chance to validate that the integrated system is working prop- erly before the system is put into production. After testing is complete, including any necessary fixes or modifications, the system goes into production. Testing should continue for a short period after the system is in production to ensure that no unexpected issues will arise in production. When the integration is complete, a project debriefing review should be conducted to under- stand what went well, what went wrong, and what could be done to improve the integration process in the future. This should be done at every level in the organization and summarized for senior management. To monitor the success of the integration, a return-on-investment analysis at the end of the project is important. Table 3-1 provides some criteria for the evaluation. This information will help show the actual return on investment of the integration plan and pinpoint areas to work on for future integration. Case Study Step 10 The project team acquired the EII software along with the necessary hardware and performed the initial installation and configuration of the software. The proj- ect team then began using the EII software to integrate the data from the various airport systems previously defined. During one of the bi-weekly status meetings with the Project Manager and CEO, it was decided to bring in outside expertise in the EII software package selected due to specific problems the project team was having with the project. This contingency was previously identified as a possibility and was included in the overall project budget. Bringing in this expert allowed the project to proceed according to schedule.

Table 3-1. Return-on-investment evaluation. Best Practices for Integration 31 Figure 3-13. Step 11. Case Study Step 11 After the project team finished their testing, the data owners were brought in to perform acceptance tests to make sure the system performed as planned. The data owners had previously been trained on the system and were anxious to see how the system worked with real-world data. Any problems identified were researched and solved by the project team, and the system was moved into production. The project team and the data owners continued to test and monitor the system after it was put into production to make sure nothing unexpected occurred. The project team met first internally then with the data owners to discuss the project and how things could be done better next time. It was decided that over- all, the project was pretty smooth, but that the data owners could have used more training leading up to the testing period. The Project Manager and the CFO worked to create a return-on-investment analy- sis a couple of months after the project was completed. They determined that the reduction in cost per enplanement was slightly under what they had projected at the beginning of the project, but still well within the range necessary to make the project provide a benefit above and beyond the project cost.

Setting Milestones Milestones for the long-range integration plan will be specific to a particular airport and proj- ect. Completing the preceding steps in this chapter can be considered a milestone, or even one of the steps alone can be a milestone. Some organizations set milestones specific to the project, such as finance or resource allocation milestones. An airport should begin to develop these mile- stones as early as possible. First, define the vision for the airport, and set realistic goals to achieve the long-range vision and the short-range vision. This might mean prioritizing the goals after an airport has reviewed the stakeholder availability. Consider the availability and schedules of managers and personnel chosen to support man- agement through the integration plan. The scheduling and timing of resources should reflect the airport’s overall objectives and the airport’s schedule for other projects. Airport personnel need to understand from the beginning how the integration will affect daily operations. Set critical training deadlines and incorporate these dates in the overall resource planning schedule. Defin- ing the stakeholder involvement early can assist in refining and prioritizing the short- and long- range vision and its success. After the resource allocation plan has been delineated, it is a good time to review the system integration challenges and plan appropriately to meet those challenges. Closed-architected sys- 32 Integrating Airport Information Systems Figure 3-14. Step 12. Step 12: Maintain the Systems Figure 3-14 indicates the level of effort of the stakeholders for this step. After the system is in production, there will be issues that should be addressed regularly, as well as periodic changes that are desired. A plan should be instituted to address the maintenance and to ensure that any changes to the system are correct and appropriate. Although small changes probably can be made with a minor review process, big changes to the system probably will require their own integration projects to follow each of the steps identified in this chapter. Case Study Step 12 After the system was firmly in place, the data owners met monthly with the IT team member in charge of maintaining the system. Throughout the first year the system was in use, they made minor changes to some of the business rules based on feedback from various departments. At the end of the first year, they recom- mended to the CFO and CEO that the second phase of the integration project be funded based on the success of the first phase.

tems may not allow for the business-critical data to be retrieved from one system to another, or such systems can require third-party vendors to assist in extracting data in a usable format. Part of resolving such challenges can involve updating a system or maybe even replacing a system, depending on the importance of the business-critical data and key metrics that the system pro- duces. It is at this point that airport personnel may need to regroup and refine the business- critical data and key metrics. Reviewing who, what, and why specific business-critical information is important and how such information shapes the overarching goals for integration and prioritizing the key metrics can facilitate such decisions. Identify the benefits and key outcomes of the integration project. When setting milestones, review the current infrastructure of the airport. Consider a timeline of acquisition requirements that includes systems, network infrastructure, IT outsourcing for complex integration projects, construction such as facility changes, external consultants, and timing of such for this integration project. If other integration projects are in progress at the airport, especially if simultaneously, under- stand the effects and how to resolve them early. Understanding the requirements specifications and setting realistic goals for accomplishing those requirements can set a clear path to a success- ful integration project. Best Practices for Integration 33

Next: Chapter 4 - Airport Information »
Integrating Airport Information Systems Get This Book
×
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

TRB’s Airport Cooperative Research Program (ACRP) Report 13: Integrating Airport Information Systems is designed to help airport managers and information technology professionals address issues associated with integrating airport information systems. A summary of the efforts associated with the development of ACRP Report 13 was published online as ACRP Web-Only Document 1: Analysis and Recommendations for Developing Integrated Airport Information Systems.

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!