Electronic Records Research 1997: Resource Materials

1. BACKGROUND AND PURPOSE OF THE PROTOTYPE

In June, 1996, the National Archives distributed its Guideline on the Management of Electronic Records in the Electronic Work Environment (EWE) to government institutions. The Guideline provides both short and long term strategies for managing electronic records that are typically generated in the office environment. The guidance is based on the principle that the most effective way to manage records in the EWE is to incorporate record keeping requirements into the design of automated business processes. In order to promote this concept, the National Archives issued a draft version of "A Vision of Record keeping in the Electronic Work Environment". While the concepts described in both this document as well as the electronic records guidance were considered to be useful by those who reviewed it, many felt that it would be even more useful if the concepts could be reflected in a "live environment", possibly through a pilot project or "proof of concept" prototype. Such an environment would also be useful in enhancing the knowledge and awareness of the members of the EWE Management Board who are the key stakeholders and the ones who would be in the best position to sponsor future work. Based on an analysis of various options, it was decided to establish a "proof of concept" demonstration prototype in the Information Management Standards and Practices Division (IMSP) of the National Archives.

The overall objective of the prototype is to illustrate an electronic work environment that comprises automated workflow and automated/transparent record keeping within the context of the business structure and work processes of a given organizational unit. Specifically, the prototype is designed to:

a) serve as a learning tool to foster greater understanding of the concepts associated with the use of workflow technologies in the electronic work environment and the implications these concepts and technologies can have for record keeping.


a) help the National Archives develop enhanced versions of its Guideline on the Management of Electronic Records in the EWE through the experience it will gain in observing the implementation of this guidance in a "live" setting.

2. OVERVIEW OF THE PROTOTYPE

The prototype is based on the perspective of a project manager working in the Information Management Standards and Practices Division (IMSP), of the National Archives of Canada. The computer screen of the project manager contains icons reflecting the business activity structure of the division which is based on the Operational Plan Framework (OPF) of the department. Every Canadian government department is required to have an OPF that describes its functions, programs and activities. It is extremely important because it is used as the basis for the management of resources, providing reports to parliament and measuring performance. An OPF is much more stable than an organization chart because it is based on functions, programs and activities that tend to remain constant over time. For instance, the OPF of the National Archives has been in place since 1990 and has survived and indeed facilitated the reorganizations that have taken place over the intervening years.

All of the sub-activities of the National Archives are related to its four main activities:

- Services, Awareness and Assistance;

- Management of Government Information;

- Holdings Management, and;

- Administration.

- Government Operations

- Culture and Heritage

IMSP, which advises government departments on the application of standards and practices to the management of records, is responsible for eight sub-activities that support three of the main activities of the NA. All of the division"s resources, its initiatives, everything that it does and for which the director is accountable, are managed and reported on in accordance with the following activities:

- "development" of standards and practices;

- "advice";

- "professional development";

- "program support-Canadian";

- "program support-international";

- "related operational" activities;

- "planning" activities, and

- "administration".

These are the icons that appear as a default on the screens of the staff (including the project manager) in the Division. Should they wish, they may move either higher or lower in the program activity structure dependent upon the perspective they need.

