Research Issues in Interfaces for the Capture of Business Processes
John McDonald
Electronic Records Meeting
Pittsburgh, PA
May 29, 1997
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) 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:
- Management of Government Information;
- Holdings Management, and;
- Administration.
- 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:
- "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):
- 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:
Activity: | development project |
Transaction Type: | request for approval of product |
Antecedents: | endorsed draft product |
Consequence: | product approved |
Status: | approve |
Software Required: | workflow, wp, forms manager |
Authority: | project manager |
Permission: | internal to Division only |
Retention: | 2 years after completion of the project evaluation report and then transfer to the National Archives |
DTD Genre: | "request for product approval" form (plus project description form and "development" product format) |
Next Steps: | approval notification; product distribution; project evaluation |
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;
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:
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)