Understanding the data to be stored in your IBM Enterprise Records repository, along with how, when, and who creates the data, is key to a successful records management deployment. The considerations vary dependent on whether your enterprise document and records repository is to be used to retain a subset of your enterprises documents, such as client documentation or corporate legal documentation, or whether it will store all records for the entire enterprise including all line-of-business records, and administrative records. Figure 5-2 illustrates this data dilemma.
Figure 5-2 The data dilemma
When you are able to make an informed decision on the type of information to be stored in the repository, how it will get there, and how it will be identified, you must design and configure your document and record classes with the appropriate metadata. As described in Chapter 2, “IBM Enterprise Records system and architecture” on page 35, when a new record is added to IBM Enterprise Records, the content is actually added initially to the record-enabled object store (ROS) and for records management purposes is filed into the file plan object store (FPOS). Given most users will only interact with the ROS, there needs to be sufficient metadata to allow you to identify and retrieve the content from the ROS. The content identification metadata stored about the item in the
What? Supplier Contracts Client Contracts Referrals Invoices Letters of Offer Employee Contracts Policies Receipts Claims Procedures Invoices Leases Retail Who? Administration Accounting Customer Service Brokerage Underwriting Marketing Payroll Human Resources Training Information Technology Legal Commercial Production Logistics SEC Requirements Why? OH&S Fiduciary Requirements Regulatory Requirements HIPAA Privacy Requirements Hazcom Requirements Prudential
Requirements Requirements Taxation
How? Product Number Customer ID Policy Number HIPAA Document Type Claim Number Employee ID Agreement Number Campaign Date Received
FPOS is required for primarily for records management and compliance purposes. It is the combination of document class metadata and record class metadata that, when combined, provide the complete metadata profile of the record, as illustrated in Figure 5-3.
Figure 5-3 Complete record metadata profile
After you understand the origins of the information to be added to IBM Enterprise Records and how it will be identified, the underpinning platform must be prepared for use, to support the business requirements for documents and records.
5.2.1 Document and record classes
After your platform is installed and configured for operation, the next step is to determine which document classes in the ROS will be records-enabled and how those document classes map to the record classes in the FPOS.
Records-enabled document classes
Even though you can declare any document object as a record, there are many configuration-related objects in a ROS that you might not want to declare as
Note: A record metadata profile is the combined metadata of the document
which classes you enable for record declaration. Figure 5-4 shows a
customer-defined document class (starting with ILG) that is records-enabled. This document class is defined in the RB ROS object store, which is the ROS for our case study. A document class is records-enabled by setting the default value of the Can Declare property to True.
Figure 5-4 A customer-defined document class
When you define a document class, you also need to determine the properties associated with the class. The choice of properties is primarily guided by business requirements for search and retrieval, and requirements for managing record disposition and holds.
From a records perspective, properties are not only useful for search and retrieval, but they can be used to help classify the record during declaration. It is also common to use a custom date property for triggering records disposition. Any such properties, whether used for search or disposition, must be properly defined and configured.
Record classes
After you have identified the records-enabled document classes for documents that will be declared as records, you must create record classes in the FPOS to correspond with those document classes. There is no requirement to have a one-to-one mapping between records-enabled document classes in the ROS and record classes in the FPOS. In some solutions, a one-to-one mapping might be easier to implement. However, it can be more efficient to map the divergent metadata from the source document classes into a single or reduced set of record classes that store only the essential common properties for managing retention. The important consideration is that both sets of classes have corresponding properties defined to support the propagation of metadata from the documents to the declared record objects. Figure 5-5 on page 132 shows z customer-defined record classes in the FPOS (the record classes starting with ILG). This record class is defined in the RB FPOS object store, which is the FPOS for our case study. This corresponds to the customer-defined document class in the ROS that we show in Figure 5-4 on page 130.
Note: Avoid using the root Document class as a records-enabled document
class. Instead, create a subclass hierarchy from the root Document class in the ROS that identifies the classes of business documents that you will store and determine which of the document subclasses you want to enable for record-declaration. Allow users to declare documents only from these classes.
Figure 5-5 A customer-defined record class
When you define a record class, you also need to determine the properties associated with the class. The choice of properties is primarily guided by management and identification requirements for record dispositions and holds and for search and retrieval in Enterprise Records.
Note: Use the same property templates for the ROS and FPOS when
5.2.2 Manual declaration
In most organizations, users working or creating records to be manually added to IBM Enterprise Records are knowledge workers. The primary role of these users might vary vastly from that of the organizations Records Administrators and Records Managers, so for the records management system to provide a complete picture of the organizations records, it must be simple enough to use that it is embraced by all users, which is the challenge.
Users creating documents can typically use keyboard shortcuts, for example CTRL+S, to save documents, and they are prompted for the name of the document. To address the record metadata requirements, and from an IBM Enterprise Records perspective, there are now additional fields to be completed when manually adding documents, specifically the document class metadata, and the record class metadata. Both of which add more keystrokes and mouse clicks.
To overcome these challenges, IBM Enterprise Records can use many of the powerful capabilities of the underlying Content Platform Engine to assist users with manual record creation and capture, for example:
Document entry templates
Inheritance
Workflow
Document lifecycles
Record entry templates
Each of these are described in the section that follows.