Fast Track Products
This checklist identifies high-level Information Technology [IT] issues that Chief Information Officers [CIOs] and IT Managers must be aware of prior to implementing an Electronic Recordkeeping System [ERKS] within their agency.
It should be noted that the distinction between IT issues and records management [RM] issues is somewhat artificial. Most of the issues listed below have implications for both IT and RM, and indeed, there is some overlap with those issues discussed in Preliminary Planning for Electronic Recordkeeping: Checklist for RM Staff.
Have you determined how records management fits into your agency's overall information management strategy?
Most information management programs are designed to improve control of the information an organization collects, creates, receives, processes, uses and distributes throughout the life cycle of the information. An effective program will provide easy access to information specific to given work tasks, reduce redundancy of information creation and storage, permit reuse of information, and clarify ownership of policy, process and procedural information.
Records management is a key component of information management for several reasons:
- It is one of the most disciplined and well-defined components of information management.
- It brings critical business records under control of the agency.
- It can provide a single point of access to important records previously controlled by functional areas or specific individuals.
- It supports record authenticity and reliability.
- It permits access to records throughout their life cycle for use and reuse, protecting their structure and context, as well as their content from alteration or revision.
- It permits the attachment of retention and disposition instructions to critical business records.
- It can manage both hard copy and electronic records.
Records management is also required of all Federal agencies. All records made or received by a Federal agency that document its organization, functions, policies, decisions, procedures, operations and other activities -- regardless of who created it or how the information was recorded -- must be identified, classified, retained and disposed of in accordance with procedures authorized by NARA.
Does your IT organization understand and support records management?
With so many institutional records now being stored electronically or managed through electronic data systems, records management programs cannot be effective without the enthusiastic participation of the agency's information technology organization. Conversely, because so much of the data contained in an agency's systems are electronic records, incorporating ERK functionality enables agency and IT objectives to be met.
Do you have an effective team which includes information technology, computer security, records management, legal, finance, audit and program staff working on ERK planning and implementation?
Each of these groups has unique, and sometimes inconsistent requirements for ERK. These requirements must be identified and incorporated into the design of ERK systems to provide the functionality required by each group, if the systems are to effectively manage reliable and authentic records for as long as they are needed and no longer.
Each of these groups is a stakeholder in the electronic recordkeeping process and has a specific role to play in the implementation of ERK, specifically with regard to resolving sometimes inconsistent requirements. It is important to determine these roles early in the planning process as this may identify additional requirements that need to be incorporated into the system design. The implementation will not succeed without the support of all these groups.
Does your agency have an information security program sufficient to support reliable and authentic records?
Information security provides one of the chief points of shared interest and potential collaboration between records management programs and the priorities of information technology organizations. Protection, preservation, and responsible systems of access to computer-stored data, including electronic records, will be vastly enhanced if the IT organization has an active and responsive program of information system security. If the agency's systems cannot support the integrity of the records and provide ample evidence of their authenticity, the agency will be in a poor position to protect its rights or the rights of citizens affected by the agency.
Records act as the 'voice' of an agency in legal proceedings. As such, the information security of record-generating systems, and indeed, of the electronic records themselves, is paramount in assuring that records will serve as reliable evidence of agency actions and that this reliability is guaranteed over time (i.e., authenticity). Failure to ensure such reliability, via suitable information security, can call into question the recordkeeping practices of an agency (i.e., "arbitrary and capricious practices") presenting substantial legal risk to an agency.
Does your agency have a program for long-term management and retention of electronic records?
Satisfactory management of electronic records requires that records be actively managed throughout their life cycle: from creation, through all phases of access and use, to final disposition, whether that is permanent storage or eventual destruction. It is important to understand the distinction between the life cycle of records and the life cycle of information systems that create, manage and use the records and the life cycle of the media on which the records are stored. The life cycle of records often exceeds the life cycle of the information system in which the records are originally created or captured. Likewise, some storage media will significantly outlast the hardware and software necessary to retrieve and display the records stored on them. To successfully manage and maintain electronic records, it is important to determine if the records will be needed beyond the life of the system where they are currently stored and, if necessary, to plan for the migration of the records to a new system before the current system is retired.
Migration strategies to counteract the hardware and software dependencies of electronic records are essential for the long-term management of records. When moving to new hardware and software environments, either for program-specific IT systems or generic desktop applications that generate electronic records, there are several issues that must be considered:
- Will the system/software changes cause your agency to re-think the record retention status of information to be generated by the new system/software?
- Are all extant records from the old system/software going to be migrated to the new system/software (i.e., will 100% of the extant record content and metadata successfully convert, or will there be loss)?
- Has the agency developed comprehensive migration process documentation providing detailed data mappings between the old and new system(s)/software?
- Have plans been made to retain the old system(s)/software until an audit establishes successful record conversion from the old to new system(s)/software?
- Will differences exist between the records generated by the new and old system/software that will require new record schedules (i.e., RM business rules) for records generated by the new system (i.e., revise the description or disposition instructions in the records schedule)?
Does your agency effectively manage its metadata?
Metadata is a term that describes or specifies characteristics that need to be known about data in order to build information resources such as electronic recordkeeping systems, and to support records creators and users. From a recordkeeping standpoint, metadata is part of a complete, reliable and authentic record. It provides sufficient information about the context in which the content of a record was created to determine who created the record and under what circumstances and how the record relates to other records. Metadata also provides information about how the content of the records was structured and how it was accessed. Without capturing the necessary metadata you cannot capture a complete, reliable and authentic record.
For an ERKS to work efficiently, it is also necessary to capture specific kinds of metadata for each record such as a unique identifier, disposition instructions, and access restrictions. Many universities, corporations, Federal agencies, and other types of organizations have established programs to manage their metadata. Those organizations that do a good job of managing their metadata will have a greater chance of successfully implementing electronic recordkeeping than those organizations that do not.
Has your agency identified its electronic records?
Before agencies can develop an effective plan to manage electronic records, they need to identify the records they currently create and receive. This information is important because the products available to support ERK vary considerably in the functionality they provide. A thorough assessment should be made of: the types of electronic records (word processing, spreadsheet, database, html, e-mail, presentation), the numbers of records (including the total volume of records to be managed, total created per day, total received per day), where these records are currently stored (on mainframes, personal computers, file servers, in databases and information systems), how often the records are accessed/used for normal business and also for FOIA requests, who manages and destroys the records, and to what extent the records are redundantly created and stored.
Have you determined the scope of your system implementation?
The scope of your system implementation is one of the earliest, and most critical decisions you have to make. In general, there are several critical implementation issues to consider with respect to "scope":
- Whether or not to install separate systems for electronic and paper records.
- Whether or not to install a single system, or separate systems for some record types.
Some types of electronic records present unique problems that might make it impossible or impractical to implement a single solution for all records types. For example, an agency might conclude after assessing its electronic records that recordkeeping functionality should be included in the design of all information systems and all other electronic records will be managed by a single system. Another agency, because of the volume of e-mail it generates, the number of FOIA requests it responds to, or the number of software products available to manage e-mail records, might determine that a separate system should be implemented to manage electronic mail.
- Whether or not to install a single system, or separate systems for sub-organizational units or functional areas.
Many agencies may decide it isn't feasible to implement a single ERKS and opt to install systems at the Operating Division level or some other sub-organizational level. This might be the case when sub-organizational units have very different records management issues to address, are very large, are very independent, or are geographically separated. Also, as functional areas install document management systems that are optimized for their specific business processes, those areas may want to use the RM functionality that is integrated with the document management product they purchase. These possibilities must be considered fully during early planning for your system implementation.
Although your implementation plan will include phased implementation, it is important that you envision the most effective and sustainable implementation configuration for your organization when all phases of your electronic records management system(s) are complete -- and plan for the needs of that longer term vision.
Does your agency understand numbers and types of end user roles associated with implementing this type of initiative?
As with most IT products, ERK products are designed to support a total number of installed seats or a maximum number of users connected to the system at the same time, so an overall estimate of expected users and an estimate of expected concurrent use is necessary. But many ERK products also distinguish among three types of users and provide different interfaces and functionality for each type--so an estimate of the users who will be coordinators, contributors and consumers is also necessary.
Coordinators are records managers, who typically require a system to manage electronic records, the file plan under which records are categorized, and end user access to ERK application functions. Coordinator functions include:
- Developing and updating the file plan
- Controlling access
- File and box handling
- Tracking the location of records through charge-in and charge-out processes
- Records center capabilities such as inventorying and shelf management
- Managing retention and disposition
- Report and bill generation
- Managing objects from source applications, including desktop applications, e-mail, and the web
- Managing EDMS, multi-EDMS, and extra-agency sources of information
Contributors are end users who create, possibly file and classify, search, request, and retrieve records. ERK software should make records management functions invisible to the user. This is a two-sided requirement. On the one hand, ERK software should make designating and classifying records as painless and unobtrusive as possible. On the other hand, the software should provide simple but rich capabilities for searching the repository.
Consumers are end users with read-only access. They may search, request, retrieve, and view records. They also require a usable, simple, non-intrusive system -- one that allows casual users to access records with minimal training.
An estimate of how many records management transactions a typical user might make in one day should be calculated. If an enterprise system is planned, it is important to estimate potential users by business unit and geographic location, in order to make the best decisions about repository replication, application integration, and implementation strategies.
- Has your agency done a cost/benefit analysis for this initiative?
Such an analysis is required by the Clinger-Cohen Act. In addition, a cost/benefit analysis may cause the project proponent(s) to change the scope of the initiative or the plan of work to maximize the benefits of ERK for the agency.