The prototype is also based on the use of automated workflow technology which permits the automation of the key business processes of the Division. One of these business processes is called "management of projects". For the purposes of the prototype, when the project manager clicks on the business activity icon, development, she is linked to the automated workflow application that permits her to establish a project (e.g. the development of a guide on the management of electronic records), seek approval for the project plan, undertake the project, develop the products for the project, and seek approval for their distribution. Along the way she can monitor a project, write a memo on the project, organize a meeting about the project and carry out any number of other tasks related to the administration and conduct of the project. But rather than have to develop a project proposal, or a project plan or even a memo from scratch, she sees the project proposal form already set up in a way that reflects the format and rules that the division has decided upon for developing project proposals. When she clicks on the routing list for her proposal, rather than having to select from all of the names of the staff in the National Archives, she sees the names of those people who normally receive development project proposals. She also knows that as the proposal is sent, the record keeping rules that were designed into the applications for documenting and otherwise supporting the tasks associated with the management of development projects are respected. Above all, just as she recognizes her accountability for finance and personnel, she also knows that she was able to carry out her responsibility for applying the record keeping rules of the organization in a manner that supported, directly, the accountability and business requirements of her area of the Division (presumably supported by a record keeping specialist.

While not supported on the prototype, another example based on a different business activity icon and the other key business process of the Division (i.e. correspondence management) may help to clarify the concepts regarding the distinction among business structure, business processes, and record keeping. In this example, the director needs to send a draft of the annual report of the ICA Electronic Records Committee to the committee members. He clicks on "Program Support-International" and is presented with a suite of pre-designed and inter-connected utilities (e-mail, work processing, workflow, etc.) that comprise the automated work process that permits him to develop a covering letter, attach the report and send the package to the members (via the mail or Internet) and to the people to whom he automatically carbon copies all Committee business. Again, all of the record keeping (tagging, storing, etc.) happens automatically based on rules and criteria that were developed by the records specialist in consultation with the director and the divisional managers within the context of the business and accountability needs of the division and department. There is no "filing" icon. The rules for establishing how the content, context, and structure of the records of the actions and transactions associated with the given work process (in this case correspondence management ), within the context of the Division"s business activities, are to be kept, were set beforehand and designed into the automated process - that is, behind the screen.

The prototype contains a number of supporting functions which may be useful to the project manager from time to time. For instance, she can restrict certain steps of the work process (or the entire process) as well as selected documents to selected individuals (other security measures can also be taken-needs to be expanded). She can identify the properties of various objects such as transaction record types (i.e. includes explanation/definition of the object; retention specifications, disposition specifications; security requirements; etc.) for each of the following objects within the development activity (i.e. the rules are based on the requirements of the business activity and implemented in the design of the automated business process (or workflow):

- project plan approval;

- review notification

- product approval notification;

- product distribution notification;

- project description and plan;

- draft product;

- reference information;

- comments;

- approved products;

- distributed products.

She can also produce reports such as the status of all projects at a given point in time or a list of all records according to a project(s), sub-activity, time frame, etc. (including their retention and disposition specifications).

With respect to a "development" project called "Management of Electronic Records", for instance, if she clicked on the "documentation" for the project, she would be presented with a list of those documents (including records(?)) that were created or received during the conduct of the project and that remained at the conclusion of the project . The distinction between the documents in a case and the case itself was important, particularly from a retention and disposition perspective. For those documents which were not required to document the project (i.e. they could be deleted at the discretion of the work group before the conclusion of the project), the retention rule was to retain until superseded or for only the short period of time required to complete a subsequent task (e.g. update the next draft). For the records retained as part of the documentation of the project (including the significant drafts of the guideline), however, the business rule was 2 years after approval of the project evaluation report, transfer to the National Archives". That is, as soon as the project was completed, all of the documents that remained would form a case which would be retained for a period of time that was pre-established and in line with the business and accountability needs of the sub-activity (e.g. development).

The systematic approach to retention and disposition was possible because the records were already classified according to activity, business process, etc. Moreover, they had been automatically self-classified as they were created. This is because as the documents were created or received they were automatically tagged with metadata that included information about the work process step that created the record, the business activity within which the step was carried out, and the organizational unit which was accountable for the activity and, as a consequence, the records themselves. This metadata was created automatically by the system because the project manager was already working inside the "activity" and its associated work process. The retention and disposition information was automatically linked to the record because the business rules for keeping records associated with, for instance, projects managed under the "development" sub-activity were already designed into the system. The filling out of a document profile by the project manager was not required.

In the prototype, "project cases" (comprising all of the documentation associated with the initiation, conduct and evaluation of projects) were part of the "development" sub-activity. The fact that "project cases" was part of the "development" sub-activity is very important because if it had been connected with another sub-activity (e.g. administration) then the documentation and associated retention and disposition information might have been different. The kinds of documentation and the associated retention and disposition information are based on the relationship of the tasks of a given work process and the business activity (or sub-activity, etc.) that it supports. Conceptually, these form business objects, each of which carries its own contextual information or metadata, including retention and disposition information. Business objects and their attributes are described in the systems documentation associated with the automated work process. An example of the attributes of a business object used in this example is as follows:

In order to gain a clearer understanding of the business structure of the organization and, as a result, the extent of the metadata that can be wrapped around a record to set it within the context of the activities it is documenting, the project manager could have moved further up the business structure in order to see the attributes of the sub-activity development and the main activity Management of Government Information .

The attributes of the main activity contain references to the legislation and/or policy which enable the activity to be carried out in the first place. It also contains cross references to the Personal Information Bank (PIB) number and the Program Record (PR) number, both of which are required under the Access to Information and Privacy legislation. Regardless of the activity level (i.e. main activity, sub-activity, sub-sub-activity, etc.) cross references are provided to the relevant points in the organizational structure (e.g. the responsibility center managers) where accountability for the activity, sub-activity, etc. has been assigned. This information is all part of the contextual information that can be associated with a record created as part of a development project.

In summary, as the records and documents of a given project are created, they are encapsulated with metadata describing the characteristics of the task (inside a business process) that created the record, the activity supported by the task, and the accountable responsibility center in the organization. This metadata together with the functionality supported in a record keeping system are designed to ensure the authenticity and reliability of the record for the length of time it is required to serve a business or accountability purpose. The intent of this prototype has been explore the feasibility of accomplishing this record keeping task automatically and, in the process, to learn more about the overall concepts and issues associated with record keeping in the electronic work environment.

3. WHAT HAS BEEN LEARNED?

3.1 The establishment of an electronic work environment based on automated workflow is not as easy as one may think. Many office environments support unstructured, complex work processes that are in strong contrast to the highly structured business process environments associated with licensing, social benefit delivery, patents assessment, etc. In an office where people are carrying out multiple tasks at the same time, where the tasks are often ad hoc rather than structured and where the absence of rules can often facilitate rather than hinder the work getting done, the introduction of workflow technologies and associated record keeping needs to be addressed very carefully. The prototype illustrates both the potential benefits and the challenges of applying workflow technology in a dynamic rapidly changing office environment.

3.2 Rather than being applied to the automation of existing work processes, workflow technologies should be used to stimulate new and innovative approaches to work process design (i.e. through re-engineering). In other words the use of workflow design techniques should stimulate rather than suppress the development of more innovative ways of getting the work done. The design of automated work processes should be flexible and adaptable to the changing needs of the organization and, above all, the reality that just as soon as the work process is automated, fresh ideas will emerge to cause its design to change again. We need to understand the changing nature of the modern "office" and, within this context, the ability of organizations to keep records. Our pre-conceived idea of what the office environment looks like, especially as a result of the introduction of workflow technology, should be tested carefully.

3.3 We need to be very careful when we say that records comprise content, context, and structure and that they provide evidence of transactions. There are many different types of "documents" associated with a given process (e.g. comments, reference information, drafts of documents, records of transactions, etc.), much of which one might not think of as being records depending upon one"s point of view(!!). Each type contains its own requirements for content, context and structure but only a few have as their purpose to provide evidence of a transaction. With respect to context, although the prototype helped us to learn more about the potential role of the government"s program activity model (as opposed to its organizational structure), we need to understand more clearly the relationships among organizational structure, business activities, and work processes and why these, collectively, are important from the perspective of describing records.

4. WHAT DO WE STILL NEED TO KNOW?

4.1 Given what we have learned, is the prototype an appropriate perspective or illustration of the concepts of organizational structure, business structure, business processes, and record keeping and the interaction among all four concepts in the modern "office"? If so, is the demonstration prototype effective in demonstrating these concepts? If not, what can be done to improve it?

4.2 The demonstration prototype is making a distinction among objects such as transaction records, comments, reference information, drafts, etc. How should we approach the issues concerning when, what, where and why these objects should be stored and, by extension, how we should address the establishment of retention/disposition and metadata standards for these objects?

4.3 How do we relate the act of capturing a transaction record (or other objects) with;

a) making sure that the right and sufficient metadata is wrapped around the record (object) as it moves into the record keeping system; and


b) the actions involved in passing the record (object) to the record keeping system (where it will be retained presumably in accordance with the retention specifications for the object within the context of the business activity within which it was generated)?

