For the past two months we’ve discussed the basics of facility databases and how to avoid the common pitfalls when setting one up. This month we’ll round off the discussion with two key points. First, we’ll explore where the data comes from that needs to be managed. After that, we’ll get into the design of the database—categorization and organization of the data.
Data Generation
When designing a database of facility data, make sure you track the right kind of information. This is more challenging than it might seem because we must examine not only our current day needs, but also what might be of importance down the road. The sections that follow describe elements to consider as you set up your databases.
- File Management: Since most laptop computers now have tens of gigabytes of storage capability, you are much less likely to exceed the storage capacity of the system than even a few years ago. Keep in mind, too, that our computers are usually connected via modem to servers that have substantial data storage capability. File management is the process that we use to review files on a recurring basis to determine whether they are needed anymore. Files can be transferred for storage, or they can be deleted, all at the click of a mouse or trackball.
- Large Number of Fields: Leasing programs often require the largest number of fields for storing various forms of data. A full-blown leasing system, with records of space you lease to others and space you lease as a tenant, may require as many as 400 fields. While the number of records may not be that great, the sheer number of data fields may require a powerful program and lots of memory to load.
- Data Tracking: Why do you need certain facility data? What will you do with it? For each program or activity, you must decide what is worth tracking and what is not. For example, you may opt not to track data outlet locations or cabling routes because they change too often to warrant the level of effort necessary to keep up with the changes. Gathering, entering, and updating data are costly steps, and many facility departments do them poorly because they fail to realize how much time, effort, and money are actually involved. Some important questions to consider in data tracking are covered in the points that follow.
- Data Selection: How much data should be tracked on each item? All databases, especially automated ones, are capable of storing all sorts of information, including things you may not need to know. Therefore, it is critical to select the right system(s) and vendors so you can store and manage the data you need to manage, rather than what the vendor’s system is programmed to store. Eliminate what you do not need, but always reserve the option to track it later.
- Data Conversion: What types of data should be convertible from one form to another? For example, how important is it to have floor plans in hard copy, on disk, transmitted over a telephone line, and/or on a teleconferencing screen? Converting data from one form to another involves more software, more input devices, more cost, and more personnel.
- Data Retrieval: How easily retrievable must the data be? It is important to decide who can access your data, who can access certain types of data and not other types, and whether these people can access the data directly or must call you to retrieve it. There must be a sharp distinction between retrieving data (a relatively easy task) and editing it (a task usually restricted to a few key people). Shared access to data is also important to all departments that require similar information. But, as noted by Gloria Hoffman and Pauline Graivier in their book Speak the Language of Success, “Facility information is shared across user and applications group boundaries. . . . It is very difficult to design and develop a comprehensive facility management system as a series of distinct applications.”
- Required Flexibility: Specific projects and information are stored in huge corporate-wide databases according to file-naming conventions that make data retrieval impossible if you don’t know the name, and easy if you do. A particular procedure must be followed to enter and retrieve information. Anyone that needs to use the database must be trained in its use. These individuals become familiar with how information is stored, how reports are generated, what information can be changed and by whom, and many other details. Sophisticated database systems are expensive, and they take a long time to develop, field-test and implement. Often, levels of access are built into the system so that certain high level information can be controlled and managed strictly by those with a need to know.
- Documentation: How much documentation should you keep, and for how long? If you store records of transactions, they can accumulate at a surprisingly fast rate. The further back you go, the better your historical record and your ability to analyze trends, but the more space you will require. Whatever your decision, it is important to establish procedures for everyone to follow to ensure uniformity. Today’s data storage systems provide immense resources for data collection and retention. Such systems are often linked with data back-up systems to assure redundancy of information. Data back-up and system upgrades are preplanned for off hours to minimize disruption of the system during normal daily operation.
- Customer Involvement: How much information will your customers provide, and how will they get it to you? If customers provide you with such information as data needed for a service call (who placed the call, the nature of the problem, their organizational code, the cost center, and the date of the call), who will enter that data—you or the customer?
- Inventory vs. Transactions: How does tracking inventory differ from tracking transactions? Most facility management groups that are automating their operations choose to automate inventories of parts, space, names of landlords, occupants, tools, furniture, equipment, and other commodities that change relatively little: that is, only when an item is deleted or added.
Transactions are more complex. In this case, you are tracking what you do, not what you have. Multiple questions arise as the task or plan develops, even for a relatively simple service call. For example, who will do the work? When will it be scheduled? What tools will be necessary? Who must be notified prior to beginning? What is the required lead time? How long will the installation take? The higher the churn rate, the more frequently the database must be accessed and modified. - Capacity vs. Speed: Have you considered what it will cost for capacity and speed? If you want both, be prepared to spend more. Powerful software search features and flexible report generators cost more, but with CAFM systems, the most significant costs are for customizing interfaces. You will also spend more for enough computer memory to mount large software applications and retrieve large data files and more for disk space to store everything, especially graphics, photos, and video.
- Breadth and Control of Information: What types of procedures must be established to manage and control the information you have? The size and scope of your inventory will significantly affect how you design a database. On the other hand, if you are responsible for one building, for example, the records required can be contained in a single system of automated and non-automated media kept in one room and perhaps managed by one person. Today’s systems are often linked by fiber optic lines so that information can be accessed through a central location (a server) and shared. Stand-alone systems are found solely in smaller applications that involve one or two buildings or part of one floor. The reasonable costs of today’s systems, combined with their inherent power and memory capacity, make it relatively affordable to link all computers so that information is shared and always up-to-date.
Whatever the size and scope, procedures must be established to ensure that records on different buildings are managed in the same manner. You must decide issues such as whether to keep all records in a central location or to set up a network of sites where information is kept, what types of records will be kept where, who can make changes, and so on. If you are managing an inventory that covers several cities, other factors become significant. For example, how will you transmit data electronically between sites? Which data will be maintained locally at each building, and how will local data be incorporated into summary records? What procedure do you have to ensure that the same up-to-date data are at every site?
The Design of a Database
The range of common technology now available means that any data that can be typed, written, spoken, or drawn can be entered into a database. Whether in an electronic or hard-copy format, databases are organized around one or more files; that is, collections of related data. Files generally contain records related to one facility. Each data item in a record is stored within a field—a space defined to contain the data item. The user defines files, records within files, fields within records, and data within each field.
Data in a database can be categorized in the following four groups:
- Location data:Places in a building, such as floors, room numbers, or a particular bay in a column grid. This category is easiest to understand by viewing graphic representations of groups of locations or plans.
- Object data: Those elements or components of building systems such as chillers, fans, window units, or furniture. Information about the objects, such as tracking manufacturers and model numbers, is useful on a continuous basis. In this sense, objects are often referred to as assets.
- Action data: The things done to or in a building to benefit the occupants, or to guarantee the continued operation of the building’s systems, such as service calls, work orders, project approvals, or preventive maintenance visits.
- Financial data: Information about locations, objects, and actions such as material cost, labor cost, and other budget items.
In Contact: A Textbook in Applied Communications, by C. Jeriel Howard and Richard Francis Tracz, there are five data types common to all facility management applications. Briefly summarized, these five data types are:
- Documents: Collections of information; objects created for presentation, such as word processing textual documents, spreadsheet and business graphics, CAD files, and voice mail messages.
- Attributes: Descriptive information attached to a piece of data to help identify and describe it. Examples include the part number, style, color, finish, brand name, manufacturer, and condition of a chair. Attributes can be used to set up data tables within a database management system.
- Spatial designations: Similar to an attribute, but this information refers to a specific geographical or spatial location, such as room boundaries, equipment locations, and HVAC ductwork.
- Transactions: Groups of activities, such as receipt or allocation of inventory items, work requests, and performance logs, that change attributes in a database.
- Schemes: Groups of information organized by specific parameters, such as information organized to describe a project’s status.
There’s so much information you need to know to create and maintain a database, maybe it’s worthy of a database itself. This three-part series of articles, I hope, will help you to set up or mend your own facilities database. The information presented is taken from BOMI’s Fundamentals of Facilities Management, ©2003.
