Title: IMPLEMENTING%20AN%20ELECTRONIC%20RECORDS%20PROGRAM:%20LESSONS%20LEARNED%20FROM%20THE%20INDIANA%20UNIVERSITY%20ELECTRONIC%20RECORDS%20PROJECT
1IMPLEMENTING AN ELECTRONIC RECORDS PROGRAM
LESSONS LEARNED FROM THE INDIANA UNIVERSITY
ELECTRONIC RECORDS PROJECT
- Philip Bantin
- Indiana University Archivist
- Director of the IU Project
- bantin_at_indiana.edu
2How to Implement an Electronic Records Strategy
- Theories abound regarding electronic records
management - What we all desperately need are case studies on
HOW institutions are developing and implementing
electronic records programs
3Implementing E-R Programs Preliminary Step 1
- Records professionals must define their primary
and unique contributions to managing digital
resources - To do this the profession must not only define
itself, but also articulate the mission of
archives/records management in relation to the
goals and objectives of other related data and
information management professionals
4Preliminary Step 1 Define What is a Record?
- Records reflect business processes or individual
activities a record is not just a collection of
data, but is the consequence or product of an
event - Records provide evidence of these transactions or
activities. In other words, recorded
documentation cannot qualify as a record unless
certain evidence about the content and structure
of the document and the context of its creation
are present and available
5Preliminary Step 1Define What do
archivists/records managers contribute?
- The IU Archives team has defined its mission and
its contribution as the identification and
appraisal of records generated in the context of
business processes, and the creation of systems
that capture, manage, and preserve these records
- In other words, records and recordkeeping systems
are our main and primary responsibilities
6Preliminary Step 2Define System Requirements
- What are the basic requirements for a
recordkeeping system? What functions will the
system perform? - What types of documentation or metadata must be
present to ensure the creation of authentic and
reliable records? - These are your blue-prints that form the
framework for your e-r program
7Preliminary Step 2Define System Requirements
- Of prime importance is addressing the questions
- Is the system capturing business records?
- Is the system ensuring that all necessary record
metadata documenting business processes are
captured? - Is the system maintaining inviolate records
protected from accidental or intentional deletion
or alteration? - Is the system preserving records with long-term
value? - Is the system implementing retention and disposal
decisions? - Is the system ensuring the future usability of
the business records?
8Preliminary Step 3 Forming PARTNERSHIPS with
other Information Professionals
- Goal Find some means of involving your program
in the authorized and routine review of
information systems. - Align your program with professionals who
routinely design and review information systems
9Preliminary Step 3Forming PARTNERSHIPS with
other Information Professionals
- Based on experience, I have found three partners
most valuable - Decision support personnel
- Systems analysts
- Internal auditors Particularly the IS auditors
10Translating these Requirements into an
Implementation Strategy
- 2 Primary Steps
- 1) Develop a methodology, a set of steps that
will allow you to design or analyze a system
according to your sets of recordkeeping
requirements and metadata specs - 2) Develop a strategy for implementing your
recommendations
11Analysis of Information Systems
- My experience would indicate that traditional
records management strategies established for
paper records will have to be altered in
significant ways to accommodate electronic
records. - How?
12Analysis of Information Systems
- The most important and profound change will be
the creation of an overall strategy that views
CONCEPTUAL MODELS and SYSTEM DOCUMENTATION as the
primary tools for dealing with many or most of
the issues the profession faces in attempting to
manage records in automated environments
13WHAT IS CONCEPTUAL MODELING?
- Conceptual models show what a system does or must
do. They are implementation-independent models
that is, they depict the system independent of
any technical implementation.
14Business Process Models
- These models provide the tools for identifying
records, and for undertaking most steps in the
systems design and analysis process. - Depicting or modeling the business processes
and/or workflow activities is the critical first
step in the analysis process all other
activities build off the results of these models
or descriptions of the business processes.
15USEFUL MODELS FOR ARCHIVISTS
- Business process decomposition descriptions or
diagrams - Business Event Diagrams
- Business process data flow diagrams
- Object Modeling Unified Modeling Language (UML)
16TimekeepingData Flow
From student
Hours worked
Completed Timesheet
Approved Timesheet
Final Approve/ Disapprove Timesheet
Approve/ Disapprove Timesheet
To Payroll
Complete Timesheet
Final Timesheet
New Timesheet
Disapproved Timesheet
Disapproved Timesheet
Timesheet
Correct Timesheet
Create Timesheet)
Recordkeeping System
From system
17Models and Documentation - Data
- Examples
- Data Models A depiction of a systems data in
terms of entities (types of things we want to
document) and relationships (properties or
characteristics of an entity) - Data Dictionary A repository of information
about the definition, structure, and usage of
data that may include the name of each data
element, its definition (size and type), where
and how it is used, and its relationship to other
data
18Documentation - System
- Descriptions of how an information system works
from either a technical or end-user perspective - Procedure Manuals Descriptions of Security and
Authorization Procedures Descriptions of
Procedures for Migrating, Purging, Exporting, and
Restoring Data
19Analysis of SystemIs the system capturing
records?
- Answer this by
- Examining and/or creating Business Process models
- Record creation occurs at the business
transaction level, and the actual records to be
analyzed are are those documents received as
inputs to the system and those records created as
a result of the outputs generated in response to
some business event or workflow activity.
20Record Capture
- For analyzing record capture, analysis and
documentation will occur at the Business Event or
Record Level rather than at a the level of a
function or of high level business process - To be effective, analysis of business processes
will have to drill down to the business
transaction that directly created the record.
21Record Capture
- Why is this necessary?
- Because we cannot assume these records and their
metadata will be captured by the automated system - Unlike paper records, we cannot assume an
electronic record (and its metadata) once
created, viewed and used in some business
transaction will be captured and saved.
22Record Capture
- Is this level of analysis realistic? YES
- But only if archivists employ a methodology based
largely upon conceptual models. - Also recognize that the vast majority of these
transactions are repeatable, and once you have
identified the transaction, you do not have to do
it again. - In this sense, each repeatable transaction forms
a record series.
23Analysis of System How Will We Know if
the System is Maintaining Inviolate Records?
- Examine procedure manuals and workflow models
relating to routing, inputting, updating, saving
and deleting records, and system security
procedures. - Analyze each major business transaction and the
records it produces in terms of these procedures - For many records this activity can be managed at
the sub-function level or for many processes
within a function
24Analysis of System Is the system preserving
records?
- Examine procedure manuals relating to backing-up,
migrating, purging, exporting and restoring data - Analyze each major business transaction and the
records it produces in terms of these procedures - For many records this could be managed at the
sub-function level or for many processes within a
function
25How Will We Know When We Have a Complete,
Authentic, and Reliable Record?
- Examine any models or documentation on data and
metadata - Determine on the basis of your metadata
specifications and business process models which
metadata elements need to be present - Some metadata can be assigned at the aggregate
level, i.e., there is a core set of metadata that
will be assigned to all records produced by a
business function/sub-function - However, some business processes will require
more detailed documentation
26Analysis of SystemIs the system implementing
retention and disposal decisions?
- Review any existing disposition schedules and
laws, policies and best practices related to
recordkeeping - Analyze transactions, and if necessary individual
records, identified in your business process
models, to determine how long records of this
business process must be retained. - Examine documentation on data and data models to
determine what types of informational value may
be present in records
27Analysis of SystemIs the system ensuring the
usability of business records?
- Review any procedures that define access and use
of records, and training procedures - Analyze each major business transaction and the
records it produces in terms of these procedures - Access and security For many records this can
be managed at the sub-function level or for many
business processes within a function
28Review and Analysis of New Systems
- Involvement in Design Stage makes the process
much easier to implement - In many cases, designing a new system involves
incorporating your requirements or specifications
and the results of your business process models
into the design of the new system
29Review and Analysis of Existing Systems
- Normally a more time consuming, more difficult
process - Involves not only specifying your requirements
and metadata specifications and your list of
records to be captured - It also requires an analysis of how the present
system is managing the data - It involves analysis of What is as depicted by
models and system documentation with What Should
Be as defined by your requirements,
specifications and models
30Analysis and Documentation
- Automated systems offer
- 1) Opportunities to define records more precisely
and more completely than ever before, and we can
realistically achieve this if we employ
conceptual models - 2) Threats to the very existence of records if we
do not modify our traditional methodologies
31Implementation Strategies
- There are many strategies for incorporating
Recordkeeping Functionality into Data and
Information Systems
32Implementation Strategies
- Issues to consider
- Should recordkeeping be incorporated into the
specific application or should recordkeeping be a
separate but integrated system? - How to combine record content and metadata?
33BUILDING RECORDKEEPING FUNCTIONALITY INTO SYSTEMS
- A key implementation strategy
- Automate records management functions to the
greatest extent possible. - What does this mean for each of the issues
related to capture, documentation, disposition,
preservation, and usability?
34BUILDING RECORDKEEPING FUNCTIONALITY INTO SYSTEMS
- Capture of Records and Metadata Implementation
- Strategy Design systems so that the capture of
records and metadata occur within the context of
an automated workflow or business process engine
35BUILDING RECORDKEEPING FUNCTIONALITY INTO SYSTEMS
- Capture of Metadata
- Strategy Develop automated audit trails
documenting all business processes, including
activities relating to the creation, updating or
revision, deletion, and access and use of records
36BUILDING RECORDKEEPING FUNCTIONALITY INTO SYSTEMS
- Disposition of Records
- Develop an automated, schedule-driven process
- Automated retention and destruction of records
- Automated notification and approval of designated
personnel in advance of disposition activities - Automated interruption of disposition activities
for records that become the subject of litigation
37BUILDING RECORDKEEPING FUNCTIONALITY INTO SYSTEMS
- Preservation of Records
- Automated schedule of when the copying and
conversion of records will occur - Automated notification and approval of designated
personnel in advance of preservation activities
38BUILDING RECORDKEEPING FUNCTIONALITY INTO SYSTEMS
- Usable and Meaningful Records
- System assembles as a unit all components of a
record, including relevant metadata, notes,
attachments, etc. - System maintains a relationship or link between
the records of related business processes
39BUILDING RECORDKEEPING FUNCTIONALITY INTO SYSTEMS
- Another implementation strategy
- Whenever possible, build recordkeeping
functionality into ENTERPRISE-WIDE applications
rather than into individual applications
40OneStart/EDENA Description of IU's Transaction
Processing/Recordkeeping Environment
41Portals and Recordkeeping
How can archivists and records managers,
leverage portals in our efforts to capture,
maintain, and preserve electronic records?
At Indiana University . . . OneStart Campus
portal EDEN (Enterprise Development
ENvironment) Shared infrastructure
42Portals in Higher Education
A campus portal may be defined as a single
integrated point for useful and comprehensive
access to information, people, and processes.
While portals have a rapidly evolving set of
features and characteristics, they can be
described as both personalized and customized
user interfaces providing users with access to
both internal and external information. Portals
can be used for a variety of activities which
generally fit into three main categories
gateways to information, points of access for
constituent groups, and community/learning hubs.
David L. Eisler, A Portals
Progress Syllabus Magazine, September 2000
43Background IUs IT Strategic Plan
- Five-year Information Technology (IT) Strategic
Plan released 1998 - Replacement or re-engineering of several
enterprise wide applications - PeopleSofts HRMS and SIS
- Excellent opportunity to integrate all of the
enterprise applications at IU through a
transaction-processing environment - Would provide access to these applications
through a coordinated, unified front end and an
infrastructure made up of components that would
be shared among applications
44OneStart EDEN Component-Based Development
OneStart
User Interface
Customized
Personalized
Adaptable
Desktop
Application Delivered
Channels
Applications
Other Content
Services
Record Keeping
Application Services
Infrastructure
EDEN
45Conceptual Design Advantages of Component-Based
Development
- Creates a repository of reusable business
functions that also allows for the replacement of
specific functions - Aids rapid application development by assembling
existing components and services. - Can improve the agility, flexibility, and
scalability of an application. - As long as components agree upon the protocol to
be used, an application does not have to reach
into another application's database for
information.
46Conceptual Design Workflow
Workflow is "the automation of a business
process, in whole or part, during which
documents, information or tasks are passed from
one participant human or machine to another for
action, according to a set of procedural
rules. http//www.e-workflow.org/
Starting from creation and ingestion, we
should integrate the workflow process with the
preservation process appraisal, verification,
maintenance and, eventually, retirement. Su-Sh
ing Chen The Paradox of Digital
Preservation Computer (IEEE Computer
Society), March 2001
47Conceptual Design EDEN Workflow Engine
Applications
EDEN (Infrastructure)
FIS
Portal (User Interface)
Inbox
HRMS
Workflow Engine
OneStart
Purchasing
Preference Engine
Recordkeeping
48Conceptual Design Routing an E-Doc
Applications
EDEN (Infrastructure)
FIS
Portal (User Interface)
Inbox
HRMS
Workflow Engine
OneStart
Purchasing
Preference Engine
Recordkeeping
49Conceptual Design Workflow and Electronic
Recordkeeping
Applications
EDEN (Infrastructure)
FIS
Portal (User Interface)
Inbox
HRMS
Workflow Engine
OneStart
Purchasing
Preference Engine
Recordkeeping
50IU Electronic Recordkeeping Projecthttp//www.ind
iana.edu/libarch/ER
OneStart/EDEN Portal http//onestart.iu.edu
Project Website http//onestart.iu.edu/project