Guest contribution by Martin Waldron,
In-Form Consult Ltd; Managing Director
MGB MoReq Governance Board, Chair
Die ersten beiden Teile des Artikels erschienen in den Newsletterausgaben 20090325 und 20090528. Der vierte Teil erscheint in der nächsten Ausgabe des PROJECT CONSULT Newsletters. Der Beitrag wurde ursprünglich als Whitepaper für die Fa. EMC verfasst.
Using MoReq2
Concepts and Terminology
MoReq2 Chapter 2 includes definitions of all the terms and concepts used in the specification; on the whole the definitions in MoReq2 are very useful. This section highlights some terms where the usage is new or has changed.
Classification Scheme – Chapter 3
A classification scheme is fundamental to records management – no change here - MoReq stipulates a hierarchic arrangement of business activities and/or records covering the whole organisation, with procedural rules. In MoReq2 the classification scheme hierarchy can contain classes, files, sub-files, volumes and records.
MoReq2 uses the term “file” in the records management sense; most people (who are not records managers) would probably use the term “folder” instead.
The term “sub-file” is used for an intellectual or logical split of a file e.g. split by type of record – the requirement to support sub-files is new to MoReq2. This is illustrated by the use in the Case File definition – see below.
The term “volume” is used for a physical, logical or mechanical division of a sub-file, e.g. based on a number of records, period of time eg yearly, or other agreed division. (TNA requirements use the term ‘part’).
Unlike MoReq, MoReq2 permits records to be stored directly in classes. It does not however encourage it. This is a long-running argument. Storing records in classes is more intuitive and consistent with DoD 5015.2 (US Department of Defence Electronic Records Management Software Applications Design Criteria Standard), but is not standard practice in Europe. It offers less control and context.
Case Files
MoReq2 has introduced the concept of case files, to meet the particular requirements of records associated with casework applications such as applications for permits, enquiries about a routine service, investigation of an incident, and regulatory monitoring.
The business requirements specific to case files (folders) typically include:
| | | |
| | · | can be created, opened and closed by practitioners, end-users or data processing systems without the need for management approval |
| | · | are structured or partly structured (e.g. contain many application forms all based on one template) |
| | · | documents may have particular naming conventions (e.g. name + date of birth) which need external validation |
| | · | may have specific metadata, integration and access requirements e.g. a metadata item to show “status” or “Progress” which can be set externally. |
Case File Example
Security categories
An ERMS will always control access to records by role and group (see section 2.2.1 below), but some organisations need to limit access further, using a scheme of security clearances, for example by marking records as Not Restricted, Confidential, Top Secret, etc. These take precedence over any other access rights. Examples of use may involve personal information, national security, healthcare, etc. A further example may be where higher grades of staff have access to information (such as details of a new product) that is not available to more junior staff. MoReq2 calls these security categories (TNA: Access Control Markings) and they are dealt with in some detail in chapter 10.13.
Disposal Holds
MoReq2 includes the concept of “disposal holds”, which was not mentioned in the previous version of MoReq. Disposal holds are used in response to unexpected events to ensure that specified records are not destroyed. The common example is to ensure that records that are, or that may be, required as evidence in legal proceedings are not routinely destroyed as a result of the assigned disposition decision.
Highly regulated industries and complex engineering projects where claims and disputes are common will find this function of real value in overriding the designated retention period and actions in order to retain the records during the dispute.
Identifying Business Requirements
This section introduces the functional areas in MoReq2 from a business viewpoint and gives guidance on their areas of application and use.
Records Management
MoReq2 chapters 3 - 9
These chapters are the core requirements of records management and are substantially expanded compared with the original MoReq specification.
Project business drivers related to the management of records are quite diverse. Drivers could be a requirement to reduce the amount of paper and duplication of paper and electronic copies of information, or to dispose of electronic records in line with the organisation’s disposition policy, or provide better access to information, or incorporate email, or comply with Freedom of Information (FOI) and Data Protection Act (DPA) legislation, or indeed all of these.
Some organisations will require a more strict regime for records management than others. However for organisations that operate in a lightly regulated environment, with little risk of documents being needed in court, and with no long-term holding of records, records management still has many benefits. For example adoption of a corporate classification system, standardising taxonomies, enforcing retention schedules and access controls, all raise productivity and reduce risk.
The main technical elements of a system which supports records management are: classification scheme, retention schedules, and access controls; are all addressed in chapters 3 – 9.
The content of each chapter and key and new aspects are set out below:
Chapter 3
Classification Scheme & File Organisation
This provides more details of the classification scheme requirements discussed above in 2.1.1. It also deals with maintenance of the Scheme in section 3.4.
Chapter 4
Controls and Security
Access control for users and protection from system failure are covered plus audit trail require-ments and management of vital records.
Chapter 5
Retention & Disposition
All aspects of retention and disposition schedules are addressed including review processes and requirements for disposition, export and destruc-tion.
Chapter 6
Capturing and Declaring Records
The capture of records is covered in some detail with 41 requirements, and aspects of bulk and email capture and the integration with scanning systems are addressed.
An organisational e-mail policy needs to be in place before technical requirements for e-mail management can be finalised, as the way e-mail is used will affect the capture requirements. MoReq2 provides a useful set of e-mail records management considerations and the 18 require-ments set out provide the user with a comprehen-sive check list of features which should be considered. Also mapping these back into your policies is useful exercise which may see a re-alignment of your policies or practices. Note that E-mail archiving is not the same as e-mail management; MoReq2 might help identify business requirements that are not addressed by e-mail archiving applications.
Any organisation that is involved in legal discovery and then relying on that information in court will need records management. The MoReq2 requirements can act as a useful checklist of business requirements that are consistent with the evidentiary code of practice, BIP0008 . EDRM systems may include scanning capability, but they are more likely to offer integration with industry-standard scanning solutions. Not all scanning applications however will support records management; in any statement of requirements suppliers should be asked for clarification of the support provided.
Chapter 7
Referencing
This chapter provides a useful guide on setting up standards for classification codes and system identifiers, and examples of different schemes. An organisation may require, for example, to retain consistency with the indexing on an existing physical filing system.
Chapter 8
Searching, Retrieval and Presentation
For many organisations a fundamental objective is to improve access to information so that users can find the correct information reliably and quickly, subject to authorisation of course. EDRM systems generally provide excellent search capabilities on information held in the repository; searching on other information located outside of a records repository is normally out of scope.
With an ERM, users who require to browse rather than search will be able to do so by navigating the classification scheme (rather like using the subject index in a library to find the correct shelf, then scanning what’s there).
The technical elements underpinning these are full text retrieval capability (similar to Google searching), support for metadata and thesaurus, access controls, and ease-of-use features such as the ability to display favourites and recently used folders and documents. MoReq2 provides a detailed specification of these functions.
This section could also be of use to an organisation considering or already using search technology. MoReq2 provides a useful checklist for their business requirements and to identify if there are any aspects that they may wish to con-sider.
Chapter 9
Administration
MoReq2 may be a very useful check list of all the administrative tasks that need to be considered when planning an EDRMS implementation.
Organisations adopting ERM need to decide how the system will be administered and allocate these tasks to ‘roles’ which may be individuals or groups. Note that administrative roles are only implementing policy decisions taken by more senior management, which should be based on the business needs of users to access information, the organisation’s records policy, laws relating to data security and archiving, and industry regulations. (The addendum on page 19 following provides a useful guide on the type of controls and assignments you may wish to use).
Aspects such as maintaining the classification scheme will remain with a records manager or RM group, but there are options on how much should be devolved to user departments – for example allowing some users to add folders or create specific types of records.
Consideration should be given to the requirements for an audit trail – these can easily grow to unmanageable size if every action is logged and the audit trail is not archived periodically.
Backup and Recovery policy and procedures need to be defined; the functionality may be provided by the EDRMS, by a database management system operating with the EDRMS, or by a corporate wide back up and recovery services.
Although it is not mandatory as in the North America, organisations may require the func-tionality to restore ‘vital records’ as a priority during a recovery exercise, that is, those that are considered absolutely essential to the organisation’s ability to carry out its business functions, in the short term or the long term or both.
Chapter 10
Optional Modules –
This chapter covers requirements that are closely related to electronic records management such as management of physical (non-electronic) records, and also related functions such as document management, workflow, electronic signatures and case management.
In this chapter MoReq2 provides less detail for these functions than in the chapters related to electronic records management.
Chapter 10.1, 10.2
Management of Physical Records
An organisation which already has physical record keeping systems should use this section to consider how they fit their solutions under two options: separate physical and electronic systems, or a unified environment.
To manage non-electronic records such as paper based records or microfiche, the EDRM system must be able to hold information about them and/or their containers (e.g. a box number and location), so that users can locate, track, retrieve, review and dispose of physical records, and allocate access controls to them in the same way as to electronic records.
If the volume of records is large and they are actively used, you may want to produce bar code labels and use these to track who holds the records, and when they are issued and returned.
In MoReq2, classes, files, sub-files and volumes may all contain any combination of electronic records and physical records – a change from the previous version of MoReq, to reflect the need to preserve the integrity and accessibility of electronic and physical records taken as a whole and manage them under a unified set of policies.
Chapter 10.3
Document Management and Collaboration
MoReq2 groups together document management and collaboration. Document management requirements are very comprehensive but collaboration requirements less so; for example facilities such as blogs and wikis which some would see as important within “collaboration” are not included in MoReq2. Collaboration is a rapidly developing field. It is probable that we will see a lot of developments in this area, in part due to the mass proliferation of Microsoft Office SharePoint Server 2007.
If all you require is a records repository, and you can accept the overheads of back-end filing, then you may not need document management. Most organisations take a wider view and want to address the process of creating, approving and capturing documents; perhaps including the scanning and capture of external paper documents (see life cycle diagram in Section 1.2). For some, the ability for teams to collaborate in producing and updating documents – as project or work groups - is also a key requirement.
The technical elements underpinning document management that relate to EDRM systems are version control, support for review and approval, and for document publishing.
Chapter 10.6
Integration with Content Management Systems (CMS)
One of the useful aspects of this section of MoReq2 may be to help define what CMS actually is, and if it is in scope for your EDRM project.
The line between EDRMS and CMS is somewhat blurred but CMSs usually deal with different aspects of managing information than EDRMSs. Common characteristics are:
| | | |
| | · | publishing information, often to websites or portals, and sometimes to several channels using different renditions (This is currently the most frequent use of the word CMS); |
| | · | managing information that originates from several sources; |
| | · | reformatting information and/or migrating it to different rendition(s); |
| | · | relating different versions, renditions and translations of documents to each other; |
| | · | managing components of documents. |
Modern content management systems include most or all of electronic document management system (EDMS) functionality (see section 10.3). There are also some clear differentiators with Electronic Records Management - ERM. ERM provides the disciplines required for compliance and good governance such as retention functionality, legal hold (for discovery) and disposition (destruction of content to reduce overall data stores) and most importantly ensures the immutability of the records.
Content management functionality may be provided by a CMS separate from the ERMS, but commonly as a unified solution that seamlessly integrates both CMS and electronic records management functionality. The relationship between an ERMS and a CMS in the unified solution is shown below, in a highly simplified form.
CMS technology is evolving rapidly, so organisa-tions that require CMS integration must specify their individual requirements; reliance on this section alone is not likely to suffice. This section should be viewed as a starting point, to prompt further analysis to determine your CMS requirements.
Chaper 10.4
Workflow
If in your organisation workflows are part of a broader ECM solution that ties into ERM, then you would be well advised to examine this section of MoReq2. One thinks for example of call centres in financial institutions or processing of applications, orders or claims.
At its simplest, many organisations require only to deliver documents electronically internally and/or externally, to improve productivity and reduce elapsed time. For others, documents are essential components in the context of a business process, where they may be tied closely to line-of-business applications, as triggers or reference material or outputs.
Workflow will be an important requirement for operational business areas that are transaction-oriented, for example processing applications or complaints rather than say producing research papers.
MoReq2 in chapter 10.4 addresses the simpler end of the workflow spectrum; if you require a full BPM system MoReq2 will not provide a comprehensive set of requirements
Technical elements underpinning workflow include a design tool to make a model of the business process, a workflow engine or monitor to check real-time status, the ability to alert users when action is possible or required, and the ability to store or retrieve information from the repository within a workflow.
Chapter 10.5
Case Management
Many organisations have case management requirements, that is, where a process is closely tied to a case file which contains the documents and/or records created and used in the application. This section provides an insight into what requirements might need to be added to leverage existing systems to provide a better record of their activities without going to the expense and added complexities of a separate records management system.
If you have case management applications, you need to decide where to hold the case files. EDRM systems traditionally had difficulty fitting these into the classification scheme, but MoReq2 has extended their “Fileplan” definitions to include a Case file structure (see 2.1.2 above).
These applications may also require application integration facilities (described in the following section) to integrate with line-of-business computer applications, and also require workflow as described above.
Chapter 10.6
Application Integration
The EDRM must fit into your technical environment and be capable of being used with other applications, for example
| | | |
| | · | allowing other business applications to create, open and close EDRMS case files; |
| | · | allowing the EDRMS to query other systems e.g. to validate metadata values |
To define the requirements administrators will need to understand in detail how users will use the system to carry out their normal workload, and involve IT to define the technical aspects.
MoReq2 provides a good start point for defining application integration requirements, but the requirements are interspersed in the case management section. Note this requires careful extraction if your requirement is just for application integration
Other Organisation-specific Functionality
Other requirements which are addressed in MoReq2 but not applicable to everyone include:
Chapter 10.11
Offline and remote working
The requirements in this section cover all types of mobile and offline usage of the EDRMS by users who are not permanently connected to the EDRMS (or to the network hosting it).
There are several possible scenarios including:
| | | |
| | · | users who access the EDRMS using portable computers (such as mobile, laptop, or notebook computers) or PCs that are connected to the EDRMS intermittently; |
| | · | users who connect to the EDRMS remotely through a dial up connection, or any other connection with low bandwidth connection (e.g. for telecommuting or in a temporary location); |
| | · | users who access the EDRMS using other mobile devices such as PDAs or smartphones. |
The importance of these requirements will depend on the nature of your organisation; the requirements covered relate mainly to:
| | | |
| | · | security e.g. specifying what cannot be downloaded |
| | · | synchronisation of data including metadata when uploading and downloading for offline working. |
Again if you have a very distributed and dynamic workforce there will be many other functional and logistic requirements you will need to work through.
Chapter 10.8
Support for encryption
The requirements in this section apply only where there is a requirement to manage records which are encrypted. This is a specialised requirement likely to apply only to a few organisations, but the fact that the support is there to be used if needed may provide reassurance.
Chapter 10.10
Distributed systems
This section comprises requirements for organisations that require an EDRMS to operate in multiple locations and find it necessary to have multiple repositories, rather than one central repository linked to all locations.
This requirement may apply where the sites are widely separated, and/or if the connectivity between them is not good. Considerations for the operation and management of multiple reposi-tories are well covered.
This section will be important for organisations that are investigating and considering imple-mentation of Federated Records Manage-ment systems (FRM).
FRM started to appear in products in around 2005. The idea is to provide records management that is capable of controlling content that resides in disparate repositories. Generally this is achieved by manipulating the security settings on the content within the repository. FRM products have been limited in the past, but this section potentially provides a method of assessing how capable these products are of achieving records management across multiple locations and systems.
Chapter 10.9
Digital Rights Management – DRM
This is a specialised requirement to do with protecting intellectual property and/or to restrict the distribution of information. DRM is generally associated with the protection of intellectual property (especially in the music, electronic publishing and film industries). E-DRM (Electronic DRM), as defined in MoReq2, deals with what is more commonly called Information Rights Management (IRM) and the section gives high level requirements providing a set of considerations on creating and exporting records with IRM features and their resulting restrictions. The user needs to take these requirements as a framework for developing more detailed technical requirements based on IRM sources and level of use.
Chapter 10.7
Electronic Signatures
For many organisations, the audit trail plus strict access control will provide sufficient assurance of the integrity of the records, and electronic signatures won’t be needed at least for internal communications. However if you use e-mail to document business transactions between organisations, it may be advisable to append an e-signature.
Note, however, that although e-signatures have been put into law and the required bodies to govern their use are in place in Germany and other EU member states, to date public adoption has been very limited. The UK has yet to set up the infrastructure for their use.
Chapter 11
Non-functional requirements
Some of the attributes of a successful EDRMS implementation cannot be defined in terms of functionality. These non-functional requirements are often difficult to define and to measure objectively but they should be identified and considered, at least at a high level. Some are specific to EDRM, but several are generic to many kinds of IT system.
MoReq2 chapter 11 brings a number of these requirements together as a checklist of areas to cover, and they provide a useful start point that is worth mentioning.
| | | |
| | · | ease of use (11.1); |
| | · | performance and scalability (11.2); |
| | · | system availability (11.3); |
| | · | technical standards (11.4); |
| | · | legislative and regulatory requirements (11.5); |
| | · | outsourcing and third party management of data (11.6); |
| | · | preservation and technology obsolescence (11.7); |
| | · | business processes (11.8). |
MoReq does not address the suitability of different storage media, other than including requirements for long term preservation.
Project Management and Implementation
As mentioned earlier, MoReq2 does not address other aspects of EDRMS implementation such as project management, development of a fileplan, defining user roles and access rules, training and communications, acceptance of the system.
These are all outside the scope of MoReq2, but are absolutely essential to successful implementation.
Metadata