powerpoint presentation - how to implement an electronic records

50
IMPLEMENTING AN ELECTRONIC RECORDS PROGRAM: LESSONS LEARNED FROM THE INDIANA UNIVERSITY ELECTRONIC RECORDS PROJECT Philip Bantin Indiana University Archivist Director of the IU Project [email protected]

Upload: nguyenhuong

Post on 01-Jan-2017

215 views

Category:

Documents


1 download

TRANSCRIPT

IMPLEMENTING AN ELECTRONIC RECORDS PROGRAM: LESSONS LEARNED FROM THE INDIANA

UNIVERSITY ELECTRONIC RECORDS PROJECT

Philip BantinIndiana University

ArchivistDirector of the IU Project

[email protected]

How 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

Implementing 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

Preliminary 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

Preliminary 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

Preliminary 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

Preliminary 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?

Preliminary 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

Preliminary 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

Translating 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

Analysis 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?

Analysis 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

WHAT 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.

Business 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.

USEFUL MODELS FOR ARCHIVISTS

• Business process decomposition descriptions or diagrams

• Business Event Diagrams• Business process data flow

diagrams• Object Modeling – Unified

Modeling Language (UML)

Create Timesheet)

Correct Timesheet

Complete Timesheet

Approve/ Disapprove Timesheet

Final Approve/

Disapprove Timesheet

From system

From student

Hours worked

Timesheet

TimekeepingData Flow

To PayrollCompleted Timesheet

Approved Timesheet

Recordkeeping System

Disapproved Timesheet

Final TimesheetNew

Timesheet

Disapproved Timesheet

Models and Documentation - Data

Examples: Data Models: A depiction of a system’s

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

Documentation - 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

Analysis of System:Is 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.

Record 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.

Record 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.

Record 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.

Analysis 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

Analysis 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

How 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

Analysis of System:Is 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

Analysis of System:Is 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

Review 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

Review 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

Analysis 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

Implementation Strategies

There are many strategies for incorporating Recordkeeping Functionality into Data and Information Systems

Implementation 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?

BUILDING 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?

BUILDING 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

BUILDING 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

BUILDING 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

BUILDING 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

BUILDING 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

BUILDING RECORDKEEPING FUNCTIONALITY INTO SYSTEMS

Another implementation strategy:

Whenever possible, build recordkeeping functionality into ENTERPRISE-WIDE applications rather than into individual applications

OneStart/EDENOneStart/EDENA Description of IU's A Description of IU's

Transaction Transaction Processing/Recordkeeping Processing/Recordkeeping

EnvironmentEnvironment

How can archivists and records managers, leverage portals in our efforts to capture, maintain, and preserve electronic records?

Portals and Recordkeeping

At Indiana University . . .OneStart

Campus portal

EDEN(Enterprise Development ENvironment)

Shared infrastructure

Portals 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 Portal’s Progress”Syllabus Magazine, September 2000

Background – IU’s IT Strategic Plan

Five-year Information Technology (IT) Strategic Plan released 1998

Replacement or re-engineering of several enterprise wide applications PeopleSoft’s 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

OneStartCustom

ized

Personalized

Adaptable

Desktop

Application Delivered

HR

MS

SIS

FIS

IUIE

Other

Other Content

EDEN

Channels

Services

Workflow

Record Keeping

Security

Users Application

Services

Applications

User Interface

Infrastructure

OneStart & EDEN Component-Based Development

Conceptual 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.

Conceptual 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-Shing Chen “The Paradox of Digital Preservation”Computer (IEEE Computer Society), March 2001

FIS

HRMS

Purchasing

OneS

tart

Recordkeeping

Inbox

WorkflowEngine

Preference Engine

EDEN(Infrastructure)Portal

(User Interface)

Applications

Conceptual Design – EDEN Workflow Engine

FIS

HRMS

Purchasing

OneS

tart

Recordkeeping

Inbox

WorkflowEngine

Preference Engine

EDEN(Infrastructure)Portal

(User Interface)

Applications

Conceptual Design – Routing an E-Doc

FIS

HRMS

Purchasing

OneS

tart

Recordkeeping

Inbox

WorkflowEngine

Preference Engine

EDEN(Infrastructure)Portal

(User Interface)

Applications

Conceptual Design – Workflow and Electronic Recordkeeping

IU Electronic Recordkeeping IU Electronic Recordkeeping ProjectProject

http://www.indiana.edu/~libahttp://www.indiana.edu/~libarch/ERrch/ER

OneStart/EDENOneStart/EDEN Portal Portal

http://onestart.iu.eduhttp://onestart.iu.eduProject WebsiteProject Website

http://onestart.iu.edu/projecthttp://onestart.iu.edu/project