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.
Chapter 5: Selection and Implementation of an Airport CMMS This chapter describes a process for selecting and implementing a CMMS at an airport. Since the CMMS impacts multiple departments or business units of the airport, this process should involve stakeholders across the entire airport and the CMMS should provide support for functions across all business units. Success should be measured by the degree to which the CMMS meets all business needs. The Selection Process The selection process uses the requirements gathered during the evaluation process. Ideally, the process of gathering asset data and understanding workflows should already be underway. The selection process should now formalize the procedures for matching the gathered airport requirements to capabilities of available software. The stakeholders involved in the selection process were defined in Chapter 3. Many of the stakeholders who are now focusing their efforts on the selection process were previously involved in the requirements-gathering process. There are many full-featured CMMS software solutions, incorporating many features and capabilities. Selection of a full-featured CMMS will ensure that an airport will be able to add options that are not implemented initially. But an optimal selection of a CMMS is specific to the requirements of the airport and the environment in which the CMMS will be deployed. Selection of a CMMS involves more than merely evaluating the capabilities of the software. It also requires determining whether the software is within the airportâs budget and then analyzing the requirements of the airport against the features and capabilities of the software. In addition, it requires vetting the software vendor and the performance of the contractor providing installation services. Researching (other airports, vendors, consultants) CMMS costs is important. If the CMMS budget is small, the airport should consider a hosted solution or starting small, with the most critical department or area where the greatest cost savings can be achieved in the shortest time. 38
The first step in the selection process is to research available software in the market. CMMS software is widely available, so the larger issue will not be to find a software, but to narrow down candidate CMMS software based on the prioritized list of airport requirements. Research can be done in-house through the Internet or with the assistance of an industry expert knowledgeable in the maintenance/asset management field. It is sometimes difficult to compare software from demonstrations by vendors. A script can make that comparison easier. It should focus on some of the particular business processes at the airport. Then, after the mandatory elements have been covered in the script, a vendor can demonstrate additional features of the software. If procurement rules allow it, the airport might request a demonstration of the software from vendors. In addition to demonstrations, airport staff might also visit vendor labs for hands-on experiences with live CMMS systems. Selected airport staff might attend training sessions or review course materials to determine the suitability of specific CMMS training for their airport. A tour of other airport CMMS implementations can offer very good information about its functionalities when deployed in an airport setting.. The organizations and associations mentioned in Chapter 1 can provide contacts and relevant information.. Other software/vendor information is available through publically accessible user groups. For example, SAP has an annual SAPHIRE event, where SAP Plant Maintenance and Material Management users can request new features, get information about best practices, and exchange ideas with peers. Other large vendors conduct similar events. Depending on the rules of the procurement process, the airport might then choose one of several procurement options. In some cases, based on the research, a short list of candidate solutions might be created and assessed for suitability. In others, the procurement process will be publicly bid. But the assessment process is essentially the same, focused on the softwareâs suitability of meeting the requirements gathered during the evaluation phase. Additional requirements stemming from the research during the procurement phase should be expected to be added to the requirements list. Regardless of the procurement mechanism, a software solution should be chosen that best meets the business needs of the airport. Additional considerations might need to be made in the following areas: ⢠Ease of integrating existing system data during the conversion period (initial implementation) or on an ongoing basis if the existing system will remain. ⢠Capabilities of the airport to manage the CMMS, including but not limited to server maintenance, networks, backend software such as databases and their administration, workstation deployments, and client software. ⢠The extent of configuration required versus customizations (which are much more difficult to implement and maintain) and the work required either by in-house or outsourced staff. Sample CMMS Software Assessment Matrix A suggested method for assessing the requirements gathered by the airport is to provide each vendor with a list of the requirement so that the vendor can illustrate the capabilities of the software to provide 39
the required functions. The airport can rate each software option based on how well it meets the functional requirements, and tally the results for a comparative score. An extract from a sample of the Vendor Assessment Matrix is shown in Table 5-1. The full sample is included in Appendix F. This matrix is a ranking scorecard with sample requirements used to rank software from multiple vendors in a software selection process. It uses a rank scale of 1-10 and tallies scores for a total comparative ranking at the end. Requirement 1 2 3 4 Work Request & Work Order Tracking. The CMMS shall provide the capability to track requests for facilities maintenance work or other work requirements received from any source from receipt through final work completion. This includes tracking its progress through planning and estimating, scheduling, execution by in-house shops or contractor forces, and while any administrative or planning actions are undertaken such as waiting for funding or incorporating the work into a capital project. Trouble Calls. The CMMS shall permit receipt and issue of Trouble Calls (TC). It also shall provide the status of TC tickets pending action, underway, and completed. Work Orders for PM, Repair, ROI, etc. The CMMS shall provide for the preparation of specific or one-time work orders for Repair, PGM, ROI and other work that is of fixed duration and scope. This shall be integrated with work order estimating and scheduling. The CMMS shall be able to identify the work order by customer, funding source, and work breakdown structure. Work Order Estimating. The CMMS shall provide for an integrated work order estimating system. The system shall provide planners and estimators with assistance in preparing work order craft, time, and material estimates. It shall permit including local labor and material rates, local unique cost factors, or standard work tasks. Preventive Maintenance (PM). A CMMS shall provide complete PM scheduling and PM order preparation based on inventory and facilities maintenance requirements including multiple levels of scheduling based on criticality, use, condition, or calendar time. The system shall track inventory data, facilities maintenance checklist, parts required, safety requirements and special environmental concerns, coordination/outage requirements, results of the last PM, diagnostic and maintenance references, drawings, special tool or equipment requirements, and special skill or trade requirements. It shall permit scheduling to the week, be able to give resource requirement reports and summary schedules. It shall include the capability to adjust future PM dates based on the actual completion date of the latest PM is a valuable feature. â¦â¦â¦â¦â¦â¦â¦â¦â¦ TOTAL Table 5-1 Vendor Assessment Matrix Based on the airportâs procurement rules, the outcome of the comparison of software to the airportâs requirements, any other criteria adopted by the airport during the procurement process, and the cost of the CMMS, the airport will decide the best fit CMMS for its requirements. Whether the selected CMMS is in-house, hosted, large or small, the next step is critical to making certain that the benefits of the CMMS are realized. 40
The Implementation Process At this stage, the airport will need a plan for a implementing the selected CMMS software. This section discusses how to plan that implementation process. Implementation planning should include stakeholders previously identified in Chapter 3. These stakeholders are even more critical to the success of the project at this stage, as they will provide an interface between the project and the other staff at the airport. And as the implementation progresses, they will provide valuable feedback to the project so that the process can be adjusted if the plan does not achieve the desired results. At a minimum, that plan will advise all of stakeholders of how the project will proceed, what the tasks are in the project, who is responsible, what things outside the project that success is dependent on, when tasks will complete, and how the project will be judged successful. During the selection process, it was decided whether the implementation is to be done by the airport staff in-house, or by a team including the software vendor or consultants (or both). Whether the implementation is done entirely in-house or not, should be determined in the project plan. This, and other elements of the plan, including specific tasks that are unique to CMMS, are discussed in the following sections, The Project Plan Using the general project management best practices, a project manager should draft a project plan for approval that would include: ⢠A communications plan, to discuss meeting, expectations for reporting, time allotted for review of documents and other communications protocols for the project ⢠A quality plan, to set the standards for quality assurance and control throughout the project to ensure that the submitted work is of the highest caliber ⢠A project schedule, to establish the time frame for the project tasks and a completion date for the project, including tasks, work breakdown schedule, milestones, resources, dependencies, costs loading, testing, transition to operations, and closeout ⢠A testing plan, which should be started early in the project ⢠A training plan, to ensure that training is executed just before transition to operations so that the training is fresh for staff when they are expected to use the new system and procedures. Identify Asset Data At some point, the airport may want to develop an Asset Management Plan to provide full life-cycle management of their assets. The ACRP Report 69 Asset and Infrastructure Management for Airports â Primer and Guidebook (published in March 2012) is a valuable tool to use in devising such a plan. For the purposes of evaluating a CMMS, the airport will need some elements of asset management in place. At a minimum, the airport will need to assemble its assets into a central data warehouse, commonly called a data dictionary or catalog. To facilitate the capture of the data, some consideration should be given to the following questions: ⢠What (and where) is the existing data? Identify the asset data that currently exists in multiple formats â electronic, paper, in peopleâs heads, on as-built drawings, etc. That data may include condition data, either recently collected, outdated, or original with scheduled (or unscheduled) updates. Asset information might include: o Asset construction dates 41
o Original project/asset costs o Features o Location o Maintenance history o Inspections o Preventive maintenance ⢠Who are the decision makers for the assets? Identification of an executive sponsor, a project champion, a project manager, and support personnel will facilitate capture of data about the assets. ⢠What is the current process for managing that data and who is responsible for it? Who owns the process? Is the process schedule maintained? ⢠Who owns the available data? ⢠What is the reliability and quality of the data? Some asset data from other systems might be available at the airport. The IT department or a consultant can assist in identification of data sources. That data might then be imported into the CMMS database. This migration might establish most of the records (the assets) in the database, although the records might be incomplete (without location and other information). Before beginning the evaluation process, stakeholders should discuss how this data can be collected. This can be a daunting task, and is often done in phases. It could be done as airport staff execute work orders, or it could be done by contracting third parties to collect all airport asset and condition data - or a hybrid approach of the two. Often airports have previous systems already populated with asset data. Usually, this data can be migrated to a new system. Other times, data exists in spreadsheets and it can be imported into the CMMS. Many times data is available only in hard copy format and must be manually input into the new system. However, the data collection phase is usually time consuming because data exists in many places and in many formats. The availability of asset data often drives the phasing of CMMS implementation. However, planning for data collection by requiring construction projects to provide electronic asset data in an open format as part of the project close out, and working with vendors and IT staff to migrate asset data from procurement and financial systems, can help close the gap. If there is no asset data catalog in existence at the airport, there are decisions about the data that will need to be decided moving forward in the process. For example, the type of data that is stored for each asset is one of these major issues. A second issue is regarding data hierarchy, i.e. the way to store the data so that it is easily located and accessible to the user. Those two issues are addressed in more detail the next sections. 42
Asset Data Types After determining the assets that the airport wants to manage, and locating any other data sources, additional data on the assets will need to be collected and be captured in the data dictionary or data catalog. An example of the asset data that might be collected, is shown in Table 5-2. It should be noted that not all fields that are identified for asset data are relevant for all assets. In this case, units are âN/Aâ because they are not relevant for taxiways, while they would be very relevant for other kinds of assets, such as transformers, elevators, etc. Attributes for each asset will also vary. A second example is provided in Table 5.3, for an Electrical Distribution System comprising a high level asset with many lower level components (generators, distribution panels, transformers, etc.) for comparison. These examples illustrate the complexities that have to be handled by the underlying data structure in the data catalog. Attribute Data Type Unit Domain / Range of Values Taxiway ID Var N/A System generated unique id for the attribute / barcode FAC ID Var N/A ID used to reference Asset Taxiway Description Note N/A A description of the attribute Taxiway Type Combo N/A Way, Lane Criticality Number N/A 1-5 low-high Legacy Names Var N/A Previous name of the attribute Date Entered Date N/A Date record was entered into the database Condition Rating Number N/A Condition rating of the attribute Inspection Date Date N/A Date of the last inspection for the condition rating Year Built Date N/A Year that the asset was constructed Design Life Number N/A Design life Remaining Useful Life Number N/A Estimate of remaining useful life Table 5-2 Asset Data Example 1: Asset Data for Taxiway Attribute Data Type Unit Domain / Range of Values System ID Var N/A System generated unique id for the entity / barcode Asset ID Var N/A ID used to reference Asset FAC ID Var N/A Unique id for the entity System Description Text N/A Description of the asset Legacy Names Var N/A Previous name of the attribute Date Entered Date N/A Date record was entered into the database Condition Rating Number N/A Condition rating of the system Inspection Date Date N/A Date of the last inspection for the condition rating Year Built Date N/A Year that the system was constructed Design Life Number N/A Design life Remaining Useful Life Number N/A Remaining useful life estimate Original Construction Cost Number $US Cost of initial construction or purchase cost Replacement Cost Currency $US Current replacement value of the system Replacement Year Date N/A Anticipated year the asset will need to be replaced Warranty Period Date N/A End of the warranty period Location ID Var N/A GIS Coordinate, Building ID, or other location reference Table 5-3 Asset Data Example 2: Asset Data for Electrical Distribution System 43
The number of data attributes that an airport wants to store and maintain for assets depends on the needs of the airport. More data can help in making appropriate business decisions about life cycles of assets; unless the data is maintained it will not be useful. More data takes longer to collect and maintain. Deciding how much data is useful is, therefore, important. If that decision is reevaluated after the initial data collection, additional budget may be required to add more data records to the database. Asset Data Hierarchies The type of data to be collected about assets is relevant, but equally important is the way that that data is structured within the asset registry. A framework, or hierarchy, for finding a single one of the thousands of assets must be assigned within the asset registry. In fact, multiple hierarchies for finding that asset are probably desirable. How the data is organized within the asset registry determines the ease with which the maintenance staff finds specific assets. When walking through the terminal, it might be important to browse the assets by location. When repairing a specific piece of equipment, it might be important to browse the assets (and spare parts) by system. An example of an asset hierarchy is shown in Figure 5-4. Table 5-4 Sample Asset Hierarchy. In this example, the facility group might be a terminal building; the facility, a specific terminal; the system, an HVAC system; the component, an air-handling unit (AHU). The purpose of the asset hierarchy is to logically structure the asset data for ease of use. Asset Data Conversion and Migration to the New CMMS It was pointed out earlier in the Guidebook that nowadays maintenance departments are rarely doing completely manual management of asset maintenance. Whether they are using spreadsheets to track warranties, or a homegrown database to manage maintenance data, many maintenance departments have some data in electronic format. It would be beneficial to take that electronic data and import it into the new CMMS. If there is existing electronic data at the airport, data migration will likely be one of the first tasks in the project schedule after an initial installation of the new CMMS. The data migration process might entail capturing data from an older database or from a spreadsheet or series of spreadsheets. However, no matter where the data resides, there is almost certainly a required change in format between the old data and the way format is needed in the new CMMS. Therefore, there is not only the need for the data to be moved into the new database, but the data will also have to be converted into a format required by the new CMMS. In the event a data conversion is necessary, a data conversion plan should be developed. This plan should identify the source data locations, formats, and definitions, and map the data schema of the existing system into the new system. The conversion plan is typically done with subject matter experts who are knowledgeable about the legacy system and with the vendor of the new system. This assures that the legacy data will be migrated and properly represented in the new system. In addition to the details of the migration mapping, the data conversion plan identifies: 44 Facility Group Facility System Component
⢠Who will be involved in the conversion ⢠What the conversion strategy will include (e.g., timing of the conversion) ⢠The effects of the conversion on the existing system (e.g., will there be a need for a system outage on the legacy system during the conversion process?) ⢠What happens in the interim period between the conversion and commissioning of the new system (how is data updated?) ⢠How the airport will continue CMMS functions during the interim period ⢠What necessary communications are required between the legacy and new system, and the timing of those communications ⢠Contingency plans, including back-out procedures, that are needed should the conversion be unsuccessful ⢠The retention requirements for the data in the legacy system? ⢠Scripts and their execution schedule are needed to perform the conversion The scripts/programs and/or manual procedures needed for the conversion need to be developed and tested. Therefore, a test plan that identifies the business processes that are supported by data to be migrated from the legacy system, should also be developed. That data is likely to include material assets, security data (e.g., names of staff able to receive work orders), contacts, work schedules, hourly rates, facility names, and locations. Work in progress items, such as open work orders and parts on order are also typically migrated. A decision must be made about which historical information needs to be migrated to the new system. Airports have reporting requirements that impact this decision. As an alternative, the legacy system might need to remain accessible post implementation of the new CMMS for reporting purposes, if history is not migrated. After testing of the data conversion procedures, operations can be cut over to the new system according to the schedule and methods identified in the conversion plan. The data conversion should be validated and any problems should be identified and logged. If the identified data conversion issues significantly impact the ongoing operations of the CMMS, a go/no go decision must be made. Data that is converted may need to be backed-out according to the back-out procedures listed in the contingency plan. One good way to validate the converted data is to run reports from both the legacy system and the new CMMS and compare the results. For example, one can prepare control totals for the number of material items; compare the number of open work orders for a period; or determine the average time needed to complete a work order. Configuration of the CMMS As discussed in earlier sections, the selection of a CMMS should be based on the value of the features and functions of that CMMS that best support the business needs of the airport. Sometimes this just requires a detailed configuration using features and functions of the CMMS to support the business processes of the airport. In other cases however, a CMMS might need customization, either because of a statutory requirement, a legacy processes, or other general (to airports) or specific (to a particular airport) requirements. Changes to an âout-of-the-boxâ solution, particularly when the solution addresses a complex and important business area, are not uncommon. However, any customization should be evaluated on a long-term cost basis. Configuration and customization are terms that refer to changes in the CMMS software. There is a major difference between the two. Configuration refers to the process of setting up the software, using its built-in parameters to fit the airport business processes and environment. Customization is a change to the CMMS that requires writing additional code to add features or modify features of the CMMS. Customization is costly, both initially and to maintain, and will likely have to be repeated each time 45
upgrades are released by the CMMS vendor. A CMMS that is a good fit for the airport will not require customization. It will, however, require configuration. Configurations to the CMMS allow the airport to fit the software to the organizational needs. Some configurations are simple, for example the form of the asset keys or its starting point; or could be more sophisticated, such as how to prioritize a work order based on its attributes. Such adjustments are supported in the future vendor software upgrades. During the implementation process, staff responsible for configuration typically reviews a configuration plan with the airport in order to document the configurations that support the airportâs business processes. The revised, finalized configuration plan then becomes part of the project implementation plan and is retained for inclusion in the testing plan and for system documentation. Configurations may be modified after the implementation, however post implementation configuration changes should be examined carefully for impact to the system. CMMS Customization A customization is necessary when a particular base functionality of the software does not have a good enough fit with the requirements of the airport, and when those requirements are of high value. This occurs when the software is chosen because of its overall good fit for other requirements. Some CMMS systems handle customization better than others. If the CMMS has an open architecture, programmers can develop special code that is linked to the features or functions. In more sophisticated systems, vendors supply an application program interface (API) that enables the use of code to access specific features of the system and develop customizations. CMMS vendors typically publish their APIs and allow programmers to extend them. Moreover, CMMS vendors publish and make available data dictionaries allowing programmers to understand the data structures behind the CMMS. To the extent that this is available, an organization can perform modifications to standard âout-of-the-boxâ software to provide added functionality. By publishing an API and/or data dictionary, the CMMS vendor has agreed to support the published functions with new revisions and upgrades, but takes no responsibility in their implementation. However, API classes may become depreciated over time requiring reviews of these items by the airport IT support organization. When deciding if and what functions to customize, there are several factors to keep in mind. First, the decision to customize will require specialized IT and business skills to specify, develop, and test each customization. This adds time and budget to the project and makes it more complex. Second, the customized code must be tested for each CMMS upgrade, and modified if required. Many organizations have to delay version upgrades to assess the impact on customized code; or if impacts have been assessed, they might be unable to remediate those customizations because of budget constraints. Testing a system with no customizations is far less expensive and time consuming than one with customizations. Moreover, there is often a conversion needed for a version upgrade, which is provided by the vendor. Customizations can preclude applying the standard conversion supplied by the vendor. In that case, a customized conversion for the airport would need to be developed by the vendor at cost to the airport. A customized conversion also makes the upgrade process more risky to perform. When the CMMS vendor does not have a published API and/or data dictionary, it may still be possible to enhance features and functions with sophisticated IT programming skills. Under these circumstances, the CMMS vendor has no role in the customization of the system and the airport is on its own. As a result, an airport should undertake such a customization only under circumstances where there is a critical need to determine if procedures may be further optimized. 46
Integrations Integrations are not likely to be in the first phase of the airportâs CMMS implementation. Integrations are likely to be in later phases, as the CMMS matures, and as users understand its features and capabilities and how they can be used to better manage assets and work at the airport. One of the ways that users see that the CMMS improved is usually by eliminating manual data entry. Data that is being generated by the CMMS can be shared with other departments. This eliminates manual data entry into the CMMS, or into other systems by sharing common data between those systems. Another logical step to improve operations is to share business intelligence that is available through information from the CMMS. In both cases integrations are required. In the CMMS evaluation process, initial integrations were specified for inclusion in the procurement documents. The selection process took those requirements into account, so it is possible that the CMMS may have provision for desired integrations. Additional enhancements, including incorporation of mobile tools including laptops, tablets, bar code scanners, GPS receivers, digital cameras, distance measuring devices, and RFID can extend the utility of the CMMS into the workplace. Integration with financial and procurement systems can eliminate redundant data entry, improve the quality of the data, and save time. Each airport will need to assess the areas of greatest benefit, and evaluate the difficulty of any particular integration as discussed in Chapter 4. Considering integrations during a second or third phase of an implementation can improve the utility of the CMMS for the airport. The integrations that were most reported as beneficial in our surveys included Part 139 report automation, GIS integration, requisition system integrations, scheduling system integrations, and safety incident reporting. The integrations led to better reporting capabilities, but Part 139 reporting was reported as one of the most beneficial of all the integrations accomplished. CMMS Support for Part 139 Inspections and Reporting Airport safety, and more specifically airfield safety, is a critical consideration to the operations of an airport. Part of the self-inspection program at an airport is the effective reporting system to ensure prompt correction of unsafe conditions and the maintenance of inspection records showing the conditions found and the corrective actions taken as a result. The self-inspection program is codified in 14 CFR 139.327 and includes mandated daily inspection procedures, processes for resolution of discrepancies, notification requirements, and a reporting and archival system. The CMMS system must have a robust reporting structure, be capable of rapid and efficient communications, and have the capability to retain necessary data to comply with the Part 139 requirements, and to show due diligence in the airportâs assurance of a safe environment for travelers. The choice of a CMMS can, in addition to managing maintenance for the airport, also support the airportâs legal duties as they pertain to satisfying the Part 139 safety requirements. In a modern CMMS, characteristics desired for the specific support of the Part 139 requirements include: ⢠A rich reporting environment, with features such as work orders details that can be recalled at various points in the work order life cycle, and the capability to provide work order analysis to determine problem areas for larger scale remediation. ⢠A rapid dispatch capability with the option to dynamically change work order priorities sent to field staff. A CMMS should be able to use mobile devices for work orders with all necessary data needed. For example, a smart phone could be used to receive and acknowledge work orders, act as a telephone and text message center, as well as receive photos, schematics, and manuals 47
associated to the work order. The mobile device should receive all information needed so that a return to the maintenance shop is not required. ⢠The capability to generate reports or extract information needed for Part 139 inspections. Ideally, a CMMS specific to an airport would have integrations to an airport GIS containing the geospatial inventory of runway configurations, pavement management systems, airfield lighting, signage and markings, emergency evacuation paths, buried underground assets, and airport-specific service equipment such as jet ways. CMMS work orders in an airport environment would need to include the ability to link inspections with preventative maintenance work orders. Ideally, inspection checklists should be embedded into scheduled preventative maintenance work orders issued on a periodic basis with the ability to create work orders when there is a deficiency found in the inspection process. The CMMS would then show a record of the entire inspection process from scheduling the work to inspect, the actual execution of the inspection with the results, and any resulting work orders needed to address the inspection problems. In this manner, metrics can be taken for the time needed to perform the process and analysis can be made. The case studies in Appendix A cite methods that two airports used in incorporating Part 139 requirements into their CMMS workflow to provide automated reporting to satisfy FAA requirements. Post Implementation The CMMS is implemented. Perhaps planning is underway for the next phase. Staff is learning the system. Training is ongoing. The airport has to provide resources for maintenance of the CMMS itself, and the CMMS data. In Chapter 3, the stakeholders involved in maintaining CMMS were identified. These stakeholders all have a role in the operations of a CMMS both during and after the initial implementation. This group is responsible for the operations of the maintenance functions that the CMMS is used to manage on a daily basis. Often, though not always, multiple departments are responsible for maintenance functions at an airport. For example, noise and flight tracking equipment, repairs and upgrades may be the responsibility of a noise reduction team outside of the facilities group. Environmental wells and measuring equipment may be the responsibility of a planning group. All assets could still be part of the CMMS, even though the maintenance procedures are managed by different business units. Each of the business units have different requirements and judge success of the implementation based on different requirements. An ongoing working group comprised of members from each business unit should meet regularly to assess that the needs of each business unit are being met. Planning for upgrades and additional functionality could continue through the working group. The group could assemble and determine standard rates, metrics for evaluation of actual performance, distribute reports and establish that the policies and procedures for the CMMS. This group would decide on business metrics from data collected in the CMMS, distribute information about the system, provide the means to distribute training, and receive feedback on the operation of the CMMS. All stakeholders should be given the opportunity to feedback to the working group. 48
The airport will need to dedicate resources to the ongoing maintenance and operation of the CMMS. The level of resources needed will depend on how the CMMS is implemented, whether it is a hosted solution or whether it is deployed and managed internally. If mobile devices are part of the solution, there needs to be a mechanism to manage the distribution of those devices. If the number of end users is high, the management of the end devices can be a major task. Many organizations are now beginning to struggle with corporate policies on mobile devices, whether and to what extent must these mobile devices be locked down in terms of capabilities, the extent of geolocation, even including access to the internet, type of phone calls being made and other policies unique to mobile device security. Depending on the device being deployed and the intention of the airport, there are many factors involved in the management of the core CMMS and those devices that are distributed in the field to staff. Limitations on the distribution of data often affect the ultimate effectiveness of the CMMS.. IT support will be required as new functionality is implemented regardless of whether the CMMS is on a hosted platform or is managed by the airport. Version changes typically are preceded by database conversions and these conversions must be examined to determine whether there is any adverse impact. As previously discussed, any specialized customizations are particularly vulnerable and it is important that a proper testing environment be maintained and used. When implementing a full scale CMMS, adequate budget and staffing must be allocated to the system once it is live. The ongoing responsibilities go beyond merely supporting the CMMS and must include how the CMMS becomes part of the cultural fabric of the airport. As with any system implementation, benefits are realized with maturity and realization of the systemâs capabilities by the staff. An evaluation of the airportâs requirements and a selection of a good-fit solution for those requirements is a very good start. But the implementation will take time, and will progress in phases that bring more benefit over time. The realization of the benefits of a CMMS will grow as the airport matures in its implementation. 49
