IBM Enterprise Records, Version 5.1.2   

IBM Enterprise Records components

In IBM® Enterprise Records, records are stored in a hierarchical structure that contains record management components, such as data models, object stores, and file plans.

Data models

Before you install the IBM Enterprise Records application, you must choose the type of installation (data model) that most closely fits your records management needs. A data model is a template for a file plan object store compliant with certain records management standards. The data model can include metadata and security features.

The data models are contained in add-ons that you can add to your environment. You can configure your object stores to use the selected data models.

When you create a file plan object store, you must select a data model. The following data models are available:
Base
Provides core records management functions and properties. The Base data model is the most common installation because it adds the minimal number of properties and works for most organizations. Functionally, the Base data model provides the same capability as the DoD Baseline data model. The Base data model is sufficient for meeting most records management requirements. However, it does not adhere to either the DoD, DoD Classified, or PRO standards.
DoD Baseline
Fulfills the Department of Defense (DoD) 5015.2 baseline standard. This Department of Defense document describes how records must be managed according to Department of Defense standards. In addition, the DoD baseline data model defines specific system interfaces and search criteria. The data model also describes the minimum records management requirements that are based on current National Archives and Records Administration (NARA) regulations.
DoD Classified
Fulfills the Department of Defense (DoD) Chapter 4 requirements, including classified records management. Includes the properties that are required by version 2 of the DoD Classified standard (DoD 5015.2) for managing classified records.
Public Records Office (PRO)
Satisfies Public Record Office (per UK standard) requirements. Includes the properties that are required by the PRO 2002 standard. The PRO data model is deprecated.

Object stores

An object store is a repository of objects and a suite of accompanying storage and retrieval services for these objects. An object store can be one of the following types:
File plan object store (FPOS)
Contains the file plan, that is, the entire hierarchy of record management entities that you create.
Record-enabled object store (ROS)
Contains documents that can be declared as records in an FPOS.
Configure separate object stores for records (metadata) and documents that are declared as records. Therefore, the FPOS contains the file plan structure, while the ROS contains documents, some of which are declared as records. You need the file plan object store repository to contain the records management objects that are needed to classify records. You need the records-enabled object store repository to contain the documents that you can declare as records. Typically, many users can have access to the ROS but not to the entities that make up your file plan in the FPOS. You can have more than one ROS associated with one FPOS.

You must decide how documents are stored, declared as records, and scheduled for disposition. Organize your file plans, object stores, record categories, and records to best handle the requirements at your sites. For example, a file plan is a structured filing schema that a records management system uses to support a retention schedule. This schema is based on a business classification scheme. There is no universal file plan for all companies. Each file plan is unique and depends on the businesses a company or organization deals with. The purpose of a file plan is for record administrators to manage retention and disposition of records. It is used to enforce records management policies.

The following figure depicts the hierarchical structure of these entities.

Figure 1. IBM Enterprise Records hierarchical structureThis graphic depicts a hierarchical structure of records where a file plan object store is at the top level.

File plans

A file plan defines the organization of records. In a file plan, you store records in a structured hierarchy that preserves the context of records. For example, the LEG100 Category can have a definition that is Legal contracts related to xxx. So, by looking at the file plan location of a record that is placed in the LEG100 category, you have context of what the record is. You can create file plans that reflect business functions of the organization. You can then catalog records under these file plans that are based on these business functions. You can create a file plan for the human resources or finance organizations.

You can also associate a naming pattern with a file plan. All entities that are created under the file plan follow the record naming pattern. A naming pattern provides a way to automatically name record categories, record folders, and records to meet your conventions. For example, you might require that the record folder naming convention is year, space, subject (metadata) of the containing category, space, and a five-digit number (2006 LOAN 00005). To automatically name records, you can associate a naming pattern with the parent container. The record pattern is a property of the container. All records declared into that container acquire the next name in the pattern sequence and increments according to your configured values.

The following outline is an example of a file plan hierarchy:
General management (category)
     Correspondence files (folder)
     Program briefings (folder)
          2013 Management training conference (volume)
          2014 Management training conference (volume)
Information management (category)
     Correspondence files (folder)
     Operator's number sheets (folder)

Record categories

A record category categorizes a set of related records within a file plan. Record categories are created to catalog records based on functional categories. The most common file plans categorize records along functional lines. At the top level of the file plan, you have the major functions like Legal, Sales, and HR. Following each of these functions, you further categorize the records. If you are using functional categories, then you are using the categories at the start of the file plan. Records from HR are in a separate tree from Legal. So if you have a contract, it is placed in the Legal tree or HR tree, depending on which functional area it belongs to. A record category can contain subcategories or record folders, but not both. You can associate retention and disposition rules with each category. These rules apply to all record folders and records that are created within the category.

Record folders

A record folder is a container for related records. You can use a record folder to manage records according to the specified retention periods and disposition events. For example, invoices get filed to the Invoice folder. There is always an open volume in the folder. A new volume is opened regularly (week, month, quarter). When the new volume is created, the old volume is closed and starts its disposition. All of the invoices in a volume are deleted when the volume expires. So, you are not doing disposition that is based on information in the record, such as ContractClosed. All records from a specified time period are automatically deleted as a single unit. You can create electronic, physical, and hybrid record folders under a category to manage electronic and physical records.
Electronic folder
Used for storing electronic records. An electronic folder can also contain markers. A marker is an electronic entry for a physical record that cannot be stored in a physical file. Examples of such records are large building plans, videotapes, or a database. When you see Physical Record in the diagram earlier, a marker that points to the record is what is stored in the folder.
Physical folder
Stores records for physical items such as paper records. A physical folder is a virtual entry for a paper folder. Based on the physical storage structure of your organization, you can model the hierarchy of physical folders in IBM Enterprise Records.
Box
Models physical entities that contain other physical entities. For example, you might create a warehouse that contains shelves that contain boxes that contain physical folders. A box can contain another box, a physical folder, or a record.
Hybrid folder
Can contain both electronic and physical records, in case you have the need for this type of combined collection. A hybrid also contains one or more volumes. There are no behavioral differences between an electronic folder and a hybrid folder. However, a hybrid folder has more metadata that describes a physical entity. This metadata includes the home location, which is the current location of the physical record.

Volumes

A volume is a logical subdivision of a record folder into smaller and easy-to-manage units. A volume can exist only in a folder. A record folder always contains at least one volume, which is automatically created by the system when a record folder is created. Thereafter, you can create any number of volumes in a record folder.

Records

A record provides metadata about a document or physical object that is placed under control of IBM Enterprise Records. A record can inherit some of its behavior from the record folder in which it is created. For example, it inherits the disposition schedule of the parent record folder. You can categorize records into the following types:
Electronic record
An electronic record points to an electronic document.
Marker
A marker points to a physical object or paper document.
Vital record
A vital record is required for meeting operational responsibilities during an enterprise-wide emergency. Vital records are required to have a periodic review and update.
Permanent record
A permanent record has sufficient historical or other value to warrant continued preservation by the organization. This preservation lasts beyond the time that is normally required for administrative, legal, or fiscal purposes.

Record types

A record type is a categorization of records that are based on common features among the records. You use record types when a group of records has a different disposition schedule from the one associated with their record category or record folder.

For example, it might be necessary to keep an employee record file for 12 years for accounting or payroll purposes. However, for performance appraisal records that must be retained for only seven years, you can create a record type with a different disposition schedule. You can associate performance appraisal records with this record type to ensure that appraisal records are deleted before an employee record file is deleted.



Feedback

Last updated: November 2013
frmpp077.htm

© Copyright IBM Corporation 2013