4.4 The prototype does not include a record keeping component (i.e. supporting functionality such as expressed in the UBC and Pittsburgh projects?). How should this be included? What would the functional requirements look like?

4.5 The prototype does not include the functionality required to permit easy access to and retrieval of records and other information either within projects or across all activities and work processes of the Division. How should this be introduced?

4.6 What skills, knowledge and abilities are required to enable this kind of environment to exist? What are the implications for records managers, archivists, and information systems specialists?

SUPPORTING REFERENCES

1. Guideline on the Management of Electronic Records in the Electronic Work Environment, 1996, Ottawa (available on the National Archives of Canada web site at http://www.archives.ca/www/english/mgr/1erec.wpd)

2. "Automated Record Keeping - A Day in the Life of a Project Manager", unpublished work-in-progress "scenario" illustrating record keeping designed into automated workflow, Ottawa, April, 1997

3. Products of the ICA Committee on Electronic Records:

Guide for Managing Electronic Records from an Archival Perspective
Electronic Records Management: Literature Review
Survey of Electronic Records Programs

4. Information Management Standards and Practices Division, Product List, last updated, Fall, 1996 (available on the National Archives of Canada web site at http://www.archives.ca)

5. Core Competencies for the Future Records Specialist, unpublished discussion paper, Ottawa, July, 1996 (available from the National Archives, Information Management Standards and Practices Division, 613-947-1510)