Sophisticated facility management software provides facility executives with a powerful tool that can make it much easier to manage a facility or portfolio. However, as with many technology acquisitions, pitfalls lie at every stage in the process.
Computer-assisted facility management, or CAFM, systems pull data from several sources — including CAD systems, human resources systems and enterprise resource planning systems — and link them in a robust, user-friendly front end that displays comprehensive information in real or near-real time. This enhanced functionality can be used to produce reports; to expedite employee moves, adds and changes as well as major moves; to track physical assets; to manage real estate portfolios; and to justify cost allocation and charge-back activities.
CAFM systems range from limited applications to comprehensive programs and programs-within-programs that may include computer-assisted maintenance management systems, or CMMS. CAFM choices generally fall into two categories: in-house and application service provider (ASP).
With in-house systems, customers purchase the software plus any additional computer hardware needed to run the software. In-house systems must be housed, maintained and backed-up by the customer, placing additional demands on IT department resources. The customer will likely need to purchase successive upgrades as they are rolled out, or risk obsolescence. Vendor technical support will likely come at a cost to the customer, either immediately after purchase and installation or at some point down the road. The customer must continue to train its employees in the technical maintenance of the software program, incurring a variety of associated risks and costs. Ownership of the software also carries the additional risk that the vendor might cease operations or stop supporting the product at some point, leaving the customer with few options in the event of a problem, and, potentially, large sunk costs.
With an ASP, the customer purchases a subscription to use software based remotely at the vendor’s site. The customer accesses the software via a secure Internet connection. The ASP provider houses both the hardware and software, and performs technical maintenance and upgrades. With an ASP, the customer’s IT department may be concerned about breaches of security where data must be transferred remotely through company firewalls, not to mention loss of control, whether actual or perceived, over the company’s data. There is also the possibility that the ASP’s equipment might fail, or that disaster might prevent access to data or cause data to be lost.
For many users, ASP solutions offer clear cost savings. Renting is often cheaper than purchasing, and rental costs can be expensed rather than capitalized. Some ASP solutions offer upgrades as part of the subscription rate for using the software. With the ASP model, the risk of lost or inaccessible data becomes largely an inconvenience, a temporary loss of functionality. Source data remains safely stored on site at the customer’s company. Direct financial losses are limited because the software is rented and not owned by the customer, and the onus for getting the system back up and running lies squarely with the ASP provider, which risks losing subscribers should the frequency or severity of service interruptions become unacceptable. ASP solutions limit training costs. There is no need to train employees to debug, update or otherwise modify the software code.
The first issue prospective buyers must deal with is sourcing and procuring the correct solution. A formal procurement process is time consuming but necessary to ensure the best value is purchased and the system conforms to internal validation requirements. This process will usually involve a request for information, a request for proposal, vendor presentations, and a request for quotation and negotiations with potential vendors.
When the procurement team — usually made up of representatives from facility management, purchasing, corporate finance, IT and human resources — selects a solution, negotiations with the vendor commence. A range of key items may be negotiable, including the cost of the solution and any optional functionality or services; the structure of the payments; the level and duration of vendor support; issues of ownership of the software code in the event the vendor ceases operations; and, perhaps most import, the method for determining when implementation is complete and what deliverables the CAFM software will produce once installed.
After a purchase is made or a contract is in place, the customer and vendor should both identify an implementation project manager and team. The customer’s team will often consist of representatives of the same groups involved in the procurement process. The customer should make sure that its team is absolutely comfortable with the vendor’s team, as they will be working closely for some time. Several factors will affect the level of effort and the time commitment required of the implementation team.
In-house systems require the customer to commit space, equipment and technical resources to set up and maintain the host server and software. The ASP approach eliminates this burden. With in-house systems, technical support personnel will need to be trained, as will system users. ASP solutions require only system users to be trained.
Initially, floor plans will need to be entered into the CAFM system and “polylined,” a process whereby each space is delineated. The larger and the more diversified the customer’s real estate portfolio, the longer it will take to complete this process. Similarly, the greater the variety of building types, workspace types and asset types, the greater the task. Often, a phased-in approach makes the most sense, with the CAFM administrator adding information for one or two buildings at a time to the CAFM system.
Anomalous seating arrangements — such as several persons occupying a fixed wall office meant for one person or persons occupying more than one workspace — can pose challenges and force compromises that may have far-reaching impacts. For example inaccurate headcount reports might be inaccurate if a shared office is counted as one employee or if an employee occupying multiple workspaces is double counted. The vendor’s implementation team might not anticipate, appreciate or communicate the consequences of such compromises. Worse, the vendor’s team might make arbitrary decisions on behalf of the customer without the customer’s full knowledge and consent. By the time the consequences of these decisions become evident, the implementation is often complete and it might cost extra to correct the problem.
Once each space has been polylined, the CAFM system is ready for personnel and asset data to be added. This will usually require the assistance of several database administrators, who will need to develop queries to isolate the specific data the CAFM system will need and to program automated uploads to the CAFM system. In the case of an ASP solution, it is particularly critical that only select data be transferred.
Process flows must also be analyzed to ensure that data that is updated is not subsequently overwritten by obsolete or incorrect data. Consider the following example of what can go wrong.
Suppose an HR database provides employee names to the CAFM system while an IT telecommunications department database supplies workspace location. Each week, information from those databases is automatically combined and uploaded to the CAFM system.
The day before the next upload, the HR department notifies the CAFM manager that an employee will be relocating to another workspace. The CAFM administrator updates the CAFM system to reflect the new location of the employee. But because the telecommunications department database is not updated before the next upload to the CAFM system, old data from the upload overwrites the correct data and the employee is relocated back to the original workspace.
It is important for the customer’s implementation team to require that several uploads take place before signing off on the installation. That provides an opportunity to uncover and correct process deficiencies. In the example above, the process for updating the telecom database should be modified. One solution is to ensure that all updates were completed prior to each CAFM upload. Another solution might be to link the CAFM system back to the telecom system so that simultaneous updating could be performed.
Another issue that frequently arises concerns terminology to describe space. Leased space, rentable space, usable space, occupied space, allocated space, common space and shared space are just some of the terms used. One CAFM system, in its standard reports, uses the term “usable workspace” to refer to the combination of assigned workspaces and shared (common) areas, excluding unassigned workspaces from this category. For organizations where “usable workspace” has been used to refer to all potentially available workspace and common areas, the CAFM system might have to be modified so that it uses the same terminology as the organization. This will involve the creation of at least one custom report and potentially could involve modification to all standard reports. If this issue is identified during contract negotiations or early in the implementation process, the customer is more likely to avoid additional cost while obtaining the desired report terminology.
With some CAFM solutions, standard reports roll up to the number of rentable square feet as a default. This number excludes vertical penetrations such as elevator shafts. Senior managers who are used to seeing reports that roll up to the actual number of leased square feet might balk at the new reports. The implementation team should compare the results of the CAFM system’s standard reports with prior company reports to uncover inconsistencies in terminology and methodology. Usually, such inconsistencies are easily corrected, but the facility executive might have to decide whether to address the issue globally or with a custom report.
Every company is different, and despite the attempts by CAFM software developers to create one-size-fits-all reports, it is quite possible that a company’s senior managers will not be satisfied with these generics. The customer’s implementation team should review all standard deliverables prior to sign-off to ensure that out-of-the-box reports meet the organization’s requirements.
Problems with CAFM systems might not manifest themselves immediately. Occasionally, the vendor’s implementation team will have made decisions that result in unexpected consequences. Process flow issues might only be seen after several reports are run. Some problems might require technical support.
CAFM technology can greatly improve the ability of facility executives to perform their jobs, but the key to successful deployment lies in paying close attention during each stage of the process.
John F. McPartland is senior vice president of operations with the Massachusetts Innovation Center.
