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 structure
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.