Upload
nguyenhuong
View
215
Download
1
Embed Size (px)
Citation preview
IMPLEMENTING AN ELECTRONIC RECORDS PROGRAM: LESSONS LEARNED FROM THE INDIANA
UNIVERSITY ELECTRONIC RECORDS PROJECT
Philip BantinIndiana University
ArchivistDirector of the IU Project